Dans l’après-midi du 8 septembre, une attaque a eu lieu contre la chaine d’approvisionnement de plusieurs paquets NPM. Les dégâts ont été limités et tout est vite rentré dans l’ordre. Mais les conséquences auraient pu être bien pires, limitées uniquement par les compétences des pirates. L’affaire relance les débats autour de l’authentification et du contrôle de la provenance des modifications.

Elle est qualifiée désormais de plus grande attaque contre la chaine d’approvisionnement jamais enregistrée. Une telle attaque consiste pour rappel à viser la chaine menant à la production d’un logiciel ou d’un service. Si elle aboutit, un code se retrouve distribué ou mis à disposition des victimes, qui croient récupérer un logiciel, la dernière version d’un composant, etc. Elle permet d’arroser un nombre important de personnes, d’autant plus que le composant ou logiciel est populaire.

Dans l’après-midi du lundi 8 septembre, des pirates ont ainsi compromis le compte NPM (Node Packet Manager, gestionnaire de paquet par défaut pour Node.js) d’un développeur. La récupération des accès leur a permis d’infecter le code de 18 paquets : backslash, chalk-template, supports-hyperlinks, has-ansi, simple-swizzle, color-string, error-ex, color-name, is-arrayish, slice-ansi, color-convert, wrap-ansi, ansi-regex, supports-color, strip-ansi, chalk, debug, ansi-styles.

Certains sont téléchargés des centaines de millions de fois par semaine. Pourtant, tout a été réglé en deux heures environ et la casse a été limitée. Que s’est-il passé ?

L’ingénierie sociale, toujours elle

L’histoire commence avec une détection de l’entreprise belge Aikido. Elle est spécialisée dans la sécurité, et plus particulièrement dans la surveillance des mises à jour de code dans les principaux dépôts open source. Comme elle raconte dans un billet de blog, elle détecte le 8 septembre à 15h16 (heure de Paris) des modifications suspicieuses dans 18 paquets. Ils sont très populaires sur NPM : ensemble, ils cumulent deux milliards de téléchargements par semaine.

L’analyse du code révèle sa fonction : intercepter silencieusement l’activité crypto et web3 dans le navigateur, manipuler les interactions avec le portefeuille et rediriger les paiements vers des comptes contrôlés par les pirates. Le code malveillant peut détourner à la fois le trafic réseau et les API des applications, indique Aikido. « Ce qui le rend dangereux, c’est qu’il fonctionne à plusieurs niveaux : modifier le contenu affiché sur les sites Web, falsifier les appels API et manipuler ce que les applications des utilisateurs croient signer », ajoute l’entreprise.

La société belge indique avoir alors contacté le développeur concerné, Josh Junon, surnommé Qix. Celui-ci répond alors qu’il a découvert avoir été piraté. Comme il l’indique lui-même dans un message sur BlueSky deux heures plus tard, il dit avoir été victime d’un email qui l’invitait à réinitialiser ses codes d’authentification à deux facteurs (2FA). Le courrier semblait parfaitement légitime selon lui, avec un lien renvoyant vers une copie conforme de la page de connexion de NPM. Cette page interceptait les informations d’authentification et le jeton 2FA pour les envoyer aux pirates. Après quoi, ces derniers ont simplement modifié l’adresse de connexion utilisée pour se connecter à NPM.

Le 9 septembre, Josh Junon a publié un message d’excuses sur Hacker News, dans lequel il admet honteusement : « yep I got pwned ». Le même jour, jFrog indiquait de son côté que la campagne continuait et que de nouveaux paquets contaminés avaient été découverts, dont DuckDB. Toujours le 9 septembre, SlowMist avertissait que d’autres développeurs recevaient le même e-mail, signe que Josh Junon n’était pas un cas isolé.

Tout s’enchaine très vite

Une chaine d’approvisionnement contaminée sur des paquets aussi populaires aurait constitué une catastrophe pour de nombreux produits. Ces attaques sont notamment très efficaces contre des composants impliqués dans le web de manière générale. Or, avec la multiplication des applications web encapsulées, cela pouvait signifier une diffusion à très grande échelle du code vérolé. Pourtant, tout s’est achevé en quelques heures, sans grande casse.

Sur le blog de la Security Alliance, on peut lire dans le billet du 9 septembre une note ironisant sur les 5 cents d’ETH ou encore les 20 dollars d’un memecoin. Dans les heures qui ont suivi la compromission, seuls 588 dollars de transactions auraient été détectés. Ce qui fait dire à l’Alliance que le plus gros impact financier de l’attaque réside finalement dans « les milliers d’heures passées collectivement par les équipes d’ingénierie et de sécurité du monde entier à nettoyer les environnements compromis, et les millions de dollars de contrats de vente qui seront inévitablement signés à la suite de cette nouvelle étude de cas ».

Cité par Brian Krebs, le pentester Philippe Catureli, responsable sécurité chez Seralys, s’en étonne également : « Ce qui est fou, c’est qu’ils ont compromis des milliards de sites Web et d’applications juste pour cibler quelques crypto-monnaies. Il s’agissait d’une attaque de la chaîne d’approvisionnement, et cela aurait facilement pu être quelque chose de bien pire que la récolte de crypto-monnaies ».

Même son de cloche chez Florian Roth, chercheur en sécurité chez Nextron Systems : « Étant donné que la plupart des entreprises exécutent au moins une application React ou Angular, elles ont eu la possibilité d’exécuter du code sur des millions de systèmes dans des milliers d’organisations. Et ils l’ont utilisé pour lacher un voleur de cryptomonnaies obscurci de manière amateur, ont été attrapés par des règles élémentaires de détection, et le problème a été résolu après 2 heures ». Pas mieux du côté du chercheur Kevin Beaumont.

L’authentification des développeurs à nouveau en question

Dans son billet de blog, Aikido relève également le vaste danger évité de peu. De faibles conséquences qui ne semblent dues qu’au manque de compétences des pirates, en dépit de leur réussite sur la chaine d’approvisionnement.

Pour montrer à quel point ce type d’incident peut être grave, la société belge rappelle une autre compromission qui s’est déroulée fin août. Là aussi, un autre développeur NPM avait été visé, permettant la récupération de ses identifiants et l’insertion d’un code malveillant dans nx, une boite à outils pour le développement open source, totalisant six millions de téléchargements par semaine.

Le code malveillant avait servi à analyser l’ordinateur du développeur pour y récupérer des jetons d’authentification, ainsi que des clés SSH et API. Ces informations n’ont cependant pas été transmises aux pirates : elles ont été publiées dans un référentiel public créé pour l’occasion dans le compte GitHub du développeur, afin qu’elles soient visibles de tous et téléchargeables.

À Brian Krebs, Charlie Eriksen, chercheur chez Aikido, affirme que tous les paquets les plus populaires devraient exiger des attestations pour les modifications de code. De manière plus générale, il est d’avis que des plateformes comme GitHub et NPM devraient relever le niveau de sécurité, en s’assurant que les commits (une proposition de modification du code, pour schématiser) sont proposés par des personnes étant bien qui elles prétendent être.

S’il s’en est fallu de peu pour échapper à une catastrophe, les évènements ne semblent pas avoir surpris les chercheurs en sécurité, qui répètent les mêmes éléments depuis des années. Kevin Beaumont s’en moquait justement avec acidité, rappelant – encore une fois – que certaines des briques logicielles les plus utilisées ne sont gérées que par une poignée de personnes. Renvoyant une fois de plus au célèbre dessin de xkcd sur les dépendances.

Rappelons également que l’authentification à facteurs multiples, si elle apporte un gain majeur de protection, n’est pas absolue. En août 2022, Microsoft avait expliqué en détail par exemple comment un acteur malveillant avait mis en place toute une infrastructure pour récupérer des jetons d’authentification, via notamment des serveurs mimant un comportement légitime. Ce type d’attaque passe systématiquement par la compromission d’une personne, le plus souvent par un e-mail soigneusement préparé.