Après Trivy, Axios : une attaque chirurgicale et violente de la supply chain
Téma la taille du RAT !
Illustration : Flock
Le 31 mars à 17h19
Une nouvelle attaque sur la supply chain, avec un projet (Axios) téléchargé plus de 100 millions de fois par semaine. Le pirate avait bien préparé son coup avec un effacement automatique des traces et des attaques prêtes pour Windows, macOS et Linux afin de récupérer des secrets et autres données sensibles sur les machines infectées.
Après Trivy, Axios : une attaque chirurgicale et violente de la supply chain
Téma la taille du RAT !
Illustration : Flock
Une nouvelle attaque sur la supply chain, avec un projet (Axios) téléchargé plus de 100 millions de fois par semaine. Le pirate avait bien préparé son coup avec un effacement automatique des traces et des attaques prêtes pour Windows, macOS et Linux afin de récupérer des secrets et autres données sensibles sur les machines infectées.
Le 31 mars à 17h19
Sécurité
Sécurité
6 min
Axios est, selon sa propre définition, un client HTTP qui « propose une bibliothèque facile à utiliser et à étendre, le tout dans un tout petit package ». L’installation est des plus simple, avec npm install axios par exemple.
« Aucune ligne de code malveillant à l’intérieur même » d’Axios
La bibliothèque JavaScript est extrêmement populaire, avec plus de 100 000 étoiles et 11 000 forks sur GitHub, et on la retrouve dans de nombreux projets. Axios est téléchargé plus de 100 millions de fois par semaine sur npm.
Problème, le compte d’un des développeurs a été piraté et des versions vérolées d’Axios ont été mises en ligne, les 1.14.1 et 0.30.4 pour être précis, comme l’explique sur X Feross Aboukhadijeh, CEO et fondateur de la plateforme de cybersécurité Socket.dev.
Un billet de blog a aussi été publié, expliquant que cette attaque permet au pirate « d’exécuter des commandes arbitraires, d’exfiltrer les données système et de persister sur les machines infectées ». Le danger est donc bien réel, avec des conséquences potentiellement graves.
StepSecurity, une autre société de cybersécurité, détaille le fonctionnement de l’attaque : « Il n’y a aucune ligne de code malveillant à l’intérieur même de la bibliothèque Axios, et c’est précisément ce qui rend cette attaque si dangereuse. Les deux versions empoisonnées injectent une fausse dépendance, plain-crypto-js version 4.2.1, un paquet qui n’est jamais importé dans le code source Axios, dont le seul but est d’exécuter un script post-installation qui déploie un cheval de Troie d’accès à distance [ou RAT, ndlr] multiplateforme ».
L’attaquant s’était bien préparé avec des charges utiles pour Windows, macOS et Linux, adaptées à chaque système pour être la plus discrète possible.
Plain-crypto-js 4.2.1 et c’est le drame
Pire encore, une fois installé, le logiciel malveillant fait tout pour supprimer ses traces. Il modifie sa version pour passer en plain-crypto-js 4.2.0 (publiée juste avant la 4.2.1 par le pirate, mais sans charge malveillante pour s’acheter une bonne conduite). Ainsi, un simple npm list après une infection indiquera plain-crypto-js 4.2.0 alors que la 4.2.1 vérolée a été en place et a déjà propagé sa charge malveillante dans le système.
Plain-crypto-js 4.2.0 est une copie de la bibliothèque crypto-js 4.2.0 (15 millions de téléchargements par semaine sur npm), un projet qui existe vraiment et tout ce qu’il y a de plus légitime. 18 heures après la mise en ligne de la version 4.2.0 de plain-crypto-js, la version 4.2.1 est mise à jour avec la charge malveillante. Avec cette « astuce », plain-crypto-js n’est plus un « nouveau » paquet sorti de nulle part, il a déjà un historique… certes fabriqué de toutes pièces pour paraitre légitime, mais un historique quand même.
La seule trace de son passage semble être la présence d’un répertoire node_modules/plain-crypto-js (une dépendance qui n’a jamais été ajoutée, officiellement, à Axios). Avec la commande find ~ -path "*/node_modules/plain-crypto-js" 2 >/dev/null vous pouvez faire une recherche automatique. Le serveur de commande et contrôle (C2) utilisé par les pirates est sfrclak[.]com:8000.
Un seul compte piraté et Axios embarque une charge malveillante
Pour arriver à leur fin, les attaquants ont piraté le compte du principal mainteneur du projet, Jason Saayman, et son adresse e-mail a été modifiée. Ils ont ajouté la dépendance vérolée à Axios, qui est passé en 1.14.1 pour l’occasion. 39 minutes plus tard, c’était au tour de la version 0.30.4 d’être mise en ligne avec la même modification, histoire de maximiser la surface d’attaque en ciblant deux branches.
Les deux versions sont publiées sur npm directement avec le compte « officiel » (mais piraté) de Jason Saayman. Elles sont donc validées via un token npm classique, sans avoir à passer par la vérification GitHub. Les deux ne sont d’ailleurs pas apparues sur la plateforme de code de Microsoft.
La charge est restée moins de 3 h en ligne
npm a rapidement retiré les deux versions pour revenir aux précédentes (1.14.0 et 0.30.3). La mouture 1.14.1 « était en ligne depuis environ 2 heures et 53 minutes, la 0.30.4 depuis environ 2 heures et 15 minutes », explique StepSecurity. Plain-crypto-js a également été supprimé. Sur npm, il est désormais indiqué que « ce paquet contenait un code malveillant et a été retiré du registre par l’équipe de sécurité de npm ». La page indique 108 téléchargements pour plain-crypto-js.
Socket.dev a trouvé la trace de plain-crypto-js dans les dépendances de deux autres projets : shadanai/openclaw et qqbrowser/openclaw-qbot. Socket.dev précise qu’il « est probable que ces deux paquets ont été ajoutés et publiés alors qu’Axios 1.14.1 était la version « latest », récupérant la dépendance malveillante de manière transitive plutôt que via une injection délibérée ».
« Une seule dépendance compromise peut se propager en cascade »
Autre conséquence, pour l’entreprise : « Cela rappelle que, à mesure que les outils d’IA et les pipelines de build automatisés accélèrent le rythme de publication des paquets, une seule dépendance compromise peut se propager en cascade à travers l’écosystème en quelques heures ».
Pensez à vérifier ce qu’il en est sur vos machines ! Avec l’IA générative et la génération automatique de code, vous pouvez très bien vous retrouver avec Axios installé sans même le soupçonner. Bien évidemment, il en est de même pour ceux qui utilisent Axios de manière consciente.
Pour Amit Geynis, responsable Malware Research chez JFrog (société spécialisée dans la gestion de la supply chain), « la compromission d’Axios rappelle que les attaques complexes et multi-plateformes de la chaîne d’approvisionnement se multiplient. La menace est à la fois réelle et systémique : l’installation d’un package s’accompagne de l’intégration de nombreuses dépendances associées, que vous ne contrôlez pas mais auxquelles vous devez pourtant accorder votre confiance ».
Cette histoire n’est pas sans rappeler la récente attaque contre Trivy puis LiteLLM, mais sans avoir de lien a priori selon plusieurs experts. Ces attaques rappellent une fois de plus (s’il en était besoin) le risque de la supply chain : les pirates n’attaquent pas directement des infrastructures mais vérolent des briques (open source) pour pénétrer des systèmes, récupérer des secrets et mots de passe, installer des logiciels, etc.
Commentaires (12)
Abonnez-vous pour prendre part au débat
Déjà abonné ou lecteur ? Se connecter
Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles d'un média expert
Profitez d'au moins 1 To de stockage pour vos sauvegardes
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 31 mars à 18h04
Le problème n'est pas de réagir rapidement. Mais d'empêcher la mise en ligne en amont...
Le 31 mars à 23h24
Le 31 mars à 23h48
Ce ne sont pas les devs que je blâme. J'en suis et je suis parfaitement au courant du milliards de problème à la con que nous vivons. A plus forte raison lorsque nous écopons de la bêtise des autres.
Ce que blâme c'est la structure. Ici NPM qui visiblement n'apprend pas de ces erreurs. Et cela se compte en années (bientôt décade).
Le 2 avril à 12h07
Ne me remerciez pas pour ce commentaire plutôt inutile, qui ne se voulait quand même pas désobligeant, je précise.
Le 2 avril à 15h52
Bref, j'y ferai attention... ou pas.
Le 31 mars à 23h51
On sait ce qui les a mis sur la piste ?
Mais sinon, savez-vous s'il existe un "registre" qui "certifie" qu'une dépendance est "fiable" ?
Au lieu de faire appel à "latest" d'un projet, on pourrait ainsi demander à récupérer que la "latest-verified" pour sécuriser le projet.
Le 1er avril à 00h50
Le 1er avril à 20h12
Le 2 avril à 12h40
Le 2 avril à 20h24
Si tu le fait, tu dois être l'un des rares à relire tout le code de ton OS (Operating System), puis celui de chaque mise à jour...
Malgré toute leur bonne volonté, on ne peut pas demander aux mainteneurs d'un projet Open Source d'être "de confiance" : ils ont d'autres choses à faire que de vérifier leur repos. D'où l'intérêt d'avoir un externes qui, lui, se charge de faire ces vérifications et qui sera payé pour ça par ses clients.
Modifié le 1er avril à 16h06
Modifié le 1er avril à 11h08
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?