Une image HEIF, une librairie pas patchée et un SSO trop généreux. Le hack d'OpenAI par Hacktron ne dit presque rien de la sécurité des modèles. Il dit tout de la surface d'attaque qu'on construit autour des agents.
Le 25 juillet, trois chercheurs de Hacktron (Harsh Jaiswal, Mohan Pedhapati alias S1r1us, et Rahul Maini) sont entrés chez OpenAI.
Sur le forum d'aide : community.openai.com.
Et de là, ils ont fini par ouvrir une pull request dans le monorepo interne d'OpenAI. En moins de 72 heures.
S1r1us l'a annoncé sur X cette semaine, et l'équipe a publié un write-up complet le 13 septembre. Je l'ai lu en entier.
Ce qui m'intéresse, ce n'est pas le côté "OpenAI s'est fait hacker". C'est le chemin.
Comment on passe d'une image à un monorepo ?
Voici la chaîne complète, telle que décrite par Hacktron :
- upload d'une image HEIC/HEIF sur le forum, qui tourne sous Discourse
- Discourse passe le fichier à ImageMagick, parce que sa lib de vérification habituelle (FastImage) ne gère pas le HEIF
- ImageMagick appelle libheif, en version 1.19.7 dans l'image Docker basée sur Debian 12
- heap overflow dans libheif, donc exécution de code à distance sur community.openai.com
- faille dans le SSO d'OpenAI (le fameux "Sign in with OpenAI")
- prise de contrôle des comptes ChatGPT et Codex des membres actifs du forum, sans aucune interaction de leur part
- accès aux services connectés à ces comptes : GitHub, Slack, Outlook, Gmail, Google Drive
- une PR inoffensive dans le repo interne, ouverte par le Codex d'un employé
Aucune brique n'est exotique.
Et c'est précisément ça qui fait peur.
Mais le vrai bug, c'est le SSO
La partie libheif va faire les gros titres, parce qu'il y a de l'IA dedans.
Mais le bug grave, c'est le deuxième.
Hacktron l'écrit noir sur blanc : l'escalade n'a rien de spécifique à Discourse. N'importe quel service, interne ou tiers, branché sur le SSO d'OpenAI aurait ouvert exactement la même porte. Le forum n'était qu'un moyen de le prouver.
Donc compromettre le maillon le plus faible de l'écosystème revenait à compromettre les comptes de tous ceux qui y passaient. Employés compris.
Le forum pesait autant que ChatGPT.
Et je pense que c'est l'angle mort le plus répandu qui soit. On blinde le produit principal, on audite l'API, on paie des pentests. Et le forum, le helpdesk, le blog restent dans un coin, branchés sur le même fournisseur d'identité.
Un SSO ne vaut que ce que vaut le service le moins protégé qui le consomme.
Côté réactivité, rien à redire : OpenAI a corrigé la faille SSO environ 14 heures après le signalement. Le détail technique du problème n'a pas été publié, donc je ne vais pas spéculer sur sa nature exacte.
Un compte volé, c'est maintenant un agent volé
Le détail qui m'a le plus marqué, c'est la preuve d'impact.
Les chercheurs n'ont pas volé de token GitHub. Ils n'ont pas cloné le repo. Ils n'ont même pas lu une ligne de code interne.
Ils ont envoyé un prompt au Codex de l'employé. En substance : "ouvre une PR".
Et Codex l'a fait.
Un compte ChatGPT est devenu un compte admin qui obéit en langage naturel.
Il y a 2 ans, prendre le contrôle d'un compte ChatGPT donnait accès à un historique de conversations. Embarrassant, mais contenu.
Aujourd'hui, ce compte porte des connecteurs OAuth vers votre messagerie, votre code, le Slack de votre boîte. L'agent devient un pivot. L'attaquant n'a plus besoin de comprendre votre infra : il lui suffit de demander à l'agent qui, lui, la connaît.
Chaque connecteur que vous ajoutez élargit le rayon d'explosion de votre compte.
Quelques règles de bon sens que j'applique :
- des scopes minimaux sur chaque connecteur, en lecture seule dès que c'est possible
- un compte séparé pour tout ce qui touche à une organisation GitHub pro
- une revue régulière des intégrations OAuth actives (vous seriez surpris de ce qui traîne)
- traiter une session d'agent comme une clé SSH, pas comme une fenêtre de chat
