Vague d'attaques sur la chaîne d'approvisionnement npm : que s'est-il passé ? Comment atténuer les risques ?

Original Article Title: "Supply Chain Attack Goes Viral Overnight: What Happened? How to Mitigate Risk?"

Original Article Author: Azuma, Odaily Planet Daily

Le 9 septembre, heure de l’Est asiatique, le Chief Technology Officer de Ledger, Charles Guillemet, a publié une alerte sur X, déclarant : « Une attaque à grande échelle sur la chaîne d’approvisionnement est en cours, le compte NPM d’un développeur bien connu a été compromis. Le paquet logiciel affecté a été téléchargé plus de 1 milliard de fois, ce qui indique que l’ensemble de l’écosystème JavaScript pourrait être en danger. »

Guillemet a précisé : « Le code malveillant fonctionne en modifiant silencieusement les adresses de cryptomonnaies en arrière-plan afin de voler des fonds. Si vous utilisez un hardware wallet, vérifiez soigneusement chaque transaction signée, et vous êtes en sécurité. Si vous n’utilisez pas de hardware wallet, veuillez temporairement éviter toute transaction on-chain. Il n’est actuellement pas clair si l’attaquant a déjà volé la phrase mnémonique des wallets logiciels. »

Que s’est-il passé ?

Selon le rapport de sécurité cité par Guillemet, la cause directe de cet incident est la suivante : le compte NPM du développeur bien connu @qix a été compromis, ce qui a conduit à la publication de versions malveillantes de dizaines de paquets logiciels, dont chalk, strip-ansi et color-convert. Le code malveillant a pu se propager aux utilisateurs finaux lorsque les développeurs ou utilisateurs installaient automatiquement des dépendances.

Odaily Note: Données du volume de téléchargements hebdomadaires des paquets logiciels compromis.

En résumé, il s’agit d’un cas classique d’attaque sur la chaîne d’approvisionnement — où un attaquant implante un code malveillant (tel qu’un paquet NPM) dans un outil de développement ou un système de dépendances afin de mener des activités malveillantes. NPM, abréviation de Node Package Manager, est l’outil de gestion de paquets le plus utilisé dans l’écosystème JavaScript/Node.js. Ses principales fonctions incluent la gestion des dépendances, l’installation et la mise à jour de paquets, le partage de code, etc.

En raison de l’immense ampleur de l’écosystème NPM, qui compte actuellement des millions de paquets logiciels, presque tous les projets Web3, crypto wallets et outils frontend dépendent de NPM — c’est précisément pourquoi les dépendances étendues de NPM et la complexité de la chaîne de liens en font un point d’entrée à haut risque pour les attaques sur la chaîne d’approvisionnement. En implantant un code malveillant dans un paquet logiciel couramment utilisé, les attaquants peuvent potentiellement impacter des milliers d’applications et d’utilisateurs.

Comme illustré dans le schéma de propagation du code malveillant ci-dessus :

· Un certain projet (boîte bleue) dépend directement de certaines bibliothèques open-source courantes, telles que express.

· Ces dépendances directes (boîtes vertes) dépendent ensuite d’autres dépendances indirectes (boîtes jaunes, telles que lodash).

· Si une dépendance indirecte est secrètement injectée avec du code malveillant par un attaquant (boîte rouge), celui-ci se propagera le long de la chaîne de dépendances dans ce projet.

Qu’est-ce que cela signifie pour la cryptomonnaie ?

La pertinence directe de cet incident de sécurité pour l’industrie de la cryptomonnaie est que le code malveillant implanté par le hacker dans le paquet logiciel compromis susmentionné est un « hijacker de presse-papiers de cryptomonnaie » sophistiqué, qui vole des actifs en remplaçant les adresses de wallets et en détournant les transactions.

Le fondateur de Stress Capital, GE (@GuarEmperor), a détaillé cela sur X, expliquant que l’injection du « hijacker de presse-papiers » du hacker adopte deux modes d’attaque — utilisation passive de l’algorithme de distance de Levenshtein pour remplacer les adresses de wallets, qui sont visuellement similaires et donc extrêmement difficiles à détecter ; modification active de l’adresse cible dans le wallet de cryptomonnaie détecté par le navigateur avant que l’utilisateur ne signe la transaction.

Puisque cette attaque visait les bibliothèques de base des projets JavaScript, même les projets dépendant indirectement de ces bibliothèques peuvent être affectés.

Comment le hacker en profite-t-il ?

Le code malveillant implanté par le hacker a également révélé ses adresses d’attaque. L’adresse principale d’attaque du hacker sur Ethereum est 0xFc4a4858bafef54D1b1d7697bfb5c52F4c166976, avec des fonds provenant principalement des trois adresses suivantes :

· 0xa29eEfB3f21Dc8FA8bce065Db4f4354AA683c0240

· x40C351B989113646bc4e9Dfe66AE66D24fE6Da7B

· 0x30F895a2C66030795131FB66CBaD6a1f91461731

L’équipe Arkham a créé une page de suivi pour cet événement d’attaque, où vous pouvez consulter en temps réel les gains et transferts du hacker.

Au moment de la rédaction, l’attaque du hacker n’a rapporté que 496 $, mais compte tenu de la propagation encore indéterminée du code malveillant, il est probable que ce chiffre continue d’augmenter — le développeur a été informé et collabore activement avec l’équipe de sécurité NPM pour résoudre le problème. Le code malveillant a été supprimé de la plupart des paquets affectés, donc la situation est sous contrôle.

Comment atténuer le risque ?

Le fondateur de Defillama @0xngmi a déclaré sur X qu’en dépit de la gravité apparente de l’événement, l’impact réel n’est pas aussi étendu — car cet événement n’affecte que les sites web ayant publié des mises à jour depuis la publication du paquet NPM compromis, les autres projets continuant à utiliser l’ancienne version ; et la plupart des projets verrouillent leurs dépendances, donc même s’ils publient des mises à jour, ils continueront à utiliser l’ancien code sécurisé.

Cependant, comme les utilisateurs finaux ne peuvent pas vraiment savoir si un projet a verrouillé ses dépendances ou s’il possède des dépendances téléchargées dynamiquement, il est actuellement essentiel que le projet procède à une auto-inspection et à une divulgation publique.

Au moment de la rédaction, plusieurs projets de wallets ou d’applications, dont MetaMask, Phantom, Aave, Fluid, Jupiter, ont tous déclaré ne pas être affectés par cet événement. Par conséquent, en théorie, les utilisateurs peuvent utiliser en toute confiance les wallets confirmés comme sûrs pour accéder de manière sécurisée aux protocoles également confirmés comme sûrs. Cependant, pour les wallets ou projets qui n’ont pas encore fait l’objet d’une divulgation de sécurité, il peut être plus prudent d’éviter temporairement leur utilisation.