Xinference : fuite PyPI expose les secrets des développeurs Xinference sur PyPI a été compromis, exposant des secrets et clés. Mesures et retour à une version saine. Xinference, la bibliothèque Python qui permet d’utiliser facilement différents modèles d’IA localement, est à nouveau touchée par une attaque sur la chaîne d’approvisionnement.
Xinference, la bibliothèque Python qui permet d’utiliser facilement différents modèles d’IA localement, est à nouveau touchée par une attaque sur la chaîne d’approvisionnement. Les versions 2.6.0 à 2.6.2 sont compromises et exposent des identifiants sensibles tels que des clés SSH, des accès AWS et des secrets contenus dans les fichiers .env.
Ce qui s’est passé avec Xinference sur PyPI
La compromission a été détectée sur PyPI, le dépôt officiel des paquets Python. Selon les analyses, il ne s’agit pas de typo-squatting mais de véritables paquets Xinference distribués avec des composants malveillants. L’équipe de recherche de JFrog a établi des liens avec les attaques menées antérieurement contre Trivy et LiteLLM, bien que le compte X des auteurs conteste cette attribution.
Une fois installés, les paquets compromis ciblent directement les secrets stockés sur la machine des développeurs : clés SSH et TLS privées, identifiants Git et AWS, fichiers de configuration d’environnement, données de messagerie et bases de données, configurations Docker et Kubernetes, accès VPN et jetons de gestionnaire de paquets. Tout est enregistré dans une archive nommée « love.tar.gz ». Les pirates exploitent les secrets pour accéder à des comptes et, dans le cas d’AWS, lancer des actions directement sur le compte visé.
Les chercheurs précisent que le paquet malveillant injecte son code via le fichier __init__.py, ce qui permet au malware de se lancer à l’importation ou au démarrage, que ce soit lors d’un import, d’un démarrage en ligne de commande ou lorsqu’une autre bibliothèque dépendante importe Xinference. Le code exploitant est encodé en base64 et exécuté via un sous-processus à l’aide d’un nouvel interpréteur Python lancé par popen, afin de masquer les sorties et d’exécuter le contenu malveillant. Le texte de l’attaque commence par le commentaire « hacked by teampcp ».
Comment l’attaque agit et ce qu’elle vise
Selon JFrog, l’objectif est d’exfiltrer le maximum de données confidentielles et d’outiller les pirates pour dérober des secrets. Voici les axes principaux observés :
- Portée des données : clés SSH, TLS privées, identifiants Git, credentials AWS, variables d’environnement et secrets stockés localement.
- Exfiltration et exécution : les données sont compressées et envoyées hors de la machine; un second code en base64 exfiltre les données via une requête POST après les avoir placées dans un dossier temporaire.
- Persistance et exécution : le malware peut être lancé au démarrage ou à travers une bibliothèque dépendante, sans nécessité d’un mécanisme de persistance propre.
Un autre point relevé est l’usage d’un nom d’archive révélateur et d’un flux d’exécution qui passe par un sous-processus, rendant la détection plus ardue pour l’utilisateur moyen.
Contexte et mesures à prendre face à Xinference
La dernière version officielle et saine de Xinference est la 2.5.0. Les versions compromises 2.6.0, 2.6.1 et 2.6.2 ont été retirées, mais restent accessibles via l’historique PyPI et pourraient être téléchargées par des développeurs non avertis. JFrog recommande d’isoler les hôtes affectés des réseaux sensibles et de vérifier tout trafic sortant ou requêtes DNS vers des domaines suspects comme whereisitat.lucyatemysuperbox.space. « Tout hôte ayant importé le paquet pourrait avoir subi une fuite de données », avertit l’entreprise, qui invite à partir du principe que l’ensemble des données sensibles stockées localement est exposé et à procéder à une rotation des secrets.
Après un audit confirmant l’absence d’accès non autorisé, il est possible de se débarrasser du problème en désinstallant la version problématique de Xinference et en réinstallant une version saine, sans persistance malveillante
Pour terminer
Cet épisode rappelle une fois de plus la fragilité de la chaîne d’approvisionnement logicielle et l’importance de surveiller activement les dépendances open source. La vigilance reste de mise : surveiller les versions utilisées, vérifier les paquets téléchargés et mettre en place une rotation régulière des secrets, afin de limiter l’impact d’une éventuelle compromission future.
