Des téraoctets de données sensibles exposés dans une attaque de la chaîne d'approvisionnement visant LiteLLM
Des téraoctets de données d'identification d'organisations parmi les plus importantes et sensibles au monde sont exposés lors d'une attaque de la chaîne d'approvisionnement visant LiteLLM
Plus de 2 500 organisations et plus de 430 000 pipelines CI/CD ont été touchés par l'attaque de la chaîne d'approvisionnement LiteLLM survenue en début d'année. La compromission de LiteLLM a été révélée peu après l'attaque visant Trivy, le scanner de vulnérabilités open source d'Aqua Security, et en était une conséquence directe. Deux versions de LiteLLM ont été publiées sur PyPI, permettant ainsi aux pirates d'accéder à toutes les informations traitées par LiteLLM. L'attaque a entraîné la compromission à grande échelle d'informations sensibles : identifiants de publication de paquets, clés cloud, clés SSH, jetons et variables d'environnement. CloudSEK précise que les chiffres ne doivent pas être interprétés comme la preuve que chaque organisation répertoriée a effectivement été compromise.
En novembre 2022, pour tenter de pénétrer un réseau informatique, les hackers visaient toujours le maillon plus faible. Et la numérisation de la chaîne d’approvisionnement (Supply Chain) en avait fait une cible de choix depuis quelques années. Le phénomène semble s’être amplifié durant la période de pandémie comme en témoignaient diverses études : BlueVoyant estimait que 97% des entreprises avaient été impactées par une violation de cybersécurité ciblant leur chaîne d’approvisionnement, tandis que Trend Micro montrait dans une étude qu’une entreprise mondiale sur deux (52 %) avait déjà relevé une attaque par rançongiciel au sein de l’organisation de sa chaîne d'approvisionnement.
LiteLLM est une bibliothèque Python open source et une passerelle d’intelligence artificiealle (IA) développée par BerriAI qui offre une interface unifiée permettant d’interroger plus d’une centaine de fournisseurs de grands modèles de langage (LLM) à l’aide du format de complétion de chat d’OpenAI. Créé par Ishaan Jaffer et Krrish Dholakia, ce projet est issu de la promotion d’hiver 2023 de Y Combinator et répond à la fragmentation croissante des API LLM, chaque fournisseur exigeant son propre SDK, son propre système d’authentification et son propre format de requête. LiteLLM fonctionne à la fois comme un SDK Python léger que les développeurs peuvent intégrer directement dans leurs applications et comme un serveur proxy auto-hébergé que les organisations déploient en tant que passerelle centralisée pour gérer l’ensemble du trafic LLM.
Selon CloudSEK, plus de 2 500 organisations et plus de 430 000 pipelines CI/CD ont été touchés par l'attaque de la chaîne d'approvisionnement LiteLLM survenue en début d'année. La compromission de LiteLLM a été révélée peu après l’attaque de la chaîne d’approvisionnement visant Trivy, le scanner de vulnérabilités open source d’Aqua Security, et en était une conséquence directe.
TeamPCP, l’acteur malveillant à l’origine de plusieurs compromissions très médiatisées de logiciels open source (OSS), n’a jamais ciblé LiteLLM directement. La bibliothèque Python open source et le serveur proxy ont été compromis après que son pipeline CI a installé automatiquement la version corrompue de Trivy. Deux versions de LiteLLM, à savoir les versions 1.82.7 et 1.82.8, ont été publiées sur PyPI, permettant ainsi aux pirates d’accéder à toutes les informations traitées par LiteLLM.
« Trivy, puis le système de compilation [LiteLLM], puis la version de LiteLLM : un seul jeton non révoqué, trois outils plus loin. C’est cette chaîne qui transforme une simple fuite d’identifiants en une exposition à l’échelle de tout l’écosystème », note CloudSEK. « Les systèmes de compilation automatisés réduisent les délais. Dès qu’un artefact malveillant atteint un registre, les tâches planifiées, les résolveurs de dépendances, les exécuteurs éphémères, les ordinateurs portables des développeurs et les couches mises en cache peuvent le copier rapidement. La fenêtre d’analyse et de rotation des identifiants s’étend donc au-delà de la simple suppression du paquet », poursuit la société.
Les versions modifiées de LiteLLM contenaient un code malveillant qui s’exécutait à chaque appel de Python, sans importation explicite. La charge utile s’exécutait sur tous les systèmes sur lesquels le paquet était installé. Selon CloudSEK, bien que les paquets affectés n’aient été disponibles que pendant 40 minutes, ce délai a suffi pour que le code malveillant se propage, exposant au final 434 000 pipelines CI/CD et affectant plus de 2 500 organisations.
Nvidia, AWS, Samsung, Salesforce, Cisco, ServiceNow, Accenture Federal Services, Siemens, Regeneron Pharmaceuticals, London Stock Exchange Group, FedEx, Volkswagen, Orange, HP, Deutsche Bahn, NGINX et Zscaler ne sont que quelques-uns des noms figurant sur la liste de CloudSEK.
« Les chiffres de plus de 2 500 entreprises et 434 000 cas en cours de traitement décrivent une exposition reconstituée. Ils ne doivent pas être interprétés comme la preuve que chaque organisation répertoriée a effectivement été compromise ou que chaque identifiant a été volé », précise CloudSEK, soulignant que chaque cas de compromission doit faire l’objet d’une vérification indépendante.
L’attaque de la chaîne d’approvisionnement LiteLLM a entraîné la compromission à grande échelle d’informations sensibles : identifiants de publication de paquets, clés cloud, clés SSH, jetons, variables d’environnement, données d’exécution et clés de fournisseurs d’IA, entre autres. Les pirates pourraient utiliser ces secrets pour prendre le contrôle de comptes, voler des données, injecter des commits malveillants, s’assurer une persistance, se déplacer latéralement, perturber des services, déployer des logiciels malveillants et mener divers autres types d’attaques.
Les organisations doivent considérer comme compromis tout secret accessible à la bibliothèque LiteLLM, y compris ceux « présents dans la mémoire du processus, injectés dans la tâche, stockés sur le disque ou récupérables via un service de métadonnées d’instance ». Les secrets potentiellement compromis doivent être validés, puis renouvelés en même temps que les comptes de service et les sessions, et les journaux doivent être examinés afin de déterminer l’étendue et la durée de l’exposition.
La prochaine attaque majeure visant la chaîne d’approvisionnement ciblera probablement les infrastructures d’IA, car ces systèmes sont devenus des « points de jonction à forte valeur ajoutée entre les données, l’identité, la puissance de calcul et l’action autonome ». « Cet incident n’était pas seulement une faille de la chaîne d’approvisionnement logicielle qui a par hasard impliqué un produit d’IA. Il a démontré que la compromission d’un point de contrôle de l’IA peut exposer les identités et les systèmes qui l’entourent. Les futures attaques viseront probablement la couche d’IA précisément parce qu’elle est connectée à tout le reste », note CloudSEK.
Selon un rapport de février 2024, l'écrasante majorité des organisations (91 %) ont connu un incident dans la chaîne d'approvisionnement logicielle au cours des 12 derniers mois. L'étude de Data Theorem et de l'Enterprise Strategy Group a interrogé plus de 350 personnes issues d'organisations des secteurs privé et public aux États-Unis et au Canada, parmi lesquelles des professionnels de la cybersécurité, des développeurs d'applications et des professionnels de l'informatique.
Sources : CloudSEK ; Hudson Rock
Et vous ?
Pensez-vous que cette information est crédible ou pertinente ?
Voir aussi :
Répondre avec citation
Partager