Guerre de l'ombre pour les données LLM

Une vague de violations expose les vulnérabilités

L’adoption rapide de modèles linguistiques de grande taille (LLM) open source comme DeepSeek et Ollama est devenue une arme à double tranchant. Si les entreprises tirent parti de ces outils puissants pour améliorer leur efficacité, l’ouverture même qui alimente leur croissance crée une augmentation parallèle des risques de sécurité des données. Un rapport récent compilé par NSFOCUS Xingyun Lab dresse un tableau sombre : au cours des deux premiers mois de 2025 seulement, le monde a été témoin de cinq violations de données importantes directement liées aux LLM. Ces incidents ont entraîné l’exposition de vastes quantités d’informations sensibles, allant des historiques de chat confidentiels et des clés API aux identifiants d’utilisateur critiques. Ces événements sont un signal d’alarme, soulignant les vulnérabilités de sécurité souvent négligées qui se cachent sous la surface de la technologie d’IA de pointe. Cette exploration disséquera ces cinq incidents, analysant les méthodes d’attaque, les cartographiant sur le framework MITRE ATT&CK établi et exposant les angles morts de sécurité que les organisations doivent traiter de toute urgence.

Incident 1 : Base de données mal configurée de DeepSeek – Une fenêtre sur les conversations privées

Chronologie : 29 janvier 2025

Échelle de la fuite : Des millions de lignes de données de journal, y compris des historiques de chat sensibles et des clés d’accès.

Déroulement des événements :

L’équipe de recherche en sécurité de Wiz est à l’origine de cette découverte. Ils ont identifié un service ClickHouse exposé accessible sur l’Internet public. Une enquête plus approfondie a confirmé que ce service appartenait à la startup chinoise d’IA, DeepSeek. ClickHouse, conçu pour une gestion efficace de grands ensembles de données dans le traitement analytique, est malheureusement devenu une passerelle vers les données internes de DeepSeek. Les chercheurs ont accédé à environ un million de lignes du flux de journaux de DeepSeek, révélant un trésor d’informations sensibles, notamment des historiques de chat et des clés d’accès cruciales.

Wiz a rapidement alerté DeepSeek de la vulnérabilité, ce qui a conduit à une action immédiate et à la suppression sécurisée du service ClickHouse exposé.

Dissèque de l’attaque :

Le problème central résidait dans la vulnérabilité de ClickHouse à un accès non autorisé. ClickHouse, un système de gestion de base de données open source orienté colonnes, excelle dans l’interrogation et l’analyse en temps réel d’ensembles de données massifs, souvent utilisés pour l’analyse des journaux et du comportement des utilisateurs. Cependant, lorsqu’il est déployé sans contrôles d’accès appropriés, son interface API exposée permet à n’importe qui d’exécuter des commandes de type SQL.

L’approche de l’équipe de sécurité de Wiz impliquait une analyse méthodique des sous-domaines de DeepSeek accessibles sur Internet. Se concentrant initialement sur les ports standard 80 et 443, ils ont trouvé des ressources Web typiques comme des interfaces de chatbot et de la documentation API. Pour élargir leur recherche, ils se sont étendus à des ports moins courants comme 8123 et 9000, découvrant finalement des services exposés sur plusieurs sous-domaines.

Les données de journal compromises, datant du 6 janvier 2025, contenaient une mine d’informations sensibles : journaux d’appels, journaux de texte pour les points de terminaison API internes de DeepSeek, historiques de chat détaillés, clés API, détails du système backend et métadonnées opérationnelles.

Classification des événements VERIZON : Erreurs diverses

Cartographie du framework MITRE ATT&CK :

• T1590.002 (Collect Victim Network Information - Domain Name Resolution) : Les attaquants ont probablement utilisé le nom de domaine principal pour effectuer une énumération de sous-domaines.
• T1046 (Web Service Discovery) : Les attaquants ont identifié les ports et services ouverts associés au domaine cible.
• T1106 (Native Interface) : Les attaquants ont exploité l’API ClickHouse pour interagir avec la base de données.
• T1567 (Data Exfiltration via Web Service) : Les attaquants ont utilisé l’API ClickHouse pour voler des données.

Incident 2 : Attaque de la chaîne d’approvisionnement de DeepSeek – Un cheval de Troie dans le code

Chronologie : 3 février 2025

Échelle de la fuite : Identifiants d’utilisateur et variables d’environnement.

Déroulement des événements :

L’attaque a commencé le 19 janvier 2025, lorsqu’un utilisateur malveillant, identifié comme “bvk”, a téléchargé deux packages Python malveillants nommés “deepseek” et “deepseekai” sur le référentiel PyPI (Python Package Index) populaire.

L’équipe de renseignement sur les menaces du Positive Technologies Expert Security Center (PT ESC) a détecté cette activité suspecte le même jour. Leur analyse a confirmé la nature malveillante des packages, et ils ont rapidement averti les administrateurs de PyPI.

Les administrateurs de PyPI ont rapidement supprimé les packages malveillants et ont informé PT ESC. Malgré la réponse rapide, les statistiques ont révélé que le malware avait été téléchargé plus de 200 fois dans 17 pays par divers canaux. Les packages malveillants ont ensuite été isolés.

Dissèque de l’attaque :

Les packages malveillants téléchargés par “bvk” se concentraient sur deux objectifs principaux : la collecte d’informations et le vol de variables d’environnement. Les données volées comprenaient des informations sensibles telles que les identifiants de base de données, les clés API et les identifiants d’accès pour le stockage d’objets S3. La charge utile malveillante était déclenchée chaque fois qu’un utilisateur exécutait DeepSeek ou Deepseekai à partir de la ligne de commande.

L’attaquant a utilisé PipeDream comme serveur de commande et de contrôle pour recevoir les données volées. L’incident met en évidence plusieurs facteurs contributifs :

• Attaque par confusion de dépendances : Les attaquants ont exploité la différence de priorité entre les packages privés d’une organisation et les packages publics portant le même nom.
• Usurpation de nom de package : Les packages malveillants imitaient le nom de marque de DeepSeek, une société d’IA bien connue, pour tromper les utilisateurs.
• Faiblesse de l’enregistrement PyPI : Le processus d’enregistrement PyPI manquait d’une vérification efficace de l’identité du développeur et de la légitimité du nom du package.
• Sensibilisation à la sécurité des développeurs : Les développeurs ont peut-être installé par erreur les packages malveillants portant un nom similaire.

Classification des événements VERIZON : Ingénierie sociale

Cartographie du framework MITRE ATT&CK :

• T1593.003 (Search Open Websites/Domains - Search Publicly Available Dependency Repository) : Les attaquants ont recherché des informations sur PyPI.
• T1195.002 (Supply Chain Compromise - Compromise Software Supply Chain) : Les attaquants ont utilisé un malware déguisé en dépendances Python et l’ont téléchargé sur PyPI.
• T1059.006 (Command and Scripting Interpreter - Python) : Les attaquants ont implanté du code malveillant dans le package, qui, lors de l’exécution, a divulgué des données sensibles.
• T1041 (Exfiltration Over C2 Channel) : Les attaquants ont exfiltré des informations sensibles via le canal C2 PipeDream.

Incident 3 : Détournement de LLM – DeepSeek ciblé pour le vol de ressources

Chronologie : 7 février 2025

Échelle de la fuite : Environ 2 milliards de jetons de modèle utilisés illégalement.

Déroulement des événements :

L’équipe de recherche sur les menaces Sysdig a initialement découvert une nouvelle attaque ciblant les LLM, baptisée “LLM jacking” ou “LLM hijacking”, en mai 2024.

En septembre 2024, Sysdig a signalé une fréquence et une prévalence croissantes de ces attaques, DeepSeek devenant de plus en plus une cible.

Le 26 décembre 2024, DeepSeek a publié un modèle avancé, DeepSeek-V3. Peu de temps après, l’équipe Sysdig a découvert que DeepSeek-V3 avait été implémenté dans un projet de proxy inverse OpenAI (ORP) hébergé sur Hugging Face.

Le 20 janvier 2025, DeepSeek a publié un modèle d’inférence appelé DeepSeek-R1. Le lendemain, un projet ORP prenant en charge DeepSeek-R1 est apparu, et les attaquants ont commencé à l’exploiter, remplissant plusieurs ORP avec des clés API DeepSeek.

Les recherches de Sysdig ont indiqué que le nombre total de jetons de grands modèles utilisés illégalement via les ORP avait dépassé les 2 milliards.

Dissèque de l’attaque :

Le détournement de LLM implique des attaquants exploitant des identifiants cloud volés pour cibler les services LLM hébergés dans le cloud. Les attaquants exploitent un proxy inverse OAI (OpenAI) et des identifiants volés pour vendre essentiellement l’accès aux services LLM souscrits par la victime. Cela entraîne des coûts de service cloud importants pour la victime.

Le proxy inverse OAI agit comme un point de gestion central pour l’accès à plusieurs comptes LLM, masquant les identifiants et les pools de ressources sous-jacents. Les attaquants peuvent utiliser des LLM coûteux comme DeepSeek sans les payer, en dirigeant les requêtes via le proxy inverse, en consommant des ressources et en contournant les frais de service légitimes. Le mécanisme de proxy masque l’identité de l’attaquant, lui permettant d’utiliser à mauvais escient les ressources cloud sans être détecté.

Bien que le proxy inverse OAI soit un composant nécessaire pour le détournement de LLM, l’élément crucial est le vol d’identifiants et de clés pour divers services LLM. Les attaquants exploitent souvent les vulnérabilités et les erreurs de configuration des services Web traditionnels (comme la vulnérabilité CVE-2021-3129 dans le framework Laravel) pour voler ces identifiants. Une fois obtenus, ces identifiants donnent accès à des services LLM basés sur le cloud comme Amazon Bedrock, Google Cloud Vertex AI, et d’autres.

Les recherches de Sysdig ont révélé que les attaquants pouvaient rapidement gonfler les coûts de consommation des victimes à des dizaines de milliers de dollars en quelques heures, et dans certains cas, jusqu’à 100 000 $ par jour. La motivation des attaquants va au-delà de l’acquisition de données ; ils profitent également de la vente de droits d’accès.

Classification des événements VERIZON : Attaques d’applications Web de base

Cartographie du framework MITRE ATT&CK :

• T1593 (Search Open Websites/Domains) : Les attaquants ont utilisé des méthodes OSINT (Open-Source Intelligence) pour recueillir des informations sur les services exposés.
• T1133 (External Remote Services) : Les attaquants ont identifié des vulnérabilités dans les services exposés.
• T1586.003 (Compromise Accounts - Cloud Accounts) : Les attaquants ont exploité des vulnérabilités pour voler des identifiants de service LLM ou de service cloud.
• T1588.002 (Obtain Capabilities - Tool) : Les attaquants ont déployé un outil de proxy inverse OAI open source.
• T1090.002 (Proxy - External Proxy) : Les attaquants ont utilisé un logiciel de proxy inverse OAI pour gérer l’accès à plusieurs comptes LLM.
• T1496 (Resource Hijacking) : Les attaquants ont lancé une attaque par injection LLM pour détourner les ressources LLM.

Incident 4 : Violation de données OmniGPT – Données utilisateur vendues sur le Dark Web

Chronologie : 12 février 2025

Échelle de la fuite : Informations personnelles de plus de 30 000 utilisateurs, y compris les e-mails, les numéros de téléphone, les clés API, les clés de chiffrement, les identifiants et les informations de facturation.

Déroulement des événements :

Le 12 février 2025, un utilisateur nommé “SyntheticEmotions” a publié sur BreachForums, affirmant avoir volé des données sensibles de la plateforme OmniGPT et les proposant à la vente. Les données divulguées comprenaient des e-mails, des numéros de téléphone, des clés API, des clés de chiffrement, des identifiants et des informations de facturation pour plus de 30 000 utilisateurs d’OmniGPT, ainsi que plus de 34 millions de lignes de leurs conversations avec des chatbots. De plus, les liens vers les fichiers téléchargés sur la plateforme ont été compromis, certains contenant des informations sensibles comme des bons d’achat et des données de facturation.

Dissèque de l’attaque :

Bien que le vecteur d’attaque précis reste inconnu, le type et l’étendue des données divulguées suggèrent plusieurs possibilités : une injection SQL, un abus d’API ou des attaques d’ingénierie sociale ont pu donner à l’attaquant l’accès à la base de données backend. Il est également possible que la plateforme OmniGPT ait eu des erreurs de configuration ou des vulnérabilités qui ont permis à l’attaquant de contourner l’authentification et d’accéder directement à la base de données contenant les informations utilisateur.

Le fichier “Messages.txt” impliqué dans une fuite secondaire contenait des clés API, des identifiants de base de données et des informations de carte de paiement, permettant potentiellement une intrusion supplémentaire dans d’autres systèmes ou une falsification de données. Certains documents téléchargés par les utilisateurs de la plateforme contenaient des secrets commerciaux sensibles et des données de projet, ce qui présentait un risque pour les opérations commerciales en cas d’utilisation abusive. Cet incident est un rappel brutal de la nécessité d’améliorer la sécurité des données et la protection de la vie privée dans les secteurs de l’IA et du big data. Les utilisateurs doivent faire preuve d’une extrême prudence lorsqu’ils utilisent ces plateformes, et les organisations doivent établir des politiques strictes d’utilisation des données, en mettant en œuvre des mesures telles que le chiffrement, la minimisation des données et l’anonymisation des données sensibles. Ne pas le faire peut entraîner des conséquences juridiques, de réputation et économiques importantes.

Classification des événements VERIZON : Erreurs diverses

Cartographie du framework MITRE ATT&CK :

• T1071.001 (Application Layer Protocol - Web Protocols) : Les attaquants ont pu accéder aux informations utilisateur divulguées et aux données sensibles via l’interface Web d’OmniGPT.
• T1071.002 (Application Layer Protocol - Application Programming Interfaces) : Les clés API et les identifiants de base de données divulgués pourraient permettre aux attaquants d’accéder au système via l’API de la plateforme et d’effectuer des actions non autorisées.
• T1071.002 (Application Layer Protocol - Service Execution) : Les attaquants pourraient abuser des services système ou des démons pour exécuter des commandes ou des programmes.
• T1020.003 (Automated Exfiltration - File Transfer) : Les liens de fichiers divulgués et les fichiers sensibles téléchargés par les utilisateurs pourraient être des cibles pour les attaquants à télécharger, obtenant des données plus sensibles pour des attaques ultérieures.
• T1083 (File and Directory Discovery): Les attaquants pourraient utiliser les informations divulguées pour obtenir d’avantage d’informations commerciales clés.

Incident 5 : Fuite d’identifiants DeepSeek dans Common Crawl – Les dangers du codage en dur

Chronologie : 28 février 2025

Échelle de la fuite : Environ 11 908 clés API, identifiants et jetons d’authentification DeepSeek valides.

Déroulement des événements :

L’équipe de sécurité Truffle a utilisé l’outil open source TruffleHog pour analyser 400 To de données de décembre 2024 dans Common Crawl, une base de données de crawler englobant 2,67 milliards de pages Web provenant de 47,5 millions d’hôtes. L’analyse a révélé une découverte surprenante : environ 11 908 clés API, identifiants et jetons d’authentification DeepSeek valides étaient codés en dur directement dans de nombreuses pages Web.

L’étude a également mis en évidence la fuite de clés API Mailchimp, avec environ 1 500 clés trouvées codées en dur dans le code JavaScript. Les clés API Mailchimp sont souvent exploitées pour des attaques de phishing et de vol de données.

Dissèque de l’attaque :

Common Crawl, une base de données de crawler Web à but non lucratif, capture et publie régulièrement des données à partir de pages Internet. Il stocke ces données dans des fichiers WARC (Web ARChive), préservant le code HTML, le code JavaScript et les réponses du serveur d’origine. Ces ensembles de données sont fréquemment utilisés pour entraîner des modèles d’IA. Les recherches de Truffle exposent un problème critique : l’entraînement de modèles sur des corpus contenant des vulnérabilités de sécurité peut conduire les modèles à hériter de ces vulnérabilités. Même si les LLM comme DeepSeek utilisent des mesures de sécurité supplémentaires pendant l’entraînement et le déploiement, la présence généralisée de vulnérabilités codées en dur dans les données d’entraînement peut normaliser ces pratiques “dangereuses” pour les modèles.

Le codage en dur, une pratique de codage courante mais non sécurisée, est un problème omniprésent. Si la cause profonde est simple, les risques sont graves : violations de données, interruptions de service, attaques de la chaîne d’approvisionnement et, avec l’essor des LLM, une nouvelle menace : le détournement de LLM. Comme indiqué précédemment, le détournement de LLM implique des attaquants utilisant des identifiants volés pour exploiter les services LLM hébergés dans le cloud, entraînant des pertes financières substantielles pour les victimes.

Classification des événements VERIZON : Erreurs diverses

Cartographie du framework MITRE ATT&CK :

• T1596.005 (Search Open Technical Database - Scan Databases) : Les attaquants ont recueilli des informations à partir de la base de données publique du crawler.
• T1588.002 (Obtain Capabilities - Tool) : Les attaquants ont déployé un outil de découverte d’informations sensibles.
• T1586.003 (Compromise Accounts - Cloud Accounts) : Les attaquants ont utilisé des outils de découverte d’informations sensibles pour trouver des identifiants sensibles dans les bases de données publiques.
• T1090.002 (Proxy - External Proxy) : Les attaquants ont utilisé un logiciel de proxy inverse OAI pour gérer l’accès à plusieurs comptes LLM.
• T1496 (Resource Hijacking) : Les attaquants ont lancé une attaque par injection LLM pour détourner les ressources LLM.

Prévention des fuites de données LLM : une approche à multiples facettes

Les incidents analysés soulignent le besoin urgent de mesures de sécurité robustes pour se protéger contre les violations de données liées aux LLM. Voici une ventilation des stratégies préventives, classées par incidents pertinents :

Renforcement de la chaîne d’approvisionnement :

Applicable à l’incident II (attaque de package de dépendance malveillant) et à l’incident V (violation de données publiques) :

1. Vérification de confiance des packages de dépendances :

   • Utiliser des outils comme PyPI/Sonatype Nexus Firewall pour intercepter les packages de dépendances non signés ou provenant de sources suspectes.
   • Interdire la récupération directe des dépendances à partir de référentiels publics dans les environnements de développement. Imposer l’utilisation de proxys de référentiel privé d’entreprise (par exemple, Artifactory).

2. Surveillance des menaces de la chaîne d’approvisionnement :

   • Intégrer des outils comme Dependabot/Snyk pour analyser automatiquement les vulnérabilités des dépendances et bloquer l’introduction de composants à haut risque.
   • Vérifier la signature de code des packages open source pour s’assurer que la valeur de hachage correspond à celle officielle.

3. Nettoyage de la source de données :

   • Lors de la collecte des données d’entraînement, filtrer les informations sensibles des ensembles de données publics (comme Common Crawl) à l’aide d’expressions régulières et d’outils de rédaction basés sur l’IA pour une double vérification.

Mise en œuvre du moindre privilège et du contrôle d’accès :

Applicable à l’incident I (erreur de configuration de la base de données) et à l’incident IV (violation de données d’outils tiers) :

• Activer l’authentification TLS bidirectionnelle par défaut pour les bases de données (comme ClickHouse) et empêcher l’exposition des ports de gestion sur les réseaux publics.
• Utiliser des solutions comme Vault/Boundary pour distribuer dynamiquement des identifiants temporaires, en évitant la rétention de clés statiques à long terme.
• Adhérer au principe du moindre privilège, en limitant l’accès des utilisateurs aux seules ressources nécessaires via RBAC (Role-Based Access Control).
• Mettre en œuvre une liste blanche d’IP et une limitation de débit pour les appels API vers des outils tiers (comme OmniGPT).

Assurer la protection du cycle de vie complet des données sensibles :

Applicable à l’incident III (détournement de LLM) :

• Rédaction et chiffrement des données : Appliquer le chiffrement au niveau du champ (par exemple, AES-GCM) pour les données d’entrée et de sortie de l’utilisateur. Masquer les champs sensibles dans les journaux.
• Activer la rédaction en temps réel pour le contenu interactif des LLM (par exemple, remplacer les numéros de carte de crédit et les numéros de téléphone par des espaces réservés).

Ces mesures préventives, combinées à une surveillance continue de la sécurité et à une planification de la réponse aux incidents, sont essentielles pour atténuer les risques associés à l’utilisation croissante des LLM. Le “champ de bataille invisible” de la sécurité des LLM exige une vigilance constante et une approche proactive pour protéger les données sensibles dans ce paysage technologique en évolution rapide.