L’écosystème NPM (Node Package Manager) fait actuellement face à une nouvelle attaque sophistiquée. De type chaine d’approvisionnement, elle consiste à infecter un maillon de la chaine de distribution en amont, afin que l’infection se répande automatiquement en aval.

Cette nouvelle attaque, d’un genre différent de celle que nous rapportions récemment, reprend dans les grandes lignes le modus operandi de l’attaque du 27 aout. À ceci près que les pirates ont entièrement automatisé le processus, conduisant à un vol de nombreuses informations d’authentification et à leur publication dans des dépôts publics, créés automatiquement ici aussi par les pirates.

Ce comportement de ver informatique a donné son nom à cette attaque : Shai-Hulud, en référence au célèbre ver des sables de l’univers de Dune. L’ingénieur Daniel Pereira a été le premier à signaler un problème le 15 septembre, avant que les sociétés Socket et StepSecurity prennent le relai. Elles notaient d’abord que 40 paquets avaient été compromis, avant que le chiffre s’envole progressivement : dans la seule journée du 16 septembre, le nombre avait atteint 200 paquets, avant de grimper à près de 500 en fin de journée.

Que fait Shai-Hulud ?

Le ver est auto-répliquant et a plusieurs missions. La principale est de voler des informations d’authentification et de les publier sur GitHub dans des dépôts créés pour l’occasion et rendus publics, afin que tout le monde puisse piocher dedans.

Plus en détail, le ver commence par analyser l’hôte et son environnement d’intégration continue pour chercher tout ce qui ressemble à un secret (au sens cybersécurité du terme, tout ce qui touche à l’authentification). Le ver scanne également, via Trufflehog, les points de terminaison des métadonnées des environnements cloud principaux (dont AWS et GCP) pour récupérer des jetons d’identification (GITHUB_TOKEN, NPM_TOKEN, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY…).

Vient ensuite l’exfiltration, en deux phases. Le ver crée un dépôt Shai-Hulud sur le compte GitHub compromis et y envoie, via un commit, un fichier JSON collectant tout ce qui a été volé : variables d’environnement, éléments d’authentification, informations système, etc. Via un workflow GitHub Actions, ces informations sont envoyées vers un serveur contrôlé par les pirates. Une copie est écrite dans les logs Actions.

Un mécanisme performant de propagation

Enfin, la phase de propagation. Si le vol d’informations a pu mener à des jetons npm, le ver les utilise pour tenter de s’y répliquer. S’il y parvient, toute la chaine recommence, expliquant que des centaines de paquets aient été compromis. Chaque fois qu’un compte privé est ainsi compromis, il est rendu public par le ver, qui en change les paramètres.

« Les versions compromises incluent une fonction (NpmModule.updatePackage) qui télécharge une archive de paquets, modifie package.json, injecte un script local (bundle.js), recompresse l’archive et la republie, permettant ainsi la trojanisation automatique des paquets en aval », explique la société Socket.

Les recommandations faites aux développeurs sont nombreuses, résume Trend Micro : auditer toutes les dépendances (en particulier les paquets mis à jour récemment), révoquer et faire tourner les informations d’authentification (surtout pour les comptes NPM), surveiller d’éventuels signes de présence de Trufflehog ou d’autres outils de balayage, se tenir au courant avec des sources fiables d’informations (dont le registre officiel de NPM), et renforcer la protection des accès ainsi que les politiques de sécurité. Il est notamment conseillé d’activer l’authentification à facteurs multiples (MFA) pour l’ensemble des développeurs et des points d’accès CI/CD.

Encore et toujours du phishing

Comment toute cette attaque a commencé ? Exactement comme les précédentes : par un e-mail frauduleux, demandant au développeur de renouveler son authentification à deux facteurs. Un lien proéminent l’emmenait vers une page ressemblant trait pour trait à celle de NPM, mais permettait aux pirates de capter le jeton d’authentification et les identifiants. Après quoi, les informations étaient utilisées pour accéder au dépôt et débuter l’infection.

En l’occurrence, c’est le dépôt du paquet ctrl/tinycolor qui a été contaminé en premier. Via une mise à jour malveillante, le paquet contenait une fonction NpmModule.updatePackage) capable d’enchainer les opérations : télécharger un tarball, modifier le fichier package.json, injecter un script local, rempaqueter le tout et le republier. C’est ce comportement qui a été repéré initialement par Daniel dos Santos Pereira. Mais le mal était déjà fait, car ctrl/tinycolor est un paquet populaire : 2,2 millions de téléchargements par semaine en moyenne.

Car les paquets téléchargés et installés sur des postes clients contiennent également une charge utile leur étant destinée. Comme pour l’attaque précédente, on y trouve un voleur de cryptomonnaies, qui permet les interceptions des transferts au sein du navigateur et leur orientation vers des portefeuilles contrôlés par les pirates.

Vers une empreinte durable ?

On ne connait pas encore l’ampleur des conséquences de cette campagne. Shai-Hulud risque cependant de remettre en question le modèle de gestion de nombreux dépôts et accentue les questionnements autour de la sécurité. Toutes les sociétés ayant formulé des recommandations sur le sujet reviennent toujours à deux consignes : la généralisation de l’authentification forte à facteurs multiples et la surveillance continue de l’activité sur les dépôts.

Par le nombre de paquets NPM touchés, l’attaque pourrait également remettre en cause le fonctionnement habituel de l’écosystème open source et à sa confiance inhérente. À une époque où les applications web (encapsulées ou non) sont omniprésentes, une contamination de la chaine d’approvisionnement peut signifier rapidement des millions de machines infectées.

Et si cette contamination vous rappelle, en d’autres circonstances, le fiasco mondial de la panne CrowdStrike, le dépôt de l’entreprise a été touché par Shai-Hulud, de multiples paquets ayant été contaminés.

Pour l’instant, on ignore si l’attaque du 8 septembre peut être considérée comme une première manifestation de la nouvelle. La méthode de départ est la même, mais l’exécution technique semble bien plus sophistiquée aujourd’hui. Dans son déroulement, Shai-Hulud ressemble davantage à l’attaque de fin août, même si – là encore – le périmètre et l’automatisation sont bien supérieurs. Si les auteurs sont les mêmes, alors les attaques précédentes ont peut-être été des galops d’essai.