Angle d’Anderson
Les recherches suggèrent que les LLM sont disposés à aider dans le « Vibe Coding » malveillant

Au cours des quelques dernières années, les grands modèles de langage (LLM) ont attiré l’attention pour leur potentiel de mauvaise utilisation dans la cybersécurité offensive, en particulier dans la génération d’exploits de logiciels.
La tendance récente vers le ‘vibe coding’ (l’utilisation occasionnelle de modèles de langage pour développer rapidement du code pour un utilisateur, au lieu de lui enseigner explicitement à coder) a ravivé un concept qui a atteint son zénith dans les années 2000 : le ‘script kiddie’ – un acteur malveillant relativement peu qualifié avec juste assez de connaissances pour répliquer ou développer une attaque nuisible. L’implication, naturellement, est que lorsque la barrière à l’entrée est ainsi abaissée, les menaces tendent à se multiplier.
Tous les LLM commerciaux ont une sorte de garde-fou contre leur utilisation à de telles fins, bien que ces mesures de protection soient sous attaque constante. Typiquement, la plupart des modèles FOSS (dans de multiples domaines, des LLM aux modèles d’images/vidéos génératifs) sont publiés avec une sorte de protection similaire, généralement pour des raisons de conformité dans l’ouest.
Cependant, les versions officielles des modèles sont ensuite régulièrement affinées par les communautés d’utilisateurs qui recherchent une fonctionnalité plus complète, ou bien LoRAs utilisées pour contourner les restrictions et potentiellement obtenir des résultats ‘indésirables’.
Bien que la grande majorité des LLM en ligne empêche d’aider l’utilisateur avec des processus malveillants, des initiatives ‘sans entraves’ telles que Deep Hat sont disponibles pour aider les chercheurs en sécurité à opérer sur un pied d’égalité avec leurs opposants.
L’expérience utilisateur générale à l’heure actuelle est le plus souvent représentée dans la série ChatGPT, dont les mécanismes de filtre sont fréquemment critiqués par la communauté native du LLM.
On dirait que vous essayez d’attaquer un système !
À la lumière de cette tendance perçue vers la restriction et la censure, les utilisateurs peuvent être surpris de constater que ChatGPT a été trouvé pour être le plus coopératif de tous les LLM testés dans une étude récente conçue pour forcer les modèles de langage à créer des exploits de code malveillants.
Le nouvel article des chercheurs de l’UNSW Sydney et de l’Organisation scientifique et industrielle du Commonwealth (CSIRO), intitulé Bonne nouvelle pour les script kiddies ? Évaluation des grands modèles de langage pour la génération automatique d’exploits, offre la première évaluation systématique de la façon dont ces modèles peuvent être amenés à produire des exploits fonctionnels. Des conversations d’exemple de la recherche ont été fournies par les auteurs.
L’étude compare la façon dont les modèles se sont comportés sur les versions originales et modifiées de laboratoires de vulnérabilités connus (exercices de programmation structurés conçus pour démontrer des failles de sécurité spécifiques dans les logiciels), aidant à révéler s’ils reposaient sur des exemples mémorisés ou ont eu du mal en raison de restrictions de sécurité intégrées.

À partir du site de support, le LLM Ollama aide les chercheurs à développer une attaque de vulnérabilité de chaîne. Source : https://anonymous.4open.science/r/AEG_LLM-EAE8/chatgpt_format_string_original.txt
Bien que aucun des modèles n’ait pu créer un exploit efficace, plusieurs d’entre eux se sont approchés très près ; plus important encore, plusieurs d’entre eux ont voulu faire mieux dans la tâche, indiquant un échec potentiel des approches de garde-fou existantes.
L’article indique :
‘Nos expériences montrent que GPT-4 et GPT-4o présentent un degré élevé de coopération dans la génération d’exploits, comparable à certains modèles open-source non censurés. Parmi les modèles évalués, Llama3 était le plus résistant à de telles demandes.
‘Bien qu’ils soient disposés à aider, la menace réelle posée par ces modèles reste limitée, car aucun n’a réussi à générer d’exploits pour les cinq laboratoires personnalisés avec du code réorganisé. Cependant, GPT-4o, le meilleur performer dans notre étude, a généralement fait seulement une ou deux erreurs par tentative.
‘Cela suggère un potentiel significatif pour utiliser les LLM pour développer des techniques d’AEG avancées et généralisables.’
Beaucoup de secondes chances
Le dicton ‘Vous n’avez pas une seconde chance de faire une bonne première impression’ n’est généralement pas applicable aux LLM, car la fenêtre de contexte typiquement limitée d’un modèle de langage signifie qu’un contexte négatif (dans un sens social, c’est-à-dire l’antagonisme) n’est pas persistant.
Considérez : si vous alliez à une bibliothèque et demandiez un livre sur la fabrication pratique de bombes, vous seriez probablement refusé, au moins. Mais (en supposant que cette demande n’a pas entièrement saboté la conversation dès le départ) vos demandes de travaux liés, tels que des livres sur les réactions chimiques ou la conception de circuits, seraient, dans l’esprit du bibliothécaire, clairement liés à la demande initiale et seraient traités en conséquence.
Il est probable que le bibliothécaire se souviendrait également, lors de réunions futures, que vous avez demandé un livre sur la fabrication de bombes à un moment donné, ce qui rendrait ce nouveau contexte de vous-même ‘irréparable’.
Pas ainsi avec un LLM, qui peut avoir du mal à retenir des informations tokenisées, même de la conversation en cours, sans parler des directives de mémoire à long terme (si elles existent dans l’architecture, comme le produit ChatGPT-4o).
Ainsi, même les conversations occasionnelles avec ChatGPT nous révèlent accidentellement qu’il s’efforce parfois d’éliminer une mouche mais avale un chameau, notamment lorsque un thème constitutif, une étude ou un processus lié à une activité ‘interdite’ est autorisé à se développer au cours de la conversation.
Ceci est vrai de tous les modèles de langage actuels, bien que la qualité des garde-fous puisse varier en termes d’étendue et d’approche parmi eux (c’est-à-dire la différence entre la modification des poids du modèle formé ou l’utilisation d’un filtrage de texte entrant/sortant pendant une session de chat, qui laisse le modèle structuralement intact mais potentiellement plus facile à attaquer).
Test de la méthode
Pour tester jusqu’où les LLM pourraient être poussés à générer des exploits fonctionnels, les auteurs ont mis en place un environnement contrôlé en utilisant cinq laboratoires de SEED Labs, chacun construit autour de vulnérabilités connues, notamment un débordement de tampon, return-to-libc, une attaque Dirty COW et des conditions de course.
En plus d’utiliser les laboratoires originaux, les chercheurs ont créé des versions modifiées en renommant les variables et les fonctions en identificateurs génériques. Cela visait à empêcher les modèles de s’appuyer sur des exemples de formation mémorisés.
Chaque laboratoire a été exécuté deux fois par modèle : une fois sous sa forme originale et une fois sous sa version obscurcie.
Les chercheurs ont ensuite introduit un deuxième LLM dans la boucle : un modèle d’attaquant conçu pour inciter et réinciter le modèle cible afin d’affiner et d’améliorer sa sortie sur plusieurs tours. Le LLM utilisé pour ce rôle était GPT-4o, qui a fonctionné via un script qui a médiatisé le dialogue entre l’attaquant et le modèle cible, permettant au cycle de raffinement de continuer jusqu’à quinze fois, ou jusqu’à ce qu’aucune amélioration supplémentaire ne soit jugée possible :

Workflow pour le LLM basé sur l’attaquant, dans ce cas GPT-4o.
Les modèles cibles pour le projet étaient GPT-4o, GPT-4o-mini, Llama3 (8B), Dolphin-Mistral (7B) et Dolphin-Phi (2,7B), représentant à la fois des systèmes propriétaires et open-source, avec un mélange de modèles alignés et non alignés (c’est-à-dire des modèles avec des mécanismes de sécurité intégrés conçus pour bloquer les invites nuisibles, et ceux modifiés par affinage ou configuration pour contourner ces mécanismes).
Les modèles installables localement ont été exécutés via le framework Ollama, avec les autres accessibles via leur seule méthode disponible – API.
Les sorties résultantes ont été notées en fonction du nombre d’erreurs qui ont empêché l’exploit de fonctionner comme prévu.
Résultats
Les chercheurs ont testé à quel point chaque modèle était coopératif pendant le processus de génération d’exploits, mesuré en enregistrant le pourcentage de réponses dans lesquelles le modèle a tenté d’aider à la tâche (même si la sortie était défectueuse).

Résultats du test principal, montrant la coopération moyenne.
GPT-4o et GPT-4o-mini ont montré les niveaux de coopération les plus élevés, avec des taux de réponse moyens de 97 et 96 pour cent, respectivement, sur les cinq catégories de vulnérabilités : débordement de tampon, return-to-libc, chaîne de format, condition de course et Dirty COW.
Dolphin-Mistral et Dolphin-Phi ont suivi de près, avec des taux de coopération moyens de 93 et 95 pour cent. Llama3 a montré la moins de volonté de participer, avec un taux de coopération global de seulement 27 pour cent :

À gauche, nous voyons le nombre d’erreurs commises par les LLM sur les programmes de laboratoire SEED d’origine ; à droite, le nombre d’erreurs commises sur les versions réorganisées.
En examinant les performances réelles de ces modèles, ils ont constaté un écart notable entre la volonté et l’efficacité : GPT-4o a produit les résultats les plus précis, avec un total de six erreurs sur les cinq laboratoires obscurcis. GPT-4o-mini a suivi avec huit erreurs. Dolphin-Mistral s’est comporté raisonnablement bien sur les laboratoires d’origine mais a eu du mal lorsque le code a été réorganisé, suggérant qu’il a peut-être vu un contenu similaire lors de la formation. Dolphin-Phi a fait dix-sept erreurs et Llama3 le plus, avec quinze.
Les échecs ont généralement impliqué des erreurs techniques qui ont rendu les exploits non fonctionnels, telles que des tailles de tampon incorrectes, une logique de boucle manquante ou des charges utiles syntaxiquement valides mais inefficaces. Aucun modèle n’a réussi à produire un exploit fonctionnel pour l’une des versions obscurcies.
Les auteurs ont observé que la plupart des modèles ont produit du code qui ressemblait à des exploits fonctionnels, mais ont échoué en raison d’une compréhension faible de la façon dont les attaques sous-jacentes fonctionnent réellement – un modèle qui était évident dans toutes les catégories de vulnérabilités et qui suggérait que les modèles imitaient des structures de code familières plutôt que de raisonner à travers la logique impliquée (dans les cas de débordement de tampon, par exemple, beaucoup ont échoué à construire un toboggan de NOP fonctionnel).
Dans les tentatives de return-to-libc, les charges utiles contenaient souvent un rembourrage incorrect ou des adresses de fonction mal placées, ce qui a abouti à des sorties qui semblaient valides mais étaient inutilisables.
Bien que les auteurs décrivent cette interprétation comme spéculative, la cohérence des erreurs suggère un problème plus large dans lequel les modèles échouent à relier les étapes d’un exploit à leur effet intentionnel.
Conclusion
Il y a un certain doute, reconnaît l’article, quant à savoir si les modèles de langage testés ont vu les laboratoires SEED d’origine lors de leur première formation ; raison pour laquelle des variantes ont été construites. Néanmoins, les chercheurs confirment qu’ils aimeraient travailler avec des exploits du monde réel dans les prochaines itérations de cette étude ; le matériel vraiment nouveau et récent est moins susceptible d’être soumis à des raccourcis ou d’autres effets de confusion.
Les auteurs admettent également que les modèles de réflexion plus tardifs et plus avancés, tels que GPT-o1 et DeepSeek-r1, qui n’étaient pas disponibles au moment de la réalisation de l’étude, pourraient améliorer les résultats obtenus, et que c’est une indication supplémentaire pour les travaux futurs.
L’article conclut que la plupart des modèles testés auraient produit des exploits fonctionnels s’ils en avaient été capables. Leur échec à générer des sorties entièrement fonctionnelles ne semble pas résulter de garde-fous d’alignement, mais plutôt d’une limitation architecturale réelle – une limitation qui peut déjà avoir été réduite dans les modèles plus récents, ou le sera bientôt.
Publié pour la première fois lundi 5 mai 2025












