veilletech.fr
5 sept. Feed du jour
#03 SÉCURITÉ Faille

Une backdoor compilée dans votre HAProxy

Le bon processus, le bon port, la bonne version affichée. Le mauvais binaire.

Rapid7 Labs décrit ted, un implant Linux compilé à l'intérieur même des binaires HAProxy de deux organisations sud-coréennes (automobile et médias), attribué avec une confiance moyenne à des acteurs nord-coréens. Une requête vers un chemin d'image précis bascule le filtre en mode C2 : l'implant décrémente les compteurs de connexions de HAProxy pour disparaître des statistiques, écrit la commande dans un tube nommé sous /tmp et répond sous un en-tête HTTP 200 ordinaire, sans que le backend voie passer quoi que ce soit.

3 min de lectureavancévidéo 1:19
Partager
Sommaire4 sections
  1. Ce qui se passe
  2. Comment le canal de commande échappe aux journaux
  3. Ce que ça change pour la détection
  4. À retenir

Ce qui se passe

Rapid7 Labs a publié un rapport sur un outillage Linux jusqu'ici non documenté, trouvé compilé directement à l'intérieur des répartiteurs de charge HAProxy de deux organisations sud-coréennes, dans l'automobile et les médias. Les attaquants ont laissé le nom de l'implant dans des chaînes de débogage : ted.

Ce n'est pas une vulnérabilité de HAProxy. L'installation suppose déjà l'exécution de code sur l'hôte et la capacité de remplacer le binaire en place. Rapid7 attribue l'outillage à des acteurs nord-coréens avec une confiance moyenne, en précisant que « d'autres éléments seraient nécessaires pour une évaluation plus définitive ».

Comment le canal de commande échappe aux journaux

Une requête vers un chemin d'image précis fait basculer le filtre en mode C2. La suite est ce qui rend l'implant intéressant : l'échange ne laisse de trace ni dans les journaux du backend, ni dans les statistiques du load balancer.

BackendStatistiquesHAProxyHAProxy(implant ted)OpérateurBackendStatistiquesHAProxyHAProxy(implant ted)Opérateurl'échange sortdes statistiquesaucune entréedans lesjournaux dubackendGET/chemin-image-declencheurdécrémente les compteurs deconnexions activesécrit la commandedans un tubenommé sous /tmpremet à zéro lecanal de requêteplus rien à transmettreHTTP/1.0 200 OK sur lasocket brute

Par ce canal, l'opérateur peut émettre une balise, téléverser et télécharger des fichiers, exécuter des commandes shell et remplacer la configuration de l'implant.

Pour la modification de pages servies aux visiteurs, quatre contrôles filtrent les requêtes : présence d'un User-Agent, correspondance d'une règle sur les motifs d'URL et de referer, puis appartenance à une liste blanche d'adresses client (vérifiée en exact puis au niveau /24) — ou une clé opérateur dans l'en-tête Accept-Language, qui court-circuite entièrement le filtrage par adresse. En sortie, l'implant réécrit le type et la longueur du contenu, force le statut à 200 et supprime l'en-tête Accept-Ranges pour qu'un client ne puisse pas demander une plage d'octets et remarquer le changement de taille.

Le reste de l'outillage suit la même discipline : le stager ne se déploie que si HAProxy ou cron tourne déjà, vérifie qu'il est root, écrase le binaire crond légitime en donnant au remplaçant l'horodatage de /usr/bin/ssh, puis efface les mots-clés tmp, wget, cron et crond de l'historique bash de root et de six journaux système, dont auth.log et audit/audit.log. S'y ajoutent un sshd trojanisé qui chiffre les mots de passe capturés, les mêmes greffes dans agetty, atd et polkitd, et un cheval de Troie d'accès distant nommé curlRAT, qui émet toutes les 12 heures par défaut, descend à 30 secondes sur ordre, et s'interrompt s'il ne trouve pas de marqueur de virtualisation.

Ce que ça change pour la détection

Les repères habituels ne servent plus : le processus attendu est là, à sa place, il écoute le bon port, et un HAProxy recompilé annonce la même chaîne de version qu'une construction propre. Rapid7 recommande la corrélation réseau indépendante, l'analyse comportementale mémoire et les contrôles d'intégrité des binaires — mais ne publie aucune règle de détection pour ce dernier point.

Deux précisions utiles. Les six domaines publiés ne résolvent plus (NXDOMAIN vérifié le 4 septembre) : ils servent à relire d'anciens journaux, pas à bloquer du trafic vivant. Et mettre HAProxy à jour ne nettoie pas un hôte déjà touché, puisque rien n'a été exploité.

Indicateurs publiés :

TEXT
img.monderhouse[.]space
img.smartnords[.]site
img.darklights[.]store
img.responsive.pstatic[.]autos
img.socialteams[.]store
img.worksongo[.]store
~/cache/haproxy-1000.cache
/var/lib/sshd/c8c68e629bba773a10ac80012d10bf19
/var/lib/snapd/g580
/tmp/jasper-log
72e70936f0dbe459142a1d867617c35f8d0cce5d18c6a49e1090a2a5adc8e558
4bb923eb040aa13ca8fd409c31ee4729c60ddff32e350efe1c5a4a9168a065f5

À retenir

Les deux victimes tournaient HAProxy 2.8.12 (8 novembre 2024), et l'implant lit les structures internes du logiciel à des décalages fixés à cette version. La branche en est aujourd'hui à 2.8.28 (27 août 2026), soit 16 versions plus loin, avec 529 bugs connus corrigés depuis — dont 1 critique et 16 majeurs. Rester sur une version de 2024 n'a pas causé cette intrusion, mais la question qu'elle pose vaut pour tout le monde : savez-vous reconstruire vos binaires compilés maison et comparer leur empreinte à celle qui tourne en production ?

Source : The Hacker News