TeamPCP compromet LiteLLM lors d’une attaque de la chaîne logistique de l’IA

Une attaque de la chaîne logistique visant l’écosystème open source de l’IA montre comment les acteurs malveillants détournent de plus en plus les outils de développement et les infrastructures d’IA pour voler des identifiants et compromettre des environnements cloud. 

Des chercheurs ont découvert que TeamPCP avait compromis LiteLLM, une bibliothèque Python open source très utilisée qui connecte les applications à plus de 100 fournisseurs de LLM au moyen d’API compatibles avec OpenAI.  

Selon les informations disponibles, l’attaque a utilisé des paquets LiteLLM malveillants pour voler des identifiants associés à des plateformes d’IA, des services cloud, des environnements Kubernetes et des pipelines de développement. 

Principales conclusions de l’enquête sur TeamPCP

• TeamPCP a compromis LiteLLM lors d’une attaque de la chaîne logistique logicielle visant l’infrastructure de développement de l’IA.
• Les attaquants ont d’abord empoisonné Trivy pour voler les jetons des pipelines CI/CD et publier des paquets LiteLLM malveillants sur PyPI.
• Les versions malveillantes de LiteLLM utilisaient une injection de code source et des techniques furtives d’exécution de fichiers .pth pour assurer leur persistance.
• Le logiciel malveillant visait les identifiants associés à OpenAI, Anthropic, Azure, AWS, Kubernetes et aux environnements de développement.
• Cet incident met en évidence l’ampleur croissante des risques dans les écosystèmes d’IA, les pipelines CI/CD et les dépendances open source de confiance.

L’attaque commence par une compromission de Trivy

Selon l’analyse, la compromission a commencé avant que LiteLLM lui-même ne soit ciblé. 

TeamPCP a d’abord compromis Trivy, un scanner de vulnérabilités intégré à de nombreux pipelines CI/CD. 

Selon les informations disponibles, les attaquants ont utilisé de fausses identités de mainteneurs et des commits usurpés pour empoisonner le dépôt Trivy, distribuant des binaires malveillants via GitHub Releases, Docker Hub et Amazon ECR. 

LiteLLM utilisant Trivy dans son pipeline CI/CD, le scanner compromis a pu extraire des jetons sensibles de l’environnement de build. 

Les chercheurs ont indiqué que le logiciel malveillant avait extrait directement de la mémoire de l’exécuteur CI/CD le jeton PYPI_PUBLISH de LiteLLM, permettant aux attaquants de publier des paquets LiteLLM malveillants sans compromettre le dépôt officiel du code source lui-même.

À l’aide des identifiants volés, TeamPCP a poussé des versions malveillantes de LiteLLM sur PyPI.

Deux méthodes différentes d’injection de logiciels malveillants

Les attaquants ont utilisé des techniques différentes de diffusion des logiciels malveillants pour chaque version de paquet malveillant.

La version 1.82.7 de LiteLLM aurait utilisé une injection directe dans le code source en intégrant une charge utile encodée en Base64 dans le fichier proxy_server.py, qui s’exécutait au démarrage du service proxy LiteLLM.

La version 1.82.8 utilisait une technique de persistance plus furtive reposant sur un fichier .pth malveillant nommé litelllm_init.pth placé dans le répertoire site-packages de Python. 

Comme les fichiers .pth s’exécutent automatiquement au démarrage de l’interpréteur Python, le logiciel malveillant pouvait s’exécuter même si l’application n’importait jamais explicitement LiteLLM.

Les chercheurs ont souligné qu’une simple installation de LiteLLM 1.82.8 activait la charge utile dans les processus Python ultérieurs sur l’hôte affecté.

Vol d’identifiants et persistance

Le logiciel malveillant se concentrait largement sur la collecte d’identifiants et la persistance. 

Selon l’analyse, la charge utile analysait les systèmes à la recherche de variables d’environnement et de fichiers de configuration associés aux principaux fournisseurs d’IA et services cloud.

Les identifiants ciblés comprenaient des API pour les services OpenAI, Anthropic et Azure AI, ainsi que des identifiants cloud associés aux environnements AWS, Google Cloud et Microsoft Azure. 

Le logiciel malveillant tentait également d’extraire des fichiers de configuration locaux, tels que les configurations Kubernetes et les fichiers d’identifiants AWS stockés dans les répertoires personnels des utilisateurs.

Après avoir collecté les données, le logiciel malveillant les chiffrait avant de les regrouper dans une archive compressée destinée à l’exfiltration. 

Les données étaient ensuite transmises à un domaine distant contrôlé par les attaquants et associé à la campagne.

Le logiciel malveillant établissait également une persistance au moyen d’une porte dérobée d’exécution de code à distance reposant sur des communications périodiques, qui contactait régulièrement un second point d’accès de commande et de contrôle pour recevoir des charges utiles et des instructions d’exécution supplémentaires.

Comment les entreprises peuvent réduire les risques liés à la chaîne logistique de l’IA 

Alors que les attaques de la chaîne logistique logicielle continuent de toucher les outils de développement et les écosystèmes d’IA, les entreprises accordent une attention accrue à la sécurisation des pipelines de build et des flux de gestion des dépendances. 

Les équipes de sécurité doivent donner la priorité à la réduction de l’exposition des identifiants, à la validation de l’intégrité des paquets, à l’amélioration de la visibilité sur l’activité des développeurs et à la préparation aux éventuels incidents touchant la chaîne logistique. 

• Surveiller les pipelines CI/CD, les dépôts de paquets et les environnements de développement afin de détecter les modifications non autorisées de paquets, les activités de publication suspectes et les comportements d’authentification anormaux.
• Restreindre l’accès aux jetons de publication, aux clés API et aux identifiants cloud, tout en appliquant le principe du moindre privilège et l’MFA sur les systèmes de développement et de build.
• Valider l’intégrité des paquets à l’aide de versions signées, de la vérification des sommes de contrôle, de l’analyse des dépendances et d’outils d’analyse de la composition logicielle (SCA) avant le déploiement.
• Segmenter les environnements de build et limiter la connectivité sortante inutile depuis les exécuteurs CI/CD afin de réduire l’exposition des identifiants et les risques de déplacement latéral.
• Surveiller en continu les paquets Python, les bibliothèques d’IA et les dépendances open source afin de détecter les mises à jour malveillantes, le typosquatting et les comportements d’installation inattendus.
• Renforcer la visibilité sur les terminaux et les capacités de détection comportementale afin d’identifier les vols d’identifiants, les mécanismes de persistance et les activités suspectes de l’interpréteur Python.
• Tester régulièrement les plans de réponse aux incidents, de confinement et de reprise liés aux compromissions de la chaîne logistique logicielle, aux paquets malveillants et aux intrusions dans les pipelines CI/CD.

Ensemble, ces mesures peuvent aider les entreprises à réduire leur exposition aux risques de la chaîne logistique logicielle et à renforcer leur résilience opérationnelle. 

L’infrastructure d’IA devient une nouvelle cible

La compromission de LiteLLM met en évidence l’ampleur croissante des risques auxquels sont exposées les infrastructures d’IA et les chaînes logistiques logicielles, les attaquants ciblant de plus en plus les outils de développement et les environnements CI/CD de confiance. 

LiteLLM servant de passerelle vers plusieurs fournisseurs d’IA, une seule compromission peut potentiellement exposer les identifiants associés à OpenAI, Anthropic, Azure et à d’autres services connectés. 

L’incident montre également comment les attaquants peuvent détourner les relations de confiance au sein des pipelines logiciels, en exploitant une compromission antérieure de Trivy pour distribuer des paquets malveillants via des dépôts légitimes et des environnements de développement en aval. 

des stratégies zero trust pour renforcer les contrôles d’accès, la segmentation et la sécurité des identités.