La bibliothèque Python Xinference, qui permet d’utiliser facilement différents modèles d’IA localement, a été ciblée. Résultat : les versions 2.6.0 à 2.6.2 sont compromises et exposent plusieurs identifiants de connexion comme les clés SSH ou les secrets .env.

Une nouvelle fois, la supply chain d’une bibliothèque utilisée par les développeurs recourant à des modèles d’IA a été compromise. En mars, c’était le scanner de vulnérabilité Trivy qui était visé puis l’application LiteLLM. Axios avait ensuite été touché. Maintenant, c’est le tour de Xorbits Inference connu aussi sous le nom de Xinference.

• Après Trivy, Axios : une attaque chirurgicale et violente de la supply chain

Cette bibliothèque permet aux développeurs de passer d’un modèle à un autre en une seule ligne de code et de sélectionner des modèles open source qui conviennent le mieux pour la voix, du multimodal, qu’ils soient sur leur ordinateur ou dans le cloud.

Mais une attaque a été détectée par un utilisateur de XInference. L’équipe de chercheurs de l’entreprise de sécurité JFrog a analysé la compromission de Xinference dans PyPI (Python Package Index), le dépôt officiel des paquets Python. Pour eux, c’est signé du même acteur que celle effectuée contre Trivy, TeamPCP, même si son compte X réfute.

Récupération de tous les secrets possibles, traitement spécial pour AWS

JFrog explique que l’attaque n’utilise pas de technique de typo-squatting ou de faux paquets. C’est bel et bien les vrais paquets de Xinference distribués via PyPI qui ont été touchés et qui comportent des trojans. La méthode utilisée par les pirates pour diffuser des paquets piégés via PyPI n’est pas indiquée par les développeurs ; il faut se contenter d’un « Oui, nous sommes attaqués, nous venons de retirer ces versions » il y a 12 heures.

Une fois installés, ils ciblent directement les mot de passe et secrets des développeurs comme les clés SSH et TLS privées, les identifiants Git, AWS, les fichiers de configuration d’environnement de l’ordinateur, de mails et de bases de données, de Docker et Kubernetes, de VPN, les jetons de gestionnaire de paquets, ainsi que les portefeuilles de cryptomonnaies. Tout est enregistré dans une archive « love.tar.gz ».

Dans le cas d’AWS, le code malveillant va directement se connecter sur le compte via les secrets dérobés. Il ne fait donc pas seulement que récupérer des « clés », dans le cas d’Amazon elles sont directement utilisées sur place pour voler d’autres secrets avant de partir (via une fonction def aws_req).

« Si vous avez installé ou utilisé les versions 2.6.0 à 2.6.2 de xinference, considérez que l’hôte a été compromis », alarme JFrog. La dernière version officielle (et saine) est actuellement la 2.5.0. Attention, sur PyPI les versions 2.6.0, 2.6.1 et 2.6.2 sont uniquement « remisées » et donc toujours accessibles et téléchargeables dans l’historique des versions PyPI.

L’entreprise de cybersécurité explique que le code malveillant se trouve dans le fichier __init__.py, ce qui lui permet de se lancer dès l’import du paquet, que ce soit via un import de la bibliothèque, au démarrage en ligne de commande ou comme un service, via l’utilisation d’une bibliothèque dépendant de ce paquet.

Le piratage se fait via du code Python encodé en base64 (pour le cacher un peu aux yeux des utilisateurs) dans le fichier transmis à un sous-processus. Un nouvel interpréteur Python appelé via popen permet de désactiver les sorties stdout, stderr et d’exécuter le contenu malveillant sans que l’utilisateur ne s’en rende compte. Celui-ci commence par le commentaire « # hacked by teampcp ».

JFrog ne s’appuie pas que sur celui-ci pour attribuer le piratage à la même équipe que celle qui s’est attaquée à liteLLM.Les chercheurs affirment que la structure de l’attaque est « similaire ». Un autre code en base64 exfiltre les données via une requête POST après les avoir compressées dans un dossier temporaire.

L’entreprise liste cependant quelques différences avec le piratage de liteLLM dans ce tableau :

Sur la machine, toutes les données confidentielles sont exposées à un risque

Pour celles et ceux qui auraient installé une de ces versions de Xinference, JFrog conseille d’isoler le plus rapidement possible les hôtes affectés des réseaux sensibles et de vérifier s’il y a du trafic sortant ou des requêtes DNS vers whereisitat[.]lucyatemysuperbox[.]space. « Tout hôte ayant importé le paquet pourrait avoir subi une fuite de données », rappelle l’entreprise. « Vous devez partir du principe que toutes les données confidentielles stockées sur la machine sont exposées à un risque » et donc faire une rotation de tous les secrets qui ont pu être ciblés.

Enfin, après un audit vérifiant qu’il n’y a eu aucun accès non autorisé, JFrog explique qu’il est possible de se débarrasser du problème en désinstallant la version problématique de Xinference car aucun mécanisme de persistance n’est mis en place.

• L’attaque sans précédent sur NPM relance les débats sur la chaîne d’approvisionnement