Une bibliothèque de développement d’IA largement utilisée a été compromise lors d’une récente attaque de la chaîne d’approvisionnement, exposant potentiellement un grand nombre de systèmes à des risques.
Des paquets LiteLLM malveillants sur PyPI ont été dotés d’une porte dérobée pour dérober discrètement des identifiants, des jetons et des données d’infrastructure sensibles dans les environnements de développement comme de production.
« La compromission de LiteLLM montre à quelle vitesse les attaques de la chaîne d’approvisionnement peuvent prendre de l’ampleur et à quel point nous sommes démunis si nous nous reposons uniquement sur les vulnérabilités connues », a déclaré Dr. Zulfikar Ramzan, Chief Technology & AI Officer de Point Wild dans un e-mail adressé à eSecurityPlanet.
« Cet incident nous oblige à élargir la discussion sur la manière dont les organisations traitent leur graphe de dépendances. Le modèle zero trust a été appliqué aux utilisateurs, aux appareils et aux réseaux. Les dépendances méritent le même niveau d’examen », a déclaré Jacob Krell, Senior Director of Secure AI Solutions & Cybersecurity chez Suzu Labs dans un e-mail adressé à eSecurityPlanet.
« Nous devrions nous en préoccuper, car la dépendance du secteur à l’égard de dépôts publics sans vérification locale des hachages ni “lockfiles” a de fait transformé Internet en dépendance de production non contrôlée », a déclaré Noelle Murata, Sr. Security Engineer chez Xcape, Inc dans un e-mail adressé à eSecurityPlanet.
« Le problème fondamental est que la chaîne d’approvisionnement logicielle repose encore sur trop de confiance implicite et pas assez d’immuabilité ou de vérification », a déclaré Cory Michal, CISO chez AppOmni dans un e-mail adressé à eSecurityPlanet.
Au cœur de l’attaque de la chaîne d’approvisionnement de LiteLLM
L’attaque cible LiteLLM, une bibliothèque open source totalisant environ 95 millions de téléchargements mensuels et qui achemine les requêtes vers plusieurs fournisseurs de LLM via une interface unique.
Comme LiteLLM est largement utilisé dans les environnements de production et cloud, il dispose souvent d’un accès à des données sensibles telles que des clés API, des identifiants cloud et des configurations Kubernetes.
Des chercheurs ont attribué l’attaque à TeamPCP, un acteur malveillant associé à de récentes compromissions de chaînes d’approvisionnement impliquant des outils comme Trivy et KICS.
Comment la porte dérobée a été livrée
Le code malveillant a été injecté dans la distribution PyPI tandis que le dépôt GitHub restait propre : les développeurs qui examinaient le code source ne voyaient donc rien de suspect, alors que les paquets installés étaient dotés d’une porte dérobée.
L’incident met en évidence une faiblesse critique de la chaîne d’approvisionnement logicielle : de nombreuses organisations font confiance aux registres de paquets sans vérifier indépendamment que les artefacts distribués correspondent bien à leur source en amont.
Au cœur de l’attaque en plusieurs étapes
Une fois installé, le logiciel malveillant utilise une chaîne d’exécution en plusieurs étapes conçue pour rester discrète et assurer sa persistance.
Le déclencheur initial est d’une simplicité trompeuse : un petit fragment de code injecté qui décode et exécute une charge utile dissimulée dès l’importation du module affecté.
Les attaquants ont poussé la technique plus loin en ajoutant un fichier .pth malveillant, qui provoque l’exécution automatique de la charge utile à chaque démarrage de l’interpréteur Python, même si LiteLLM n’est jamais utilisé directement.
Cela accroît la surface d’impact et transforme toute exécution de Python en point de compromission potentiel.
Après son exécution, le logiciel malveillant progresse en trois étapes coordonnées.
Premièrement, un script orchestrateur prépare et lance la chaîne d’attaque.
Ensuite, un composant de collecte d’identifiants recueille systématiquement les données sensibles présentes sur l’hôte, notamment les clés SSH, les identifiants des fournisseurs cloud, les secrets Kubernetes, les fichiers .env, les configurations de bases de données et d’autres artefacts de grande valeur.
Enfin, le logiciel malveillant assure sa persistance en installant une porte dérobée au niveau du système, qui contacte périodiquement une infrastructure contrôlée par les attaquants pour recevoir des charges utiles et des instructions supplémentaires.
Au-delà du simple vol de données, l’attaque est conçue pour s’étendre.
Le logiciel malveillant permet les mouvements latéraux dans Kubernetes en déployant des pods privilégiés sur les différents nœuds afin d’étendre l’accès des attaquants.
Les données volées sont chiffrées avant leur exfiltration vers des domaines contrôlés par les attaquants, ce qui complique la détection.
Atténuer les risques liés à la chaîne d’approvisionnement logicielle
Les organisations susceptibles d’avoir été exposées aux paquets LiteLLM compromis doivent rapidement évaluer les risques et contenir les dommages potentiels.
Compte tenu de l’ampleur de l’attaque et de son orientation vers le vol d’identifiants et la persistance, les mesures correctives classiques pourraient ne pas suffire à elles seules.
Les équipes de sécurité doivent considérer les environnements affectés comme potentiellement compromis et donner la priorité au nettoyage immédiat comme au renforcement à long terme.
- Supprimez les versions compromises de LiteLLM, réinstallez une version propre et vérifiée, puis reconstruisez les systèmes affectés à partir d’une base de référence fiable plutôt que de tenter un nettoyage sur place.
- Recherchez les mécanismes de persistance et les indicateurs de compromission, notamment les services systemd suspects, les fichiers inattendus ainsi que les pods Kubernetes ou les charges de travail privilégiées non autorisés.
- Faites tourner et révoquez tous les identifiants exposés, notamment les jetons cloud, les clés API, les clés SSH et les sessions actives, puis auditez les rôles IAM et l’accès aux secrets afin de détecter tout signe d’abus.
- Auditez les pipelines CI/CD et les environnements de développement pour détecter une compromission en aval, faites tourner les secrets des pipelines et examinez les journaux à la recherche de fuites d’identifiants ou d’activités anormales.
- Surveillez le réseau et le système quant au comportement afin de repérer les signes d’exfiltration et de mouvements latéraux, notamment un trafic sortant inhabituel, des communications périodiques avec l’infrastructure adverse et des schémas anormaux d’exécution des processus.
- Renforcez la sécurité de la chaîne d’approvisionnement en épinglant les dépendances, en vérifiant les paquets par rapport aux sources en amont, en utilisant des méthodes de publication fiables et en assurant la visibilité des SBOM dans tous les environnements.
- Testez régulièrement les plans de réponse aux incidents et organisez des exercices sur table autour de scénarios d’attaques de la chaîne d’approvisionnement logicielle.
Ensemble, ces mesures aident les organisations à renforcer leur résilience face aux attaques de la chaîne d’approvisionnement, tout en réduisant leur exposition aux dépendances compromises et aux menaces dissimulées.
Les outils de confiance deviennent des cibles
L’incident LiteLLM illustre une évolution plus large : les attaquants ciblent de plus en plus des outils qui disposent déjà d’un accès à des systèmes et à des données sensibles.
En ciblant ces composants bénéficiant d’un haut niveau de confiance, les acteurs malveillants peuvent plus facilement contourner les défenses traditionnelles et étendre leur emprise au sein d’un environnement.
Il montre également comment les attaques peuvent toucher plusieurs écosystèmes, des groupes comme TeamPCP exploitant des identifiants volés lors d’une compromission pour permettre la suivante dans les pipelines CI/CD, les registres de paquets et désormais les outils d’IA.
Pour les organisations, cela souligne la nécessité de vérifier en permanence l’intégrité des dépendances logicielles.
C’est précisément pour répondre à ce besoin croissant de vérification continue de la confiance et de limitation des accès implicites qu’une approche zero trust peut contribuer à renforcer les défenses contre les attaques modernes de la chaîne d’approvisionnement.