La compromission temporaire du paquet npm populaire Axios montre à quelle vitesse une dépendance fiable peut devenir une menace généralisée.
Des attaquants ont détourné le compte d’un mainteneur et publié des versions malveillantes qui installaient discrètement un cheval de Troie d’accès à distance (RAT) lors des installations habituelles de paquets, mettant en danger les environnements de développement et les pipelines CI/CD.
« Si les risques traditionnels, comme l’installation manuelle de dépendances et les bots de mise à niveau non sécurisés, restent importants, la menace plus pressante et tournée vers l’avenir se situe à une échelle hyperélevée : les agents de codage dotés d’une autonomie totale et capables d’exécuter des outils », a déclaré Liran Tal, Head of Developer Relations & Community chez Snyk, dans un e-mail adressé à eSecurityPlanet.
Au cœur de l’attaque de la chaîne d’approvisionnement d’Axios
Les chercheurs de Snyk ont constaté que l’attaque avait touché Axios — utilisé pour plus de 100 millions de téléchargements hebdomadaires — ce qui signifie que même une exposition brève a créé un rayon d’impact considérable dans les pipelines de développement et les environnements de production.
Les organisations qui s’appuyaient sur des compilations automatisées ou des dépendances non verrouillées étaient particulièrement vulnérables, car les versions malveillantes pouvaient être récupérées à leur insu, ce qui montre une nouvelle fois à quel point des paquets open source de confiance peuvent être transformés en armes sans modification de leurs fonctionnalités fondamentales.
Fonctionnement de l’attaque
La cause première était la compromission du compte d’un mainteneur, illustrant une catégorie croissante d’attaques contre la chaîne d’approvisionnement qui ciblent l’identité plutôt que le code.
En abusant du modèle de confiance de npm, l’attaquant a pu publier directement des versions malveillantes sur le paquet officiel, contournant les mesures de protection traditionnelles.
Plutôt que de modifier Axios lui-même, l’attaquant a inséré une dépendance malveillante (plain-crypto-js) dans le paquet, permettant à la charge utile de s’exécuter lors de l’installation par l’intermédiaire d’un script postinstall, avec une interaction minimale de l’utilisateur.
Une fois déclenchée, l’attaque a déployé une charge utile en plusieurs étapes, recourant à des techniques d’obfuscation par couches pour échapper à la détection.
Le logiciel malveillant récupérait dynamiquement des RAT spécifiques à chaque plateforme pour les systèmes macOS, Windows et Linux, permettant un impact multiplateforme étendu.
Après son exécution, il supprimait les traces de son installation, compliquant l’analyse forensique et réduisant la probabilité d’une détection dans les environnements compromis.
L’attaque pouvait être effectivement exploitée pendant sa brève période de publication, et tout système ayant installé les versions concernées doit être considéré comme entièrement compromis.
Compte tenu de la capacité du RAT à exécuter des commandes, à exfiltrer des données et à assurer sa persistance, cet incident montre à quelle vitesse une dépendance fiable peut devenir un vecteur d’attaque à fort impact lorsque les contrôles de la chaîne d’approvisionnement sont faibles ou inexistants.
Comment réduire les risques liés à la chaîne d’approvisionnement
Les attaques contre la chaîne d’approvisionnement sont de plus en plus ciblées et difficiles à détecter, en particulier lorsqu’elles proviennent de dépendances fiables.
Les contrôles de sécurité traditionnels ne détectent souvent pas les comportements malveillants introduits lors du processus de compilation ou de l’installation d’un paquet.
Pour réduire les risques, les organisations doivent renforcer les contrôles liés à la gestion des dépendances, aux environnements de compilation et à la surveillance de l’exécution.
- Auditer les fichiers de verrouillage et imposer le verrouillage des dépendances afin d’empêcher les mises à jour non autorisées ou malveillantes des paquets.
- Faire tourner les identifiants et les secrets des systèmes potentiellement exposés afin de réduire les risques après compromission.
- Restreindre les scripts postinstall et mettre en place une liste d’autorisation des dépendances à l’aide d’outils DevSecOps afin de limiter l’exécution de code non fiable.
- Vérifier l’intégrité des paquets au moyen de signatures, d’informations de provenance ou d’attestations afin de garantir des sources fiables.
- Isoler les environnements de compilation et restreindre l’accès réseau sortant afin de bloquer les rappels malveillants.
- Surveiller les comportements anormaux à l’aide de EDR ou de contrôles d’exécution afin de détecter les processus et connexions suspects.
- Tester les plans de réponse aux incidents pour les scénarios d’attaque contre la chaîne d’approvisionnement et utiliser des outils de simulation d’attaque.
Collectivement, ces mesures contribuent à limiter le rayon d’impact des attaques contre la chaîne d’approvisionnement tout en renforçant la résilience des environnements de développement et de déploiement.
Évolution des menaces visant la chaîne d’approvisionnement
Cet incident illustre l’évolution des attaques contre la chaîne d’approvisionnement : les attaquants ciblent de plus en plus les mainteneurs et les canaux de distribution plutôt que les failles au niveau du code.
À mesure que les écosystèmes open source se développent, ces approches permettent des compromissions plus efficaces et plus discrètes, avec un impact en aval plus étendu.
Ces tendances soulignent la nécessité d’adopter une approche plus structurée de la sécurité de la chaîne d’approvisionnement logicielle dans les flux de travail de développement et de déploiement.