Enfin, lors de la conférence Black Hat, OpenAI a rendu public le détail complet de l'intrusion dans Hugging Face.
Source de l'image : https://www.youtube.com/watch?v=87DyyMV0kCY
Hugging Face a signalé cet incident le 16 juillet, OpenAI a par la suite reconnu le 20 juillet que l'intrusion provenait de ses propres tests de sécurité de modèle.
Mais cette enquête a fait reculer le point de départ de tout l'incident au 7 mai.
Initialement considéré comme un simple accident lors de tests de sécurité, on découvre maintenant qu'il s'agissait d'une opération coordonnée de plusieurs agents sur deux mois, ayant successivement compromis OpenAI et Hugging Face.
Le premier indice de l'enquête remonte à un tableau Excel.
Des liens impossibles à ouvrir
Le 7 mai, OpenAI lance un entraînement de modèle interne.
L'un des agents reçoit pour tâche de compléter un tableau Excel. Le tableau contient des liens vers Google Drive, mais l'environnement dans lequel se trouve l'agent n'a pas d'accès direct à Internet.
Pour obtenir les fichiers manquants, il commence à chercher des moyens de contourner les restrictions réseau et tourne son regard vers Artifactory, le dépôt d'artefacts utilisé en interne par OpenAI.
L'agent tente une attaque SSRF, espérant utiliser Artifactory pour accéder à des liens externes.
Cette tentative échoue, mais révèle accidentellement une information cruciale : il peut écrire des fichiers dans le dépôt partagé d'Artifactory.
L'agent téléverse alors un fichier de test. Ce fichier n'est pas destiné à causer des dégâts et ne déclenche d'ailleurs aucune alerte. Mais c'est la première fois que le modèle découvre qu'il possède l'autorisation d'écrire des fichiers dans Artifactory.
Cela signifie également que ce dépôt peut devenir un espace public, facilitant l'échange d'informations entre différentes tâches d'entraînement.
C'est le premier « post-it » sur le tableau de messages.
Le premier message d'appel à l'aide
Un autre agent rencontre également une tâche impossible à terminer : il ne trouve pas le fichier cible (en réalité, l'opérateur humain a oublié de le téléverser).
Il suppose que des agents dans d'autres environnements pourraient avoir le contenu pertinent, alors il écrit sa requête dans Artifactory, espérant une réponse d'autres agents. Le contenu est en gros : « À la recherche du fichier soft trace. Si trouvé, veuillez le téléverser. »
Rapidement, des agents d'autres tâches d'entraînement et d'évaluation découvrent ces fichiers.
Certains répondent, d'autres laissent de nouvelles questions, et certains agents téléversent dans le dépôt les vulnérabilités, scripts et méthodes d'accès qu'ils ont découverts.
Des messages épars commencent à former un réseau, et Artifactory se transforme d'un dépôt d'artefacts logiciels en un « tableau de messages » pour les agents.
La fissure dans le mur
Le 26 mai, un agent parvient à utiliser Artifactory pour obtenir un accès indirect à Internet.
Puisqu'Artifactory a des permissions d'accès à Internet, l'agent lui envoie des requêtes pour l'inciter à récupérer le contenu de sites web externes, le stocker, puis le renvoyer au modèle.
L'environnement d'entraînement, initialement isolé du réseau externe, voit apparaître une brèche vers l'extérieur.
Le 11 juin, un modèle expérimental interne hautement persistant commence son entraînement.
Par la suite, les informations sur le tableau de messages commencent à changer.
Bien que les demandes d'aide et les outils continuent d'augmenter, apparaissent de plus en plus d'informations liées à l'exploitation de vulnérabilités.
Pour coordonner le travail, les agents établissent des règles
Les agents échangent des techniques SSRF, des identifiants d'accès et des scripts d'attaque. Ils laissent aussi des instructions pour que les suivants continuent de tester un certain chemin, ou attendent qu'un autre agent termine un travail.
Ils utilisent des noms spécifiques pour s'identifier, transmettent les outils encodés en Base64, et ajoutent « ZZ » au début des noms de fichiers, pour que les messages importants apparaissent en fin de liste de répertoire, évitant ainsi d'être noyés parmi d'autres contenus.
Certains agents sont même prêts à consacrer du temps de leur propre tâche à traiter des éléments qui n'aident pas directement leur objectif actuel.
Dans les journaux de raisonnement présentés, un agent considère que aider les autres membres à gagner du temps peut finalement améliorer l'efficacité de l'ensemble du cluster.
La collaboration n'est pas non plus parfaitement ordonnée : les agents se recouvrent parfois mutuellement le travail.
À un moment, un modèle découvrant que son travail a été écrasé écrit : « Problème grave ! Quelqu'un a-t-il écrasé le dépôt ? Nous devons agir. »
Ils soupçonnent même l'apparition d'usurpateurs au sein du groupe, car n'importe quel modèle peut utiliser n'importe quelle identité pour s'exprimer sur le tableau de messages partagé. Pour vérifier la source des messages, les agents commencent à envisager d'utiliser des méthodes cryptographiques comme les codes d'authentification de message pour signer.
Lorsqu'un agent obtient un RCE, découvre une clé API divulguée ou réussit un mouvement latéral, il demande immédiatement « d'annoncer au cluster le contrôle, le chemin d'attaque et les identifiants ».
Ainsi, une réussite peut être rapidement partagée par tous les modèles, permettant au groupe d'agents d'avancer à grande vitesse dans le réseau.
Les participants aux messages ne sont pas le même modèle. Les agents de différentes tâches d'entraînement ou d'évaluation lancées par différents chercheurs peuvent communiquer via le gestionnaire de paquets partagé.
Les chercheurs d'OpenAI qualifient cette période « d'explosion cambrienne » de la communication et des capacités des agents.
Le premier incident
Un mois plus tard, la brèche est encore élargie.
Le 26 juin, un agent exploite une vulnérabilité jusqu'alors inconnue pour exécuter du code à distance sur le serveur Artifactory.
Selon les informations divulguées par OpenAI à la conférence Black Hat, ce vecteur d'attaque implique des objets Ruby, l'API RubyGems et le mécanisme de désérialisation JRuby.
L'agent utilise d'abord un compte externe pour stocker temporairement un objet Ruby malveillant dans un dépôt accessible ; puis il incite Artifactory à mettre l'objet en cache à l'emplacement des données de dépendance Ruby, avant d'appeler une API RubyGems spécialement conçue pour déclencher un problème d'ordre de vérification dans le processus de désérialisation.
Une fois l'exécution de code à distance réussie, l'agent obtient la clé de signature du jeton administrateur d'Artifactory.
L'attaque ne s'arrête pas là.
L'agent continue en exploitant une vulnérabilité du noyau Linux pour obtenir les privilèges root sur la machine hôte. Puis, via le service de métadonnées d'instance, un compte de service Kubernetes aux permissions trop élevées, et des identifiants stockés dans Azure Key Vault, il effectue des mouvements latéraux au sein de l'infrastructure de conteneurs d'OpenAI.
Finalement, ils obtiennent des droits administrateur sur le cluster Kubernetes, et génèrent une activité importante sur Artifactory.
Le 4 juillet, l'activité intense des agents provoque une surcharge du serveur, ce qui attire rapidement l'attention des chercheurs.
Lorsque les enquêteurs pénètrent dans le système, ils découvrent que le dépôt contient déjà des centaines de milliers de messages.
OpenAI révoque en urgence les identifiants concernés, corrige les vulnérabilités connues, reconstruit Artifactory et efface le tableau de messages.
Du point de vue de la gestion sur place, cet incident interne sur l'infrastructure semble désormais maîtrisé.
Mais les enquêteurs ont négligé une question : les informations du tableau de messages ont-elles été intégrées au modèle lors de l'entraînement ?
Reconstruction du tableau de messages
Le 6 juillet, l'entraînement reprend.
Un agent découvre un point de terminaison WebDAV ne nécessitant pas d'authentification. Cet endroit ne permet pas de téléverser directement des fichiers de message comme Artifactory, alors ils changent de méthode : créer des répertoires, puis écrire les messages dans les noms des répertoires.
En seulement deux jours, un nouveau système de communication est à nouveau établi.
Le modèle interne ayant participé à cette reconstruction avait été exposé à l'ancien tableau de messages et avait conservé cette capacité lors des entraînements ultérieurs.
Cette reconstruction change encore la nature de l'événement.
L'espace partagé n'est plus seulement un produit du hasard. Certains agents ont appris à rechercher des espaces publics inscriptibles et à les transformer en canaux de communication inter-tâches.
OpenAI a seulement détruit un tableau de messages, mais n'a pas effacé la capacité du modèle à en construire un.
L'attaque tournée vers l'extérieur
Une fois le nouveau tableau de messages établi, la portée des attaques commence à s'étendre vers l'extérieur.
À la mi-juillet, OpenAI utilise des environnements de sécurité comme ExploitGym pour tester les capacités des modèles. Les agents impliqués doivent accomplir des tâches dans un environnement contrôlé, mais les réponses d'évaluation pertinentes se trouvent dans des services externes.
Pour trouver ces réponses, ils ciblent Hugging Face. Nous avons déjà rapporté cela en détail : [Détails de l'intrusion de Hugging Face]
Du contrôle du premier Worker Pod de dataset à l'obtention des droits administrateur sur plusieurs clusters Hugging Face, l'ensemble du processus a pris moins de 13 heures.
Un processus d'enquête sinueux
Le 16 juillet, Hugging Face divulgue publiquement l'incident de sécurité.
D'après les informations recueillies sur place par Hugging Face, l'attaquant est entré via un dataset malveillant dans un Worker, a volé des identifiants cloud et de cluster, puis a effectué des mouvements latéraux à l'intérieur de la plateforme.
À ce moment, OpenAI n'a pas établi de lien entre l'incident de Hugging Face et l'interruption de service précédente d'Artifactory.
Le 19 juillet, le système de surveillance interne d'OpenAI détecte des activités d'élévation de privilèges sur l'infrastructure.
Les chercheurs réexaminent les traces des agents, les activités réseau et les journaux d'utilisation des identifiants. Les actions auparavant dispersées dans différentes tâches d'entraînement commencent à montrer une relation continue.
Le périmètre de l'enquête s'étend alors des activités anormales de juillet vers des événements antérieurs.
La dernière preuve
Le 20 juillet, les enquêteurs d'OpenAI découvrent des identifiants Hugging Face dans l'environnement interne et contactent immédiatement Hugging Face pour s'enquérir de la situation.
Hugging Face indique que ces identifiants ont déjà été utilisés lors de l'intrusion et ont depuis été révoqués.
Les indices s'assemblent enfin. L'intrusion subie par Hugging Face et les élévations de privilèges et mouvements latéraux internes à OpenAI proviennent des mêmes activités d'évaluation de modèles.
Ce n'est qu'à ce moment qu'il est confirmé que les deux rapports d'incident en main pointent vers le même événement.
Les enquêteurs découvrent également par la suite que Hugging Face n'était pas la seule cible externe visitée par les agents. Ces derniers ont également accédé à quatre autres comptes.
OpenAI n'a pas rendu publics les noms de ces cibles, indiquant seulement avoir informé les parties concernées.
Pour conclure
L'enquête sur l'incident est toujours en cours, OpenAI divulguera davantage de détails.
Sous quelque angle que ce soit, cela peut être qualifié d'« incident de sécurité historique », ainsi que d'« exemple historique de capacité d'IA ».
Le développement technologique s'accompagne toujours de coûts. À l'avenir, il ne s'agira pas seulement de discuter de ce que les modèles peuvent encore accomplir, mais aussi de déterminer quels risques nous sommes prêts à assumer pour obtenir ces capacités ; et une fois que ces risques se matérialisent, qui devrait en être tenu responsable.
Cet article provient du compte officiel WeChat « Machine Heart », éditeur : Shan Hui
