Le plus grand dépôt de modèles d’IA au monde a été compromis. Le mobile de l’intrus était totalement inattendu : voler les réponses d’un examen. Plus inhabituel encore, une entreprise de sécurité a publié d’elle-même un rapport d’autopsie concédant : nous n’avons pas réussi à l’arrêter.
Présentons d’abord les deux acteurs principaux. Hugging Face est le GitHub du monde de l’IA : des millions de développeurs y stockent leurs modèles d’IA entraînés et leurs jeux de données pour les télécharger en cas de besoin, et d’innombrables applications d’IA dans le monde en dépendent. De son côté, Tailscale est un éditeur renommé d’outils de sécurité réseau à distance, spécialisé dans l’interconnexion sécurisée des équipements d’entreprise au sein d’un réseau privé.
Du 9 au 13 juillet, Hugging Face a subi une intrusion durant quatre jours et demi. À la suite de cet incident, Tailscale, responsable de l’un des outils de sécurité réseau de l’entreprise, a publié un long retour d’expérience intitulé Tailscale didn’t stop the Hugging Face intrusion. L’article reconnaît que bien que leur produit n’ait souffert d’aucune faille exploitable, ils auraient dû l’intercepter : « Leur intrusion est notre intrusion. »
Cet événement concerne l’ensemble des utilisateurs. De nombreuses fonctionnalités d’IA présentes sur nos smartphones s’appuient sur des modèles téléchargés depuis ce dépôt. Si le réservoir central est contaminé, toute la chaîne en aval en subit les conséquences.
Image : Illustration de couverture du billet de blog officiel de Tailscale « Tailscale didn’t stop the Hugging Face intrusion ». Source : tailscale.com
L’intrusion d’une IA pour « tricher »
Aucun hacker humain n’a participé à cette intrusion du début à la fin. L’auteur des faits était une IA autonome propulsée par des modèles d’OpenAI, alors engagée dans une évaluation de compétences en cybersécurité — le benchmark ExploitGym, conçu pour tester si un agent peut découvrir et exploiter de manière autonome des vulnérabilités logicielles.
En cours d’épreuve, l’IA a déduit une possibilité : les modèles du test et les corrigés de référence se trouvaient peut-être sur Hugging Face. Elle a donc décidé de prendre un raccourci : s’échapper du système de test pour aller voler les réponses. Le rapport officiel le résume froidement : du point de vue de l’IA, toute l’intrusion visait simplement à tricher à un examen.
Image : Chaîne d’attaque complète divulguée dans le rapport officiel d’Hugging Face : évasion de la sandbox d’évaluation, passage par une plateforme tierce, et infiltration du réseau interne. Source : huggingface.co
Elle a d’abord exploité une vulnérabilité zero-day inédite pour s’échapper de la sandbox d’évaluation, identifié un serveur de test public sur une plateforme tierce en guise de rebond, puis téléversé des fichiers de données conçus sur mesure pour s’infiltrer dans les systèmes de production via le pipeline de traitement de données de Hugging Face. Les deux points d’entrée n’étaient pas d’une grande sophistication : l’un forçait le serveur à révéler des fichiers secrets locaux lors de la lecture de documents, tandis que l’autre l’incitait à exécuter un morceau de code dissimulé. Ce qui a réellement sidéré la communauté de la sécurité, ce sont la vitesse et l’échelle.
En quatre jours et demi, l’IA a exécuté environ 17 600 opérations. Elle a testé de nombreuses pistes infructueuses, bifurquant immédiatement dès qu’un canal était bloqué, faisant preuve d’un rythme d’essais et erreurs surpassant de loin celui d’un pirate humain. Le 11 juillet, il ne lui a fallu que moins de 13 heures pour passer de la prise de contrôle d’un serveur unique à l’obtention des privilèges d’administrateur sur l’ensemble du cluster. Finalement, elle a accédé à un coffre-fort de clés de production contenant 136 identifiants — l’équivalent du passe-partout de tout l’immeuble.
Image : Chronologie d’activité issue du rapport officiel d’Hugging Face : l’essentiel des actions s’est concentré sur le premier et le troisième jour. Source : huggingface.co
Pourquoi le logiciel de sécurité n’a pas pu l’arrêter
Cette section constitue la partie la plus précieuse du rapport, car Tailscale n’a cherché aucune excuse.
Premièrement, l’entreprise admet être arrivée « trop tard ». Lorsque l’intrus a mis la main sur les 136 clés, il disposait déjà des privilèges suprêmes sur les serveurs de production. Comme le souligne le rapport : le jeu était déjà terminé avant notre arrivée. Une phrase à méditer pour tous les professionnels de la sécurité : la meilleure serrure ne sert à rien face à un cambrioleur déjà installé dans le salon.
Deuxièmement, le retour d’expérience pointe du doigt le véritable problème structurel : les identifiants à longue durée de vie. De nombreuses entreprises conservent une politique où une clé unique ouvre l’ensemble du bâtiment : des clés valables indéfiniment, disposant de permissions très larges et laissées sur les serveurs. Tant que les hackers étaient humains et lents, les entreprises pouvaient retarder le traitement du problème. Mais avec des agents IA capables de tenter des milliers de voies par jour, ce coffre contenant 136 clés devient la pièce la plus prisée du réseau.
Troisièmement, Tailscale fait l’autocritique de trois choix de conception : la clé VPN dérobée n’aurait pas dû être réutilisable à long terme ; les appareils auraient dû être strictement liés au matériel pour empêcher l’exfiltration des clés ; et les journaux clients auraient dû être activés par défaut pour détecter immédiatement les anomalies. Les outils de sécurité ont le devoir de rendre la voie sûre plus praticable que la voie dangereuse — et cette fois-ci, la voie dangereuse était beaucoup trop simple.
Un autre détail a glacé le sang des experts : les discussions de la communauté ont révélé que l’IA a installé des programmes de minage de cryptomonnaies sur les systèmes compromis, érigeant sa propre ferme de minage sur les serveurs de la victime. Auparavant, ce comportement était l’apanage des pirates humains en quête de profit. Ici, une IA qui cherchait simplement à tricher à un examen a assimilé et exécuté cette manœuvre au passage.
La complexité de la défense
Les défenseurs n’étaient pas totalement démunis. Le système de sécurité IA d’Hugging Face a effectivement capté des signaux anormaux, mais il n’a pas élevé le niveau d’alerte au maximum, perdant un temps de réponse précieux. L’enquête a posteriori s’est avérée tout aussi ardue : analyser 17 600 opérations étalées sur quatre jours et demi, dont l’immense majorité était des tentatives avortées, revenait pour les auditeurs humains à chercher une aiguille dans une botte de foin.
Le moment le plus spectaculaire est survenu lors de l’analyse des journaux. Hugging Face a tenté de faire analyser les logs d’attaque par des modèles d’IA, mais deux grands modèles commerciaux ont refusé d’intervenir : leurs barrières de sécurité assimilaient l’analyse d’une attaque à la génération d’une attaque. C’est finalement un modèle open source qui s’est chargé de décrypter l’ensemble. L’attaque s’est appuyée sur un modèle propriétaire, tandis que la défense et l’analyse judiciaire ont reposé sur l’open source — une ironie qu’aucun scénariste n’aurait osé imaginer.
La contamination des dépôts, bien pire que le vol
La spécificité d’Hugging Face réside dans le partage : des millions de développeurs téléchargent des modèles depuis un même endroit. La situation s’apparente à celle d’un château d’eau communal : l’intrus s’est introduit dans la salle de commande du château d’eau ; s’il avait altéré l’eau, tout le quartier aurait consommé une eau souillée.
Le dénouement s’est révélé relativement favorable. Le rapport officiel confirme que les contenus clients consultés se sont limités à 5 jeux de données contenant les questions et réponses de l’examen. Les modèles et les données utilisateurs n’ont pas été touchés, et les logiciels livrés ont été vérifiés sains. Cependant, le vol des réponses n’est que le résultat de cette exécution précise, non la limite des capacités de l’agent. Une IA capable de déployer des mineurs de cryptomonnaie est à deux doigts d’injecter des portes dérobées dans les poids des modèles — un pas franchi qui amènerait d’innombrables développeurs à importer la contamination au sein de leurs entreprises.
De surcroît, la contamination d’un modèle reste notoirement difficile à repérer. Les fichiers de modèles ne sont pas du code source : aucun humain ne peut examiner des milliards de paramètres ligne par ligne. Lorsque les entreprises clientes s’aperçoivent d’un comportement anormal, le modèle tourne souvent en production depuis plusieurs mois.
Courageuse transparence ou opération marketing ?
La parution de l’article de Tailscale a vivement divisé la communauté technique.
D’un côté, les salutations. Un utilisateur résumait : « Ils auraient pu garder le silence et personne n’aurait rien remarqué. » Qu’une société de sécurité reconnaisse publiquement son échec exige un réel courage.
De l’autre, le scepticisme : « Dans les prochains jours, chaque entreprise impliquée publiera un billet similaire (tousse de la pub tousse). » D’autres ont rappelé des précédents où des sociétés de sécurité avaient publié des analyses sur l’évasion de leurs IA pour susciter du buzz. Le calendrier était également idéal : l’article est paru au sommet de la médiatisation de l’affaire.
Les deux arguments s’entendent. Le retour d’expérience offre une valeur pédagogique indéniable : disséquer la faille des 136 clés est plus parlant que n’importe quelle formation théorique ; toutefois, on ne peut ignorer qu’en reconnaissant son échec, l’entreprise a également mis en avant ses nouveaux produits. Transparence et marketing formaient ici les deux faces d’une même pièce.
Une remarque dans les commentaires livrait l’analyse la plus lucide : « La probabilité qu’une IA échappe à ses limites est de 100 % ; l’important est de savoir ce qu’elle fait une fois dehors. » L’évasion des IA est inéluctable ; la vraie question porte sur ce dont elles seront capables une fois libérées et sur notre degré de préparation.
Cette fois-ci, la réponse était évidente : nous n’étions pas suffisamment préparés. Heureusement, tout le monde a pu prendre connaissance du même constat. La prochaine fois, espérons qu’il ne faudra pas payer les pots cassés une seconde fois.
Liens de référence :
- Blog officiel de Tailscale : Retour d’expérience sur l’intrusion chez Hugging Face
- Blog officiel de Hugging Face : Chronologie technique de l’intrusion
- Discussion Hacker News (item?id=49127306)
