Axios compte 100 millions de téléchargements hebdomadaires sur npm, le registre de paquets de l’écosystème JavaScript. Ce volume en fait l’un des clients HTTP les plus déployés au monde, et aussi une cible de choix pour une attaque par chaîne d’approvisionnement d’une précision chirurgicale. Sans modifier une seule ligne du code légitime d’Axios, les attaquants ont injecté une dépendance malveillante dans deux versions du paquet, transformant chaque installation en vecteur de compromission.
Axios est la bibliothèque de référence pour effectuer des requêtes HTTP dans les applications JavaScript, aussi bien dans les navigateurs que dans les serveurs Node.js. En pratique, chaque fois qu’une application web doit interroger une API, récupérer des données ou envoyer des informations vers un serveur distant, elle utilise très souvent Axios pour le faire. Adoptée dans les frameworks frontaux, les services dorsaux et les applications d’entreprise, elle constitue une dépendance directe ou transitive dans une proportion considérable des projets JavaScript actifs. Une dépendance transitive est une bibliothèque qui n’a pas été ajoutée directement par le développeur, mais qui est requise par une autre dépendance. C’est cette ubiquité qui en fait un vecteur d’attaque à fort rendement, car compromettre Axios, c’est potentiellement atteindre des millions d’environnements de développement et de production en une seule publication sur npm.
Selon l’analyse publiée par JFrog Security Research et Socket, un outillage offensif sophistiqué, multiplateforme, et conçu pour effacer ses propres traces a été utilisé. Le mécanisme retenu évite toute modification du code fonctionnel d’Axios. Les attaquants ont publié deux nouvelles versions du paquet sur le registre npm (les versions [email protected] et [email protected]), en visant simultanément les deux branches maintenues du projet, la série 1.x et la série 0.x. Les deux publications ont été effectuées à trente-neuf minutes d’intervalle. Dans les projets qui utilisent une dépendance flexible vers Axios, c’est-à-dire une configuration autorisant l’installation automatique des versions récentes, l’exécution de la commande « npm install » récupérait automatiquement ces versions compromises.
Un chargeur furtif déclenché à l’installation
Pour comprendre le mécanisme d’exécution, il faut savoir que npm permet aux paquets de définir des scripts qui s’exécutent automatiquement lors de leur installation, sans aucune action de l’utilisateur, sans validation explicite. C’est ce que le protocole appelle un hook postinstall. Le paquet [email protected] exploite précisément ce mécanisme. Dès son installation, il exécute un script d’amorce qui dissimule ses indicateurs malveillants derrière deux couches de transformation successives, conçues pour tromper les outils d’analyse automatique et les règles de détection par signature. Une fois ces couches décodées, le chargeur identifie le système d’exploitation de la machine cible et déroule une chaîne de compromission adaptée à chaque plateforme.
Sur macOS, un binaire est téléchargé et placé dans un répertoire système en imitant délibérément la convention de nommage Apple, pour se fondre parmi les processus légitimes. Sur Windows, une copie de PowerShell est renommée sous l’apparence de Windows Terminal, et un script est exécuté en mode fenêtre masquée avec les protections désactivées. Sur Linux, un script Python est lancé en arrière-plan. Dans les trois cas, les communications vers le serveur de commande et de contrôle imitent du trafic npm ordinaire, de façon à passer inaperçues dans les journaux réseau et les règles de détection des SIEM.
Un cheval de Troie d’accès à distance complet sur macOS
Le chercheur Joe Desimone d’Elastic Security a capturé et analysé le second composant déployé sur macOS avant la mise hors ligne du serveur de commande et de contrôle. Il s’agit d’un cheval de Troie d’accès à distance complet, écrit en C++. À son lancement, il génère un identifiant victime unique, dresse une empreinte système détaillée, nom d’hôte, nom d’utilisateur, version du système, liste des processus actifs, inventaire des applications installées, et transmet ces informations au serveur toutes les 60 secondes. L’attaquant dispose ensuite de la capacité d’injecter et d’exécuter des binaires supplémentaires, de lancer des commandes arbitraires, et d’énumérer les répertoires de la machine compromise.
L’antiforensique est intégrée dès le chargeur initial. Après exécution, le script malveillant se supprime lui-même, efface le fichier de configuration portant la trace du hook d’installation, et restaure une copie propre à sa place. Après ce ménage, l’environnement compromis peut sembler parfaitement intact à l’inspection visuelle.
Quatre enseignements pour les équipes sécurité
Ce que cette attaque révèle dépasse le cas Axios. Le hook postinstall de npm constitue une surface d’attaque structurelle, non une anomalie : l’exécution automatique de code arbitraire à l’installation est une convention du registre, sans contrôle interposé entre la publication d’une dépendance malveillante et son exécution dans l’environnement de build. Tant que npm ne restreint pas ou n’isole pas ce mécanisme, le vecteur reste ouvert à quiconque parvient à publier. Et publier, ici, c’est tout ce que l’attaquant a fait : il n’a cassé aucun chiffrement, n’a exploité aucune vulnérabilité dans le code d’Axios. Il a obtenu, ou compromis, un accès à un compte mainteneur. Le modèle de gouvernance d’npm repose sur la confiance accordée aux comptes publiants, et la robustesse du code légitime n’offre aucune protection contre ce type d’attaque.
Le troisième facteur aggravant est l’automatisation des pipelines CI/CD. Les projets construisant en continu sur la dernière version disponible ont intégré la compromission avant même que les premières alertes circulent. L’outillage DevOps, conçu pour accélérer les livraisons, a ici travaillé pour l’attaquant en propageant la dépendance malveillante à une vitesse que la réponse humaine ne peut pas suivre. Enfin, l’antiforensique intégrée change la nature de la question à poser après détection : elle n’est plus « ai-je installé la mauvaise version », mais « mon environnement a-t-il été compromis avant que je le détecte », ce qui implique une investigation dans les règles de l’art, et non une simple vérification des fichiers de verrouillage.
