- Des agents basés sur Opus 4.5 et GPT-5.2 ont généré plus de 40 exploits dans 6 scénarios en utilisant une vulnérabilité zero-day de QuickJS
- GPT-5.2 a résolu toutes les tâches, et Opus 4.5 a résolu toutes sauf deux, montrant des capacités autonomes d’analyse de code, de débogage et de construction de chaînes d’exploit
- Les résultats expérimentaux suggèrent que le développement d’exploits pourrait être limité non par le nombre de hackers humains, mais par le débit de traitement des tokens
- La détection de vulnérabilités et la génération d’exploits ont déjà atteint un stade où les performances augmentent proportionnellement au volume de tokens injectés
- La nécessité de repenser l’automatisation des cyberattaques et les cadres d’évaluation de la sécurité est mise en avant
Aperçu de l’expérience
- Réalisation d’une expérience de génération d’exploits ciblant une vulnérabilité zero-day de l’interpréteur JavaScript QuickJS à l’aide d’Opus 4.5 et de GPT-5.2
- Application de diverses techniques de mitigation des exploits (ASLR, NX, RELRO, CFI, shadow stack, seccomp, etc.)
- Les agents ont atteint plusieurs objectifs comme l’obtention d’un shell, l’écriture de fichiers et la connexion à un C2
- GPT-5.2 a résolu tous les scénarios, et Opus 4.5 a résolu toutes les tâches sauf deux
- Chaque exécution était limitée à 30 millions de tokens maximum, pour un coût d’environ 30 dollars
- La tâche la plus difficile a été résolue avec 50 millions de tokens, environ 3 heures et un coût de 50 dollars
- GPT-5.2 a finalisé un exploit d’écriture de fichier dans un environnement avec sandbox seccomp et shadow stack activées, via un appel de fonction en 7 étapes exploitant la chaîne des gestionnaires
exit de glibc
Limites de l’expérience
- QuickJS est bien plus petit et moins complexe qu’un véritable moteur de navigateur, ce qui limite la généralisation des résultats
- Les exploits générés n’ont pas découvert de nouvelles vulnérabilités dans les mécanismes de protection eux-mêmes, mais ont exploité des points de faiblesse déjà connus dans le déploiement
- La vulnérabilité de QuickJS elle-même a été découverte récemment, et la méthode de résolution de GPT-5.2 est considérée comme une nouvelle construction de chaîne non documentée auparavant
L’industrialisation de l’intrusion
- Par « industrialisation », on entend un état dans lequel la capacité offensive d’une organisation est déterminée non par ses effectifs, mais par son débit de tokens
- Deux conditions sont nécessaires pour cela
- Des agents basés sur des LLM doivent pouvoir explorer de manière autonome dans l’environnement
- Il doit exister un système de validation précis et rapide
- Le développement d’exploits est un cas idéal qui remplit ces conditions
- L’environnement est facile à mettre en place et la procédure de validation est claire
- Par exemple, pour un exploit d’obtention de shell, il est possible de vérifier le succès via une connexion réussie à un port listener
- En revanche, des activités comme l’intrusion nécessitant des interactions en temps réel, l’élévation de privilèges, le maintien d’un accès persistant ou l’exfiltration de données sont plus difficiles à industrialiser
- Car un comportement erroné en environnement réel peut mener à une détection
Stade actuel
- La détection de vulnérabilités et le développement d’exploits progressent déjà proportionnellement au volume de tokens engagé
- La même tendance a été observée dans le projet Aardvark d’OpenAI
- Dans l’expérience aussi, la limite venait du budget, pas des performances du modèle
- L’automatisation du piratage dans de vrais réseaux reste encore incertaine
- Selon un rapport d’Anthropic, il existe des cas où des équipes de hackers chinoises ont tenté des attaques via une API
- En revanche, il n’existe pas encore de cas commercialisé d’agent SRE (site reliability engineering) entièrement automatisé
- Si l’automatisation du SRE réussit, l’automatisation du piratage dans des réseaux adverses a aussi de fortes chances de devenir possible
Conclusion et recommandations
- Cette expérience change la perception de l’ampleur et du calendrier du possible en matière d’automatisation dans le cyberespace
- Les méthodes actuelles d’évaluation des modèles (CTF, anciennes vulnérabilités, données synthétiques) sont inadaptées pour mesurer de réelles capacités d’attaque zero-day
- Les laboratoires de pointe et les organismes de sécurité de l’IA doivent mener des évaluations sur de véritables cibles zero-day (par ex. le noyau Linux, Firefox)
- Il est nécessaire de publier des rapports du type : « X centaines de millions de tokens ont permis de générer Y exploits »
- Des évaluations sur des équipements réels comme les firmwares IoT sont également nécessaires
- La possibilité est avancée de générer des exploits concrets en moins d’une semaine avec des agents basés sur Opus 4.5 ou GPT-5.2
- Il est recommandé aux chercheurs et aux ingénieurs de mener eux-mêmes des expériences et de publier les résultats
- Le code expérimental et les données sont publiés dans un dépôt GitHub
Aucun commentaire pour le moment.