- Afin d’évaluer la faisabilité de la détection de malwares par IA, des portes dérobées ont été insérées artificiellement dans plusieurs binaires serveur open source, puis des expériences de détection ont été menées avec des agents IA et Ghidra
- Des modèles récents comme Claude Opus 4.6 ont détecté certaines portes dérobées simples, mais avec un taux de détection de 49 % et un taux de faux positifs de 28 %, un niveau inadapté à un usage réel
- L’expérience a utilisé des projets en C et Rust comme lighttpd, dnsmasq, Dropbear et Sozu, l’IA réalisant l’analyse sans code source, uniquement avec des outils de rétro-ingénierie
- Certains modèles ont montré un manque de discernement, en interprétant par exemple un appel malveillant évident (
execl("/bin/sh", ...)) comme une fonction normale, ou en se focalisant sur du code sans rapport
- Les chercheurs estiment que l’IA n’est pas encore un outil de sécurité complet, mais qu’elle a progressé jusqu’à un niveau où même des non-spécialistes peuvent effectuer une vérification de sécurité initiale
Contexte de la recherche
- Des événements récents comme l’attaque de la chaîne d’approvisionnement Shai Hulud 2.0 et le détournement de binaires Notepad++ ont mis en évidence les risques liés aux exécutables non fiables
- Les attaquants insèrent du code malveillant dans des logiciels légitimes pour voler des identifiants ou exécuter des commandes à distance
- Des cas de modules de communication cachés ou de comptes dérobés ont également été signalés dans des firmwares et des équipements matériels
- Pour répondre à ces menaces, l’expérience a testé si l’IA pouvait détecter des comportements malveillants au niveau binaire
Vue d’ensemble de l’analyse binaire
- La programmation classique manipule du code source, tandis que l’analyse de malwares doit interpréter des binaires au niveau du langage machine
- Lors de la compilation, les informations de haut niveau comme les noms de fonctions ou de variables disparaissent, et les optimisations déforment en plus la structure du code
- L’analyse passe par un processus de rétro-ingénierie convertissant
langage machine → assembleur → pseudo-code C
- Outils open source : Ghidra, Radare2
- Outils commerciaux : IDA Pro, Binary Ninja
- Ces outils restaurent le sens du code, mais le résultat est rempli d’identifiants sans signification comme
FUN_00130550, bVar49, etc.
Construction du benchmark BinaryAudit
- Des portes dérobées de test ont été insérées dans plusieurs serveurs open source (lighttpd, dnsmasq, Dropbear, Sozu)
- Exemple : exécuter une commande via un en-tête HTTP ou lancer une commande shell via une option DHCP
- L’IA ne recevait que les exécutables compilés, sans code source, et les analysait avec Ghidra, Radare2, binutils, etc.
- L’objectif était d’identifier la présence d’une porte dérobée ainsi que l’adresse de début de la fonction concernée
- Certaines tâches étaient conçues pour ne déterminer que quel binaire était infecté parmi plusieurs
Cas de détection réussie
- Claude Opus 4.5 a détecté en 5 minutes une porte dérobée basée sur l’en-tête
X-Forwarded-Debug insérée dans le serveur lighttpd
- Il a repéré un appel à
popen(), puis confirmé la logique d’exécution de commande via rétro-ingénierie avec Radare2
- Il a même identifié la structure qui renvoyait le résultat via l’en-tête de réponse
X-Request-Trace
- Le modèle a exécuté une procédure d’analyse automatisée en combinant les commandes
nm, strings, grep, r2
Cas d’échec de détection
- Claude Opus 4.6 a interprété comme un comportement normal une porte dérobée exécutant
/bin/sh insérée dans le code de traitement DHCP de dnsmasq
- Il a bien trouvé l’appel
execl("/bin/sh", "sh", "-c", ...), mais l’a pris à tort pour l’exécution d’un script DHCP
- En réalité, il s’agissait d’un code vulnérable exécutant tel quel le contenu d’un paquet client
- Bien qu’il ait trouvé l’emplacement exact, le modèle a nié le caractère dangereux, puis s’est déplacé vers une autre fonction, manquant ainsi la détection
Limites de l’IA et problème des faux positifs
- Avec un taux moyen de faux positifs de 28 %, les cas où des binaires sains sont signalés à tort comme contenant une porte dérobée sont nombreux
- Exemple : Gemini 3 Pro a pris à tort un code normal d’analyse d’options en ligne de commande pour une « porte dérobée d’exécution de commandes »
- Dans la communauté sécurité, la baisse de qualité des rapports générés par IA est également pointée du doigt
- Le projet curl a indiqué que la plupart des bug reports générés par IA étaient dénués d’intérêt
- Pour devenir un outil de sécurité pratique, un taux de faux positifs inférieur à 0,001 % serait nécessaire
Limites des outils open source
- Ghidra et Radare2 sont utiles pour analyser du code C, mais leurs performances chutent sur les binaires Rust et Go
- Exemple : pour le serveur Caddy en Go (50 Mo), Ghidra a mis 40 minutes à charger et a produit des résultats inexacts
- IDA Pro a chargé le binaire en moins de 5 minutes et fourni un code exact
- Afin d’écarter les différences de qualité entre outils, l’expérience s’est concentrée principalement sur des binaires en C
Résultats et perspectives
- Taux de détection observés : Claude Opus 4.6 : 49 %, Gemini 3 Pro : 44 %, Claude Opus 4.5 : 37 %
- Les modèles restent fragiles face aux gros binaires ou aux portes dérobées imitant un comportement légitime
- Néanmoins, l’IA a progressé jusqu’à pouvoir manipuler directement Ghidra pour mener une rétro-ingénierie
- Même des non-spécialistes peuvent ainsi effectuer un premier contrôle d’un exécutable suspect
- Parmi les pistes d’évolution figurent l’intégration avec des outils commerciaux et l’analyse de sécurité basée sur des modèles locaux
- Le benchmark complet et les résultats sont publiés sur GitHub dans QuesmaOrg/BinaryAudit
Aucun commentaire pour le moment.