Une nouvelle campagne de supply chain frappe l’écosystème Node.js. Baptisée Chaindrop, elle a conduit à la publication de plus de 2 200 versions malveillantes pour 440 paquets sur le registre NPM. Le résultat : des paquets NPM infectés largement utilisés, capables d’exécuter du code malveillant dès l’installation.
Au-delà de l’infection initiale, l’attaque a aussi favorisé la propagation. L’altération de certains modules a permis de contaminer encore davantage de dépendances, portant le total des paquets supplémentaires infectés à 433. Les conséquences potentielles s’étendent aux développeurs, mais aussi aux environnements d’intégration et de livraison continue (CI/CD) qui installent ces dépendances en routine.
Comment Chaindrop a contaminé les paquets NPM
Selon les informations rapportées, l’opération s’appuie sur la compromission du compte GitHub du mainteneur à l’origine de la mise en ligne des modules. La campagne commence avec 11 transporteurs de malwares dans des espaces de noms liés à keyv et cacheable.
Une fois ces premiers paquets en place, le mécanisme d’empoisonnement vise un objectif simple : obtenir des téléchargements et des exécutions. Les paquets compromis ont, ensemble, dépassé 500 millions de téléchargements hebdomadaires. Autrement dit, de nombreuses équipes ont pu déclencher l’exécution du code malveillant sans le savoir.
Une exécution malveillante dès l’installation
Les versions infectées ne se contentent pas d’être “toxiques” à long terme : elles déclenchent des actions dès la phase d’installation. Les paquets malveillants embarquent un dropper de préinstallation conçu pour récupérer le runtime JavaScript Bun et pour charger ensuite un second étage chiffré et obfusqué.
La charge utile décrite représente environ 710 Ko de code de deuxième étape obfusqué. À partir de là, le malware déploie ses capacités de vol et de propagation.
Le vol de secrets : poste de dev et environnements CI/CD
Le comportement observé sur les machines infectées est particulièrement préoccupant. Le malware recherche les identifiants et secrets disponibles, puis les chiffre avant de les exfiltrer. L’envoi peut s’effectuer via un endpoint HTTPS dynamique ou via des dépôts publics GitHub créés par l’attaquant.
Les systèmes visés incluent explicitement :
- les postes de travail des développeurs,
- les environnements d’intégration/déploiement continu (CI/CD),
- les contextes où des identifiants NPM, GitHub et cloud sont stockés.
Le malware récupère des identités réutilisables pour se faire passer pour l’entité compromise. Il peut alors énumérer des paquets et des dépôts, repérer des secrets de workflows, et extraire des paramètres cloud et des valeurs de stockage de secrets.
La propagation via identifiants NPM et GitHub Actions
Une fois les accès obtenus, l’attaque ne s’arrête pas. L’un des points clés est l’utilisation de jetons et identifiants volés pour repackager et republier des modules. Les informations rapportées indiquent que le malware utilise un token de publication NPM pour :
- énumérer les paquets accessibles à l’identité compromise,
- télécharger les dernières archives (tarballs),
- insérer le malware et un chargeur de configuration,
- ajouter un hook preinstall,
- incrémenter la version de patch, puis republier.
En parallèle, l’attaque exploite aussi des identifiants GitHub compromis et le fonctionnement de GitHub Actions pour contaminer davantage de dépôts. Le but : amplifier le vol d’identifiants et installer une forme de persistance dans l’environnement de développement.
Un mécanisme de commande et contrôle basé sur la blockchain
Sur le plan technique, le code décrit serait une évolution d’un ver déjà cité dans des campagnes précédentes de type “Mini Shai-Hulud”. Un élément notable est l’usage d’une blockchain Ethereum pour la commande et le contrôle (C&C), selon une technique appelée EtherHiding.
Ce choix vise à rendre le suivi et l’attribution plus difficiles, car l’infrastructure de commande peut être difficile à distinguer d’activités légitimes sur un registre public.
Extinction automatique : “dead-man’s switch” et auto-effacement
Chaindrop ne mise pas uniquement sur la persistance. Le malware intégrerait aussi un mécanisme de sécurité au niveau de l’opération : un “dead-man’s switch” installé au niveau de l’hôte. Après avoir établi une persistance sur macOS et Linux, il interrogerait l’API GitHub toutes les 60 secondes en utilisant le token GitHub volé.
Si le token cesse de fonctionner, l’exécution s’arrête : l’état est supprimé et le programme quitte. De plus, un auto-effacement après 24 heures est également mentionné, ce qui réduit la fenêtre d’observation directe.
Pourquoi le pic d’itérations malveillantes inquiète
Les versions historiques peuvent aussi être modifiées et republées. Cette particularité explique un phénomène observé : le 4 août, le nombre total d’itérations malveillantes constatées atteint 2 212 en moins de quatre heures.
En clair, l’attaquant a réussi à toucher des versions déjà connues, augmentant l’ampleur réelle du risque. Pour les équipes qui s’appuient sur des installations reproductibles, cela signifie que plusieurs “builds” peuvent avoir embarqué une charge utile identique à travers différentes lignes du temps de publication.
Ce que les développeurs doivent faire maintenant
Si vous avez installé l’un des paquets NPM infectés, la recommandation est de considérer votre machine comme potentiellement compromise. Les actions suggérées reposent sur trois axes : nettoyage, limitation du contrôle de l’attaquant, et audit.
Parmi les mesures recommandées :
- Isoler les systèmes concernés,
- préserver les éléments utiles à l’investigation (tarballs des paquets, logs NPM, logs CI, journaux d’audit GitHub, images des runners),
- reconstruire les runners CI et les machines de build,
- révoquer et faire tourner les identifiants et secrets potentiellement exposés,
- auditer les dépôts GitHub pour détecter toute activité anormale.
L’idée est de réduire la fenêtre d’exposition tout en conservant des preuves suffisantes pour déterminer quels secrets ont été récupérés et comment la propagation a pu se produire.
Prévenir la récurrence dans vos workflows
Au-delà du traitement d’incidents, Chaindrop rappelle l’importance de renforcer la sécurité autour des dépendances. Les équipes peuvent notamment vérifier que leurs pipelines CI/CD :
- limitent les droits des jetons utilisés lors des builds,
- séparent mieux les environnements (dev, CI, production),
- mettent en place une supervision des téléchargements et des exécutions de scripts d’installation,
- documentent clairement quelles actions peuvent modifier des dépôts ou publier sur un registre.
Chaque minute de retard peut compter : si un identifiant est volé, il peut être réutilisé pour republier des modules et poursuivre l’attaque via d’autres dépôts.
Conclusion
Chaindrop montre à quel point une compromission d’identité peut transformer l’écosystème de dépendances en vecteur d’attaque à grande échelle. En visant 440 paquets et plus de 2 200 versions malveillantes, l’opération a généré de nombreux paquets NPM infectés capables d’exécuter du code dès l’installation, de voler des secrets puis de se propager.
Si vous utilisez ces modules, agissez rapidement : isolez, conservez les journaux, nettoyez les environnements d’intégration, et faites une rotation des identifiants potentiellement exposés. C’est souvent la différence entre une alerte contenue et une compromission durable.
Source: https://www.securityweek.com/over-400-npm-packages-infected-in-chaindrop-supply-chain-attack/
