Nous avons vraiment évité une menace majeure

• La récente attaque de la chaîne d’approvisionnement survenue dans l’écosystème des paquets NPM aurait en réalité pu provoquer des dégâts bien plus importants
• Les attaquants n’ont utilisé le code malveillant que pour modifier des adresses de portefeuilles de cryptomonnaies en exploitant des bibliothèques populaires
• Cette attaque a été menée en volant les informations de double authentification de développeurs via des e-mails de phishing sophistiqués
• Si elle avait été utilisée sous une forme plus destructrice (par exemple le vol de clés API), elle aurait pu entraîner des dommages massifs
• Le texte souligne que toute dépendance est potentiellement risquée et insiste sur l’importance de comprendre l’ensemble de l’arbre des dépendances

---

Vue d’ensemble de l’attaque et inquiétudes

• Récemment, des paquets populaires de NPM, l’un des plus grands écosystèmes de paquets, ont été exposés à une attaque
  • Exemples de fonctions : gestion des couleurs dans le terminal, correspondance entre noms de couleurs et RGB, décorateurs de débogage de fonctions, utilitaires de détection de valeurs de type tableau, etc.
• Ces dépendances courantes sont largement utilisées et, une fois le code introduit, il a de fortes chances d’être déployé immédiatement en production
• Si l’attaque avait inclus un proxy malveillant, le vol de clés API ou d’autres actions graves, les conséquences auraient pu être bien pires
• En pratique, ce malware se contentait de modifier les adresses de paiement en cryptomonnaie dans des portefeuilles en ligne (comme MetaMask)

La sophistication de l’attaque de phishing

• Le point de départ de l’attaque a été un e-mail de phishing extrêmement bien conçu
  • Il donnait une impression personnalisée en utilisant le nom d’utilisateur NPM
  • Il cherchait à inspirer confiance avec un message demandant de « changer le mot de passe et les identifiants de double authentification pour des raisons de sécurité »
  • Combiné au mode de fonctionnement particulier de NPM, le contenu était suffisamment crédible pour tromper facilement un utilisateur ordinaire
  • Une date limite précise ajoutait un sentiment d’urgence et poussait à cliquer sur le lien de phishing dans un moment d’inattention ou de surcharge
  • Il utilisait un domaine en .help ressemblant au domaine officiel de NPM
• L’élément le plus visible était essentiellement l’utilisation de « npmjs.help » à la place du domaine officiel
  • De nos jours, de nombreux nouveaux gTLD (Generic Top Level Domain) sont largement utilisés pour des blogs, de la documentation, etc., ce qui peut aussi paraître naturel

Les dommages potentiels de l’attaque

• L’e-mail de phishing permettait, après vol des informations de double authentification, d’injecter du code d’attaque puis de publier de nouveaux paquets
• Des bibliothèques très largement utilisées comme is-arrayish, color-string, color-name ont été visées
  • Si le code malveillant avait dépassé le simple détournement de cryptomonnaies pour aller jusqu’au vol de clés API, les conséquences auraient pu être catastrophiques
  • Par exemple, une exposition massive de clés API OpenAI ou AWS aurait pu causer des dégâts durables et à grande échelle
• En réalité, la plupart des bibliothèques infectées sont surtout utilisées dans des outils en ligne de commande, ce qui limitait d’autant l’intérêt d’un vol de cryptomonnaies

Un ciblage de l’écosystème Web3 et la stratégie des attaquants

• Cette attaque semble avoir principalement visé les utilisateurs Web3 (paiement via navigateur, etc.)
  • En choisissant comme cibles des bibliothèques génériques sans lien direct avec le Web3, les attaquants ont évité une détection et un blocage rapides par l’écosystème Web3
  • Exemple : même en surveillant de près les bibliothèques liées à MetaMask, il est difficile de prévoir qu’une attaque surgira dans un utilitaire lié aux couleurs de texte

Les enseignements pour l’écosystème de développement

• Ce cas rappelle avec force que tous les paquets de dépendance peuvent en réalité être malveillants
  • Il existe des limites pratiques au fait de contrôler ou surveiller en permanence l’intégralité de l’arbre des dépendances
  • Cela montre aussi que, sous la pression du temps et des déploiements rapides en production, les vérifications de sécurité risquent inévitablement d’être reléguées au second plan
• À l’avenir, la compréhension de l’ensemble des dépendances d’un projet et une gestion prudente gagneront encore en importance

Conclusion et avertissement

• Ce contenu ne cherche ni à blâmer ni à tenir quiconque pour responsable ; il est important de reconnaître que tout le monde peut être exposé à une attaque de phishing
• La situation ayant pu évoluer depuis la publication de ce billet, il convient de vérifier directement en cas d’erreur ou de doute sur son contenu

Tags:

[GN⁺]

Commentaire Hacker News

• L’attaque sur la supply chain de nx via npm a été une balle que beaucoup d’entreprises n’auraient pas pu éviter : il suffisait d’installer le plugin nx de VS Code pour qu’il vérifie automatiquement la dernière version de nx sur npm, et si vous aviez une session GitHub active (par exemple avec un compte d’entreprise connecté via GH CLI) ou des informations sensibles dans un fichier .env, tout aurait pu être exfiltré ; ce n’était pas quelque chose qu’on pouvait éviter simplement en figeant les dépendances ou en gérant correctement les mises à jour de sécurité ; il faut un changement bien plus profond dans cet écosystème ; voir l’avis de sécurité officiel pour plus de détails

  • J’évite tout ce qui touche à NPM ; la seule exception, c’est le compilateur TypeScript, mais si une réécriture en Go arrive, je compte aussi m’en débarrasser ; avec Go, on peut au moins spécifier une version minimale, et ce qu’on télécharge n’est jamais exécuté pendant la compilation ; avec NPM, la source diffère souvent de GitHub, donc je trouve ça peu fiable
  • Les extensions d’éditeur sont des cibles d’attaque très attrayantes, parce qu’elles s’installent et se mettent à jour automatiquement dans des environnements de développement à haut risque ; je trouve étonnant qu’on n’ait pas encore vu de vague massive de rachats malveillants comme pour les extensions de navigateur ; j’ai entendu dire que l’équipe de VS Code investit beaucoup dans la détection de malwares, mais je me demande si tous les éditeurs comme Sublime ont des processus de vérification comparables
  • Je garde tous les paquets et toutes les bases de données en local, et je travaille en mode avion sur ma machine de dev ; je n’active Internet que pour faire un git push

• On est vraiment passés à un cheveu de la catastrophe ; j’ai du mal à croire qu’un attaquant ayant obtenu l’accès à ce type de paquets n’ait mis en ligne qu’un simple outil de vol de crypto ; à leur place, j’aurais l’impression qu’il valait le coup d’investir une semaine de plus pour y intégrer un exploit plus sophistiqué : clés API, ajout de clés publiques SSH, fuite d’IP de serveurs, profils navigateur ou jetons de session sur les machines des développeurs, voire les informations de carte Amazon sur mon desktop ; il y a énormément de choses à voler, et même sans les utiliser soi-même, ça se revend facilement sur des forums du dark web ; je me demande parfois si les cybercriminels vraiment compétents ont déjà des jobs stables et très bien payés dans la tech, et qu’il ne reste plus que ce genre d’attaques basiques

  • Cette méthode d’attaque devait forcément être découverte très vite, donc au lieu d’être discrète, elle visait apparemment une prise de contrôle totale du compte, avec une stratégie de type « frapper vite et repartir » ; il fallait une méthode automatisable pour extraire le maximum d’argent en quelques heures, et la crypto était la réponse évidente ; sauf à avoir un backdoor assez propre pour résister à l’examen de la moitié du monde, il n’y avait aucune raison de préparer quelque chose de plus long
  • La crypto volée ne peut pas être annulée, remboursée ni récupérée, donc c’est concrètement une ressource qu’on peut encaisser à coup sûr ; à l’inverse, les API ou les clés SSH des développeurs ont presque zéro valeur, et même dans le meilleur des cas, pour monétiser ça il faut souvent finir par convertir en crypto
  • Entrer vite, voler des centaines de milliers de dollars, sortir, puis recommencer quelques mois plus tard : en évitant correctement la police, on peut vivre comme ça sans souci ; même voler des clés AWS ne rapporte pas tant que ça ; il y a aussi des criminels qui ciblent les mots de passe ou les bases de données de gestionnaires de mots de passe, mais au final ils finissent souvent par viser des sites liés à la crypto ; il y a probablement aussi, en ce moment même, des gens qui attendent patiemment le bon moment pour infiltrer des entreprises, et ceux-là resteront invisibles jusqu’à ce qu’ils réussissent
  • Ce n’est pas une opportunité unique dans une vie ; à l’avenir, les criminels vont se rendre compte qu’en ne ciblant que quelques « développeurs », ils peuvent accéder très facilement à des millions de dollars, et on verra apparaître des méthodes encore plus audacieuses ; si vous maintenez du code open source, vous devriez vraiment réfléchir au niveau de protection de votre identité physique en ligne

• Ma tendance à procrastiner est une technique de survie ; j’attends que les autres fassent les bêta-tests à ma place ; autrefois, au bureau, j’ai utilisé Microsoft Office 2000 pendant 12 ans, ce qui m’a offert 10 années de tranquillité sans problèmes de montée de version ni besoin de reformation ; et je ne clique jamais sur les liens présents dans les e-mails

  • C’est pareil pour ma Honda et pour Kubernetes ; comme j’ai gardé très longtemps une voiture de 2006, j’ai traversé sans les subir plusieurs générations de petits et gros problèmes d’intégration voiture-téléphone, et ce n’est que récemment, sur un modèle 2023, que la connexion avec l’iPhone est enfin devenue vraiment fluide ; pour Kubernetes aussi, le fait d’avoir longtemps repoussé sous la pression de mon manager m’a évité une grande partie des galères de migration, maintenant que EKS, GKE, etc. sont enfin suffisamment mûrs ; si j’avais suivi le mouvement il y a 6 ou 7 ans, j’aurais probablement énormément souffert pour rien
  • Dans l’écosystème npm, si vous ne vous mettez pas à jour toutes les 54 secondes, vous êtes déjà très en retard
  • C’est efficace contre les nouveaux paquets malveillants, mais pas toujours quand un logiciel déjà infecté se prend en plus un ver
  • Je répondrai demain
  • « Retarder par défaut l’utilisation d’une nouvelle version de deux semaines » est une défense très efficace contre les attaques sur la supply chain

• Ce serait difficile pour une petite startup, mais pour un acteur majeur comme npm, je pense qu’il faudrait réserver toutes les variantes de domaine dans tous les TLD, comme npm.io, npm.sh, npm.help, etc. ; le fait qu’un attaquant ait obtenu le domaine npm.help a rendu cette attaque encore plus efficace

  • On voit aussi des cas comme AWS, qui dit à ses clients de faire attention au phishing, puis change l’adresse d’envoi officielle des factures de [e-mail] à [e-mail] ; quand on voit ça pour la première fois, ça ressemble presque à un e-mail de phishing, mais on vous dit que c’est officiel, donc ça crée de la confusion ; même l’e-mail d’annonce préalable avait l’air d’un phishing, au point que je n’ai pas ouvert le PDF joint avant d’avoir reçu une vraie facture ; les entreprises disent aux clients de se méfier du phishing, tout en créant elles-mêmes une confusion inutile
  • Il existe plus de 1 500 TLD, et même si certains sont restreints ou liés à des codes pays, je me demande quel serait le coût annuel réel d’un enregistrement de masse de tous ces TLD ; il existe probablement des services SaaS qui gèrent ça
  • Quand on regarde la liste des TLD, il y en a tellement que même pour un gros acteur, essayer de tout réserver pour empêcher le phishing ne peut pas être une solution complète, même si ça vaut peut-être le coup d’en sécuriser une partie
  • La première chose à faire, c’est de vérifier s’il s’agit bien d’un domaine officiel ; je me méfie systématiquement des domaines enregistrés récemment, des registrars à bas prix, ou de ceux qui expirent bientôt ; et si, en plus, le lien met une pression du type « il n’y a pas le temps » avec une échéance urgente, j’enquête encore davantage ; les communications officielles devraient utiliser uniquement le domaine principal connu, ou un sous-domaine clairement rattaché
  • Les variantes de nommage autour de npm et des domaines proches sont pratiquement infinies, donc la stratégie consistant à tous les réserver est irréaliste ; rien qu’au nom de domaine, on devrait déjà soupçonner un phishing, mais en pratique des domaines comme npmjs.help seront quand même cliqués par erreur

• Et si quelqu’un combinait une très grande minutie à la Jia Tan avec la faiblesse de notre sécurité actuelle, côté plugins d’éditeur, shell userland, etc. ? Les outils pour développeurs tournent avec des privilèges de superutilisateur, alors que ce sont souvent les moins vérifiés ; moi non plus, je ne peux pas auditer un par un elisp, neovim, vscode, ni même les petits outils userland ; dans le meilleur des cas, je les prends via nixpkgs ; il suffirait qu’un jour apparaisse un plugin VSCode un peu meilleur, puis d’attendre 1 ou 2 ans, et c’est terminé ; GG

  • J’espère qu’un jour quelqu’un résoudra enfin le problème du xkcd 1200

• Des wallets comme MetaMask étaient ciblés, mais j’ai entendu dire que MetaMask était plutôt bien protégé contre ce genre d’attaque grâce à son module d’isolation LavaMoat ; j’aimerais vraiment lire une analyse détaillée du niveau de protection réel ; je n’ai pas de lien direct avec MetaMask, mais je suis curieux de l’efficacité de ce type de réponse sécurité, qui arrive souvent lentement par rapport aux attaques ; j’ajoute à titre de référence cet article lié

• À l’affirmation « la vérité, c’est qu’avec ce genre d’attaque de phishing on finit forcément par se faire avoir un jour », je répondrais que, personnellement, probablement pas ; j’ai pour règle de ne jamais saisir d’informations d’authentification via un lien reçu par e-mail que je n’ai pas explicitement demandé moi-même, par exemple pour une réinitialisation de mot de passe ; en 2025, c’est à mon avis une compétence de sécurité que tout le monde devrait avoir

  • Dire « ce genre » de phishing donne l’impression d’une attaque sophistiquée, alors qu’en réalité c’est encore une fois un développeur qui s’est fait avoir par un e-mail de phishing tout ce qu’il y a de plus banal ; c’est une erreur très basique, à un niveau où parfois même quelqu’un du service administratif ne se ferait pas piéger ; bien sûr, tout le monde peut se tromper, mais je pense qu’une négligence évidente et des erreurs d’amateur sont largement responsables de ce genre de répétitions

• Contrairement à ce qu’indique l’article en disant que « tout le malware s’est contenté de remplacer les adresses de wallets crypto », la raison pour laquelle MetaMask n’a pas été affecté est la suivante :

1. au moment de l’attaque, le paquet n’avait pas été mis à jour immédiatement ;
2. MetaMask était protégé par LavaMoat à la fois à l’installation et à l’exécution ; en revanche, cette payload malveillante visait des pages web utilisant d’autres wallets qui interagissent avec MetaMask ; pour référence, j’ai participé au développement de LavaMoat ; voir le GitHub de LavaMoat pour plus d’informations

• Les grands dépôts de paquets open source ont besoin de solutions de sécurité bien plus solides, ou au moins d’un ensemble central de paquets fiables et audités ; c’est pareil dans les écosystèmes Python, Rust, etc., qui fonctionnent eux aussi largement sur la confiance

  • Le problème fondamental de npm, c’est l’absence d’obligation de namespace ; les débutants en Java se plaignent parfois que Maven n’est pas aussi simple que npm, mais plus le temps passe, plus j’apprécie l’obsession de Maven pour la qualité, notamment via son système d’espaces de noms ; le POM xml est certes pénible, mais sa gestion conservatrice du changement inspire confiance ; article lié : Pourquoi les namespaces comptent dans les dépôts open source publics
  • Dans un cas comme celui-ci, où le compte du mainteneur du paquet lui-même est compromis, des solutions structurelles comme le namespace ne servent plus à rien ; la seule vraie défense est d’empêcher qu’une nouvelle release soit appliquée immédiatement, en introduisant un délai
  • Les distributions Linux reposent elles aussi sur la confiance, mais pour obtenir le droit d’y publier un paquet, il faut prouver qu’on est digne de confiance, et tout un système de vérification de cette confiance existe ; NPM ressemble plutôt à un système totalement ouvert où n’importe qui peut publier

• L’affirmation « il n’y a aucun moyen d’empêcher ça » n’apparaît que dans les écosystèmes où les compromissions sont les plus fréquentes

  • C’est exactement ça, le problème ; c’est une conclusion d’une paresse absolue