Fuite massive de clés : attaque de la chaîne LiteLLM

Quarante minutes. C'est tout ce qu'il a fallu en mars pour que des attaquants transforment des téléchargements de paquets de routine en un vol massif de données.

Les développeurs et ingénieurs qui pensaient récupérer des versions légitimes de la bibliothèque open-source d'intégration IA LiteLLM (versions 1.82.7 et 1.82.8) ont plutôt téléchargé du code truffé d'une porte dérobée aspirant la mémoire. Une fois exécutée, la charge malveillante parcourait la RAM du système, récoltait les secrets présents et les transmettait en continu vers des serveurs contrôlés par les intrus. Le résultat : plusieurs téraoctets de données sensibles exfiltrées depuis certaines des plus grandes entreprises mondiales.

Comment la compromission d'un paquet est devenue une catastrophe mondiale de la chaîne d'approvisionnement

Les chercheurs en sécurité ont ensuite découvert un cache totalisant environ 195 téraoctets. On y trouvait des clés d'accès cloud, des jetons de registre de conteneurs, des clés SSH et des mots de passe de bases de données actifs liés à plus de 2 500 organisations. Le jeu de données contenait aussi des identifiants provenant de plus de 434 000 entrées de pipelines CI/CD, beaucoup exposées en raison de configurations de pipelines publiques permissives. En bref : dès que des identifiants étaient en mémoire ou dans des variables de pipeline, ils étaient en danger.

L'intrusion n'a pas commencé chez LiteLLM. Selon les traces techniques reconstituées par les enquêteurs, les attaquants ont d'abord compromis un scanner de vulnérabilités largement utilisé, Trivy, et ont exploité cette porte d'entrée pour empoisonner des projets connexes comme KICS et le SDK Python de Telnyx. De là, la chaîne infectée s'est propagée aux paquets publiés de LiteLLM.

L'opération a été revendiquée par un groupe se faisant appeler TeamPCP. Plusieurs équipes de sécurité indépendantes ont corroboré le schéma d'attaque et la chronologie, laissant peu de doute qu'il s'agissait d'une campagne coordonnée contre la chaîne d'approvisionnement plutôt que d'un exploit isolé.

Qui a été touché ? L'impact est vaste. Des géants de la technologie et des entreprises d'infrastructure critique figurent dans les divulgations : Nvidia, Amazon Web Services, Samsung, Cisco, Siemens, Volkswagen, Reuters, FedEx, Epic Games, X (anciennement Twitter), HP, Philips et Deutsche Bank font partie des sociétés dont les clés exposées ont été confirmées avec un haut niveau de confiance.

Pourquoi cela a-t-il pris une telle ampleur si rapidement ? Deux facteurs se sont conjugués : une précipitation à adopter des outils IA et un modèle de confiance fragile dans les chaînes d'approvisionnement open-source. Des organisations désireuses d'intégrer des capacités d'IA ont installé des bibliothèques et des pipelines d'automatisation avec un audit minimal. Les secrets stockés dans des variables d'environnement ou laissés en mémoire dans des runners de build sont devenus des cibles faciles.

Il existe aussi une raison technique à l'efficacité de l'attaque. Les builds LiteLLM malveillants exécutaient un aspirateur de mémoire qui vidait tous les identifiants présents en mémoire et les envoyait à un collecteur. Cela signifie que même les jetons éphémères utilisés brièvement lors des déploiements ont été capturés. Éphémère n'est pas synonyme de sûr lorsqu'un attaquant peut lire la RAM.

Révoquez et renouvelez immédiatement toutes les clés et tous les jetons exposés.

Cette unique injonction est ce que répètent aujourd'hui les équipes de sécurité. Mais la remédiation est complexe. Comme de nombreux secrets divulgués ont été observés sans étiquette de domaine ni identifiant d'organisation, les défenseurs doivent relever un défi d'inventaire douloureux : identifier quelles clés ont été créées par quels services, puis révoquer, renouveler et reconfigurer. Pour de nombreuses équipes d'ingénierie, cela signifie reconstruire les runners CI/CD, remplacer les secrets embarqués par des identifiants à courte durée de vie et adopter des outils de détection des fuites de secrets qui signalent les divulgations avant qu'elles n'atteignent la production.

Les leçons sont claires et sévères. Premièrement, la provenance des dépendances compte. Installer à la hâte des bibliothèques pratiques sans vérifier les sommes de contrôle et l'identité des éditeurs crée un risque pour la chaîne d'approvisionnement. Deuxièmement, les secrets ne doivent pas résider en clair dans des variables de pipeline ni sous forme de jetons à longue durée de vie. Utilisez des identités de service à courte durée de vie et un accès basé sur les charges de travail lorsque c'est possible. Troisièmement, l'écosystème open-source a besoin de garde-fous plus solides : des builds reproductibles, des paquets signés et une meilleure hygiène des éditeurs atténueront ce type d'attaque.

Pour les organisations utilisant LiteLLM ou tout outil lié, les mesures immédiates devraient inclure :

• Inventoriez tous les identifiants et jetons susceptibles d'avoir été chargés en mémoire lors du build ou à l'exécution.
• Révoquez et renouvelez ces clés, en émettant de nouveaux identifiants avec des privilèges minimaux.
• Auditez les pipelines CI/CD et remplacez tout secret en clair par des jetons à courte durée de vie stockés dans un coffre sécurisé.
• Validez l'intégrité des paquets en vérifiant les sommes de contrôle et en favorisant les versions signées émanant de mainteneurs de confiance.
• Surveillez les trafics sortants anormaux depuis l'infrastructure de build qui pourraient indiquer la présence de portes dérobées persistantes.

L'attaque est un signal d'alarme. L'intégration d'outils d'IA peut apporter des gains de productivité importants. Mais quand la vitesse dépasse la sécurité, les conséquences ne sont pas théoriques. Les identifiants sont une monnaie d'échange. Une fois divulgués, ils permettent l'escalade, le mouvement latéral et le vol de données à grande échelle. Les équipes doivent partir du principe qu'une compromission est possible et construire des systèmes qui minimisent ce qu'un attaquant peut saisir lors d'une seule session.

Attendez-vous à des divulgations plus détaillées de la part des firmes de sécurité au fur et à mesure qu'elles analysent le trésor de 195 téraoctets et cartographient les organisations affectées. Pour l'heure, la posture la plus sûre consiste en une rotation rapide et coordonnée des clés, accompagnée d'un examen forensique des processus de build et de déploiement.