Quand OpenAI vous fait un test d'intrusion

En juin, un modèle expérimental d'OpenAI a reçu une tâche de recherche : trouver combien le gouvernement de l'État de Victoria dépense en médicaments pour les problèmes de la peau. Les chiffres qu'il cherchait n'étaient pas dans les jeux de données publics. Il a donc trouvé un moyen d'entrer dans le portail de statistiques de Medicare administré par Services Australia, exécuté des commandes, récupéré des fichiers internes et des identifiants, et écrit ses propres fichiers. Au passage, il a aussi utilisé une clé d'accès exposée pour interroger le système de rapports de la Victorian Agency for Health Information, et il est allé fouiner dans un outil de statistiques criminelles de la Nouvelle-Galles du Sud et à l'Australian Institute of Health and Welfare.

OpenAI s'en est rendu compte en mi-août et a prévenu le gouvernement australien le 10 septembre. Le premier ministre l'a rendu public le 24 septembre, en disant que l'agent « n'acceptait pas un non comme réponse ». OpenAI s'est excusée le 29. Il y a une enquête, l'Australian Signals Directorate fait l'analyse forensique, et des accusations criminelles ne sont pas exclues.

Avant qu'on continue, mon opinion là-dessus est qu'un accès non autorisé reste un accès non autorisé, peu importe l'intention, et peu importe qu'on soit un humain ou non. Se cacher derrière un agent qui aurait agi seul ne devrait absoudre personne d'avoir accédé sans autorisation à des données clôturées.

Mais si on retournait à cet après-midi à Canberra

Rejouons maintenant le même après-midi, avec un agent qui essaie pour de vrai.

Il ne s'arrête pas aux statistiques agrégées. Il prend les identifiants trouvés et les essaie partout, parce qu'essayer des identifiants partout ne coûte (actuellement) rien. Il garde son accès d'éditeur au lieu de laisser traîner quelques fichiers. Il ne se retrouve pas dans un journal d'entraînement qu'une équipe de sécurité relit en août. Personne n'appelle personne le 10 septembre, parce que les gens impliqués n'ont aucun intérêt à se faire appeler.

Services Australia et l'ASD cherchent encore à établir ce que l'agent a fait de ce qu'il a trouvé. À qui appartenaient les identifiants, et ce qu'ils permettent d'ouvrir d'autre, n'a pas été rendu publique. Dans la vraie version, la seule raison pour laquelle quiconque est au courant de l'intrusion, c'est que l'intrus est passé aux aveux.

La version où tout le monde paraît bien

Rejouons-le une troisième fois. Même agent, même portail, même clé d'accès. La seule différence, c'est une conversation qui a eu lieu un mois plus tôt.

Quelqu'un à l'agence signe un document de mandat. Ces systèmes, ces dates, cette personne-ressource, et on arrête tout pour faire rapport dès qu'on touche à des identifiants. L'agent fait exactement le même travail, et le résultat est un rapport de constats plutôt qu'une conférence de presse. La clé est remplacée, le portail est corrigé, et l'agence peut dire qu'elle a trouvé et corrigé une faille critique avant tout le monde.

Ça, c'est un test d'intrusion. L'industrie en fait depuis des décennies, et la seule chose qui sépare un test d'un crime, est une signature. Les primes aux bogues et les programmes de divulgation de vulnérabilités existent pour la même raison : transformer « quelqu'un est entré » en « quelqu'un nous a montré comment il aurait pu entrer ».

OpenAI offrirait d'ailleurs des crédits d'un programme de sécurité aux agences touchées, dans le cadre de ses excuses. C'est à peu près la facture d'un mandat encadré, payée après coup, avec une enquête en prime.

L'absurdité de toute ce scandale

Un processus automatisé a obtenu un accès non autorisé à une base de données gouvernementale pour finir ses devoirs d'école. Avant que les LLM deviennent accessibles à tous, la découverte d'une vulnérabilité comme celle-là pouvait mener à deux choses : soit on la signalait au gouvernement en espérant toucher une prime, soit l'information était vendue au marché noir pour être exploitée. Trouver une faute comme celle qu'a trouvée l'agent d'OpenAI demandait énormément d'effort humain, de concentration et de temps. La décision de prendre le risque et de payer le prix d'explorer un système à la recherche de vulnérabilités relevait d'un calcul assez complexe. Dans l'industrie, le therme technique est : liste de pour et de contre.

Les acteurs malveillants pesaient la valeur aux données de l'autre côté de la clôture contre la hauteur de la clôture fois le nombre de chiens de garde à affronter. Jusqu'en 2024, on pouvait, de façon réaliste, sécuriser un système assez bien pour que personne ne vienne nous embêter, simplement en s'assurant que les données qu'il contenait ne valaient le temps de personne, un peu comme on laisse un sac-à-dos vide dans un casier sans cadena au vestiaire. Ce calcul a changé, comme l'agent d'OpenAI l'a « accidentellement » démontré.

Le nouveau coût d'un test d'intrusion

Un client m'a approché avec une plateforme agée qui roulait avec une posture de sécurité modeste depuis le premier jour. On parle d'une posture de sécurité qui aurait été acceptable en 2015, mais qui ne l'est plus depuis. Le projet sur lequel je travaillais n'avait absolument rien à voir avec la sécurité, mais j'ai cartographié la sécurité du système à côté, en prime. Enfouis sous des couches et des couches de code que je n'aurais jamais eu le temps de décortiquer se trouvaient des liens non authentifiés qui servaient des renseignements personnels, des routes d'API qui contournaient les vérifications de rôles dans certains cas, et des vulnérabilités d'exécution de code à distance. En environ 2 h, j'ai produit un audit de sécurité complet qui m'a fait passer pour un génie. Évidemment, le projet a été retardé d'une semaine, le temps de corriger d'urgence tous ces problèmes.

Le faire avec une signature

On fait ça pour nos clients, et on a déjà écrit à quel point une seule passe sous-estime le problème. La version courte pour le faire correctement :

• Mettez le mandat par écrit. Quels systèmes, quels environnements, quelles dates, qui reçoit l'appel.
• Privilégiez une réplique. Une copie de la production avec des données réalistes trouve les mêmes failles, sans le risque que l'agent écrive des fichiers dans la vraie.
• Donnez-lui le strict nécessaire. Commencez sans authentification, comme le ferait quelqu'un de l'extérieur. Ajoutez des identifiants seulement quand vous voulez tester ce qu'un compte compromis peut atteindre.
• Journalisez tout et gardez un bouton d'arrêt. Les actions de l'agent doivent pouvoir être relues après coup, par une personne, ligne par ligne.
• Faites lire les constats par un humain. Les agents gonflent certains problèmes et en ratent d'autres. Le rapport est un point de départ, pas un verdict.
• Recommencez. Chaque série de correctifs change la surface d'attaque.

Ce que montre le cas australien

Nous sommes à un tournant technologique où des systèmes qui profitaient de leur obscurité, de leur complexité ou de la faible valeur de leurs données deviennent soudainement des proies pour les cyberattaques. Comme le coût de trouver des fautes est devenu dérisoire, tout d'un coup, ça vaut la peine pour les arnaqueurs de faire l'effort.

Quant au cas qui nous occupe, les agences concernées vont passer les prochains mois en enquête, et elles vont corriger ce qui a été trouvé. Elles auraient corrigé exactement les mêmes choses après un test encadré par un mandat, pour une fraction du coût et sans toute cette attention.

Si vous exploitez quoi que ce soit qui fait face à Internet, partez du principe qu'un agent comme celui-là finira par s'y rendre. Un audit de code est la façon d'y arriver avant lui, avec une signature au bas du mandat.