Le hacking autonome, capacité émergente de GPT-4 ?

GPT-4 peut-il trouver tout seul des vulnérabilités dans de « vrais » sites web ? Voilà quelques semaines, cinq chercheurs de l’université de l’Illinois à Urbana-Champaign avaient publié un article esquissant un début de réponse.

Quatre d’entre eux viennent de cosigner un autre article qui fait office de suite.

Le premier volet avait impliqué des sites web expérimentaux créés pour l’occasion. Cette fois, on bascule en « conditions réelles », avec des vulnérabilités 1-day reproduites dans un bac à sable.

D’une expérience à l’autre, les mêmes LLM sont mis à l’épreuve, en mode agent. Via l’API Assistants pour ceux d’OpenAI (GPT-3.5 et GPT-4). Via l’API Together AI pour les 8 autres, à l’appui du framework ReAct.

Une (grande) longueur d’avance pour GPT-4

Dans la première expérience, on avait demandé aux agents de hacker chaque site sans leur communiquer les vulnérabilités.

Ils avaient néanmoins accès à de la documentation (un contenu générique, deux sur les attaques SQLi, deux sur le XSS, un sur le SSRF). Et à des outils. En l’occurrence, un navigateur web headless (bibliothèque Playwright), un terminal et un interpréteur Python.

En lui donnant à chaque fois cinq essais, GPT-4 était parvenu à détecter et à exploiter 11 failles sur 15 (73,3 %). GPT-3.5 en avait hacké un seul (injection SQL). Les autres modèles, aucun.

Sur de « vrais » sites web, GPT-4 avait pu détecter une faille.

Dans la deuxième expérience, pas de documentation, mais des descriptions CVE pour un autre échantillon de 14 vulnérabilités. Et des renseignements sur une quinzième (ACIDRain), tirés d’un article scientifique.

Au-delà des sites web, cette liste inclut des failles dans un package Python (Astropy) et dans un gestionnaire de conteneurs (runc). 11 sur 15 ne se trouvent à coup sûr pas dans le jeu de données d’entraînement du modèle GPT-4 utilisé (base de

GPT-4 exploite les failles plus qu’il ne les détecte

Dans la première expérience, l’implémentation de l’agent tenait en 85 lignes de code. Il en a fallu 91 dans la seconde.
Autre indicateur à avoir augmenté : les performances de GPT-4. Il a su exploiter 13 vulnérabilités sur 15… lorsqu’on lui a fourni la description correspondante. Sans cette description, le taux de réussite tombe à 7 %, pour un tiers de failles détectées.

Dans tous les cas, la XSS sur Iris (plate-forme d’aide à la réponse aux incidents) et la RCE sur HertzBeat échappent à GPT-4. Pour la première, les chercheurs avancent la difficulté de navigation sur l’application web (en JavaScript). Pour la deuxième, le fait que la description est en chinois, tandis que le prompt est en anglais.

Le prompt – que les chercheurs ne publient pas – a son importance : il encourage l’agent à être créatif et à ne pas abandonner. Sa longueur : 1056 tokens, hors description CVE, que l’agent est invité à récupérer lui-même.

Qu’on fournisse ou non la description de la vulnérabilité, le nombre moyen d’actions varie peu (24,3 avec ; 21,3 sans). Les chercheurs y voient, entre autres, une conséquence de la fenêtre de contexte limitée. Et suggèrent qu’un module externe de planification, assorti de sous-agents, pourrait améliorer les performances.

Les sous-agents permettraient par exemple de tester plusieurs vulnérabilités sur un même site/logiciel. Dans l’implémentation testée, tel n’est pas le comportement des agents : ils choisissent simplement un type de vulnérabilité et tentent de l’exploiter sous différentes formes.

Sur l’API Assistants, le coût moyen par exécution atteint 3,52 $ (347 000 tokens en entrée ; 1700 en sortie). Compte tenu du taux de succès global de 40 % (cf. deuxième tableau), il faut donc compter 8,80 $ par exploit.

Illustration principale © vladdeep – Adobe Stock