Le 16 juillet, Hugging Face, plus grand dépôt de modèles et de jeux de données d’intelligence artificielle au monde, a révélé avoir détecté et neutralisé une intrusion dans son infrastructure de production.

C’est un jeu de données piégé, déposé sur la plateforme, et exécuté automatiquement dès son traitement par les serveurs de Hugging Face qui a servi de point d’entrée. Une fois ce premier accès obtenu, le hacker a pu récupérer des identifiants de connexion à l’infrastructure cloud de l’entreprise, puis progresser de serveur en serveur à travers plusieurs de ses clusters internes, le temps d’un week-end.

Dans son communiqué, l’entreprise précise que l’opération a été pilotée par un cadre d’agents autonomes ayant exécuté plusieurs milliers d’actions.

Mais c’est surtout dans les coulisses de l’enquête que Hugging Face tire une leçon de cet épisode : « Quand nous avons commencé l’analyse des journaux (ndlr : des connexions), nous avons d’abord utilisé des modèles frontière via des API commerciales. Cela n’a pas fonctionné. » En cause ? Les commandes d’attaque réelles nécessaires à l’analyse, toutes bloquées par les garde-fous des fournisseurs, « incapables de distinguer un analyste en réponse à incident d’un attaquant. »

Hugging Face est une plateforme où les entreprises et chercheurs déposent leurs modèles d’IA et jeux de données, pour que d’autres puissent les télécharger et les utiliser. // Source : Capture d’écran homepage Hugging Face

Le tournant open-weight

En effet, pour analyser les plus de 17 000 actions enregistrées de l’attaquant, Hugging Face s’est finalement tournée vers GLM 5.2, un modèle open weight, hébergé et exécuté directement sur sa propre infrastructure.

Selon la communication de l’entreprise, ce choix a résolu deux problèmes à la fois. D’abord, en tant que modèle « open weight », dont les poids sont librement accessibles et déployables localement, GLM 5.2 n’était pas soumis aux garde-fous automatiques des API commerciales.

Ensuite, en tournant en local, l’analyse n’a nécessité l’envoi d’aucune donnée sensible, ni les artefacts de l’attaquant ni les identifiants compromis, vers un tiers. Grâce à cette approche, Hugging Face affirme avoir reconstruit la chronologie complète de l’attaque, extrait les indicateurs de compromission et cartographié les identifiants touchés en quelques heures.

Un enseignement pour tous les défenseurs ?

Sur le plan technique, Hugging Face indique avoir corrigé les failles d’exécution de code ayant permis l’accès initial, éradiqué la présence de l’attaquant et reconstruit les nœuds compromis. L’entreprise a aussi changé tous les mots de passe et clés d’accès concernés, et par précaution, étendu cette opération à l’ensemble de ses accès sensibles. Ses équipes ont également renforcé les contrôles de sécurité sur ses clusters, fait appel à des experts en cybersécurité externes pour approfondir l’enquête, et signalé l’incident aux autorités.

Mais au-delà de ces mesures correctives, c’est surtout le recours à GLM 5.2 que Hugging Face met en avant en tirant les conclusions de cette mésaventure.

Sans remettre en cause les mesures de sécurité des modèles hébergés, Hugging Face pointe un angle mort à anticiper avant qu’un incident ne survienne : « La leçon pratique pour les défenseurs : disposer d’un modèle performant que vous pouvez faire tourner sur votre propre infrastructure, validé et prêt avant qu’un incident ne survienne, à la fois pour éviter d’être bloqué par les garde-fous et pour empêcher que les données et identifiants de l’attaquant ne quittent votre environnement. »