GitLab découvre une vaste attaque de la chaîne d’approvisionnement NPM

• Une variante de malware destructrice se propage dans l’ensemble de l’écosystème npm, et l’équipe sécurité de GitLab l’a détectée
• Le malware est une forme évoluée de Shai-Hulud, avec une structure de propagation de type ver qui infecte automatiquement les autres packages des développeurs compromis
• Après avoir dérobé des identifiants sur GitHub, AWS, GCP, Azure, etc., il exfiltre les données vers des dépôts GitHub contrôlés par les attaquants
• Il intègre un « dead man’s switch » qui supprime immédiatement les données des utilisateurs si l’accès à GitHub et à npm est bloqué simultanément
• GitLab a confirmé que ses propres systèmes n’avaient pas été infectés et fournit des moyens de détection et de réponse via Dependency Scanning et GitLab Duo Chat

---

Vue d’ensemble de l’attaque

• L’équipe Vulnerability Research de GitLab a détecté une attaque de la chaîne d’approvisionnement à grande échelle dans l’écosystème npm
  • Son système de surveillance interne a découvert plusieurs packages infectés
  • Le malware a été identifié comme une variante de Shai-Hulud
• Le malware infecte automatiquement les autres packages d’un développeur compromis via une propagation de type ver
• GitLab a confirmé ne pas avoir utilisé de package malveillant dans son propre environnement et a partagé les informations avec la communauté sécurité

Structure interne de l’attaque

• Les packages npm malveillants détectés par le système de surveillance interne exécutent les fonctions suivantes
  • Collecte d’identifiants GitHub, npm, AWS, GCP et Azure
  • Envoi des données dérobées vers des dépôts GitHub contrôlés par les attaquants
  • Infection automatique des autres packages de la victime
  • Exécution d’une charge destructrice si l’accès à l’infrastructure est bloqué
• Plusieurs packages infectés ont été confirmés, et l’enquête se poursuit

Analyse technique : déroulement de l’attaque

Vecteur d’infection initial

• Le malware s’introduit dans le système via un processus de chargement en plusieurs étapes
  • Un script setup_bun.js est ajouté au package.json du package infecté
  • En apparence, il se fait passer pour un programme d’installation du runtime JavaScript Bun
  • En réalité, il exécute bun_environment.js (10 MB, charge utile obfusquée)
• L’ensemble combine un petit chargeur et une charge utile obfusquée volumineuse pour échapper à la détection

Collecte d’identifiants

• Dès son exécution, il collecte des tokens et secrets depuis diverses sources
  • Tokens GitHub (ghp_, gho_)
  • Identifiants AWS, GCP et Azure
  • Tokens npm (.npmrc et variables d’environnement)
  • Il scanne tout le répertoire personnel avec l’outil Trufflehog pour rechercher des clés API, mots de passe, historique Git, etc.

Réseau d’exfiltration des données

• Avec les tokens GitHub volés, il crée des dépôts publics contenant la description “Sha1-Hulud: The Second Coming.”
  • Ces dépôts servent de boîte de dépôt de données
  • Il y installe des runners GitHub Actions pour assurer la persistance
• Si les privilèges sont insuffisants, il recherche d’autres dépôts portant le même marqueur pour réutiliser des tokens d’autres systèmes
  • Cela forme ainsi un réseau distribué de partage de tokens

Propagation dans la chaîne d’approvisionnement

• En utilisant les tokens npm dérobés, il infecte tous les packages de la victime
  1. Téléchargement du package d’origine
  2. Insertion de setup_bun.js comme script preinstall
  3. Ajout de la charge utile bun_environment.js
  4. Incrémentation du numéro de version
  5. Republier le package infecté sur npm

Dead man’s switch

• Le malware surveille en continu l’accès à GitHub (exfiltration des données) et à npm (propagation)
  • Si les deux canaux sont bloqués, il déclenche immédiatement la destruction des données
• Windows : suppression des fichiers utilisateur et écrasement des secteurs du disque
• Systèmes Unix : écrasement puis suppression des fichiers avec la commande shred
• En cas de suppression en masse des dépôts GitHub ou de révocation massive des tokens npm, il existe un risque que les systèmes infectés suppriment leurs données simultanément

Indicateurs de compromission (IoC)

• Principaux indicateurs de détection
  • Fichier : bun_environment.js (script post-install malveillant)
  • Répertoires : .truffler-cache/, .truffler-cache/extract/
  • Processus : del /F /Q /S "%USERPROFILE%*", shred -uvz -n 1, cipher /W:%USERPROFILE%
  • Commandes : curl -fsSL https://bun.sh/install | bash, powershell -c "irm bun.sh/install.ps1|iex"

Aide à la détection et à la réponse fournie par GitLab

• Les utilisateurs de GitLab Ultimate peuvent vérifier immédiatement leur exposition via les fonctions de sécurité intégrées
  • Si Dependency Scanning est activé, les packages infectés sont détectés automatiquement dans package-lock.json ou yarn.lock
  • Une alerte s’affiche si une merge request inclut un package infecté
• Une détection rapide par requêtes est aussi possible avec GitLab Duo Chat
  • Exemple : “Y a-t-il des dépendances affectées par la campagne Shai-Hulud v2 ?”
  • Le Security Analyst Agent interroge les données de vulnérabilité du projet et fournit une réponse immédiate
• Pour les équipes gérant plusieurs dépôts, GitLab recommande de combiner détection automatisée basée sur CI/CD et réponse rapide basée sur des agents

Perspectives

• Cette attaque est considérée comme une nouvelle forme d’attaque de la chaîne d’approvisionnement qui utilise la destruction des données des victimes pour protéger l’infrastructure de l’attaquant
• GitLab travaille avec la communauté au développement de stratégies de restauration sûres et continue de surveiller les variantes avec ses systèmes de détection automatisée
• L’objectif est de prévenir les dommages secondaires liés au dead man’s switch grâce à un partage précoce des informations

[GN⁺]

Avis Hacker News

• Il y a environ un mois, j’avais besoin de faire une tâche pénible, donc j’ai cherché un paquet NPM
  En lançant brew install npm, j’ai vu déferler une cascade de dépendances ; je me suis arrêté un instant pour peser les risques et les bénéfices, puis j’ai finalement fait marche arrière avec brew uninstall npm
  À la place, j’ai résolu le problème avec un vieux pipeline d’utilitaires Unix et awk, et avec le recul, c’était probablement la meilleure décision

  • La leçon est claire — il ne faut pas utiliser les technologies web pour du scripting local
    NPM est un outil conçu pour résoudre des problèmes de compatibilité navigateur, donc dans un environnement sans navigateur, il apporte une complexité inutile
  • C’est précisément pour cela qu’il faut de la conteneurisation ou de la virtualisation
    Exécuter directement sur son système principal du code issu d’écosystèmes très dépendants comme Node ou Python expose fortement aux attaques sur la supply chain
    C’est pourquoi je n’installe même plus d’interpréteur Python ou JS sur mon système de base
  • Moi aussi, à une époque, je ne lançais npm que dans un conteneur Docker, et on se moquait souvent de moi sur les forums
    J’ai fini par abandonner, mais aujourd’hui j’ai l’impression que j’avais raison
  • J’ai eu une expérience similaire. J’ai vu le nombre de dépendances qu’artillery voulait tirer et j’ai immédiatement laissé tomber
  • Ironiquement, les développeurs disent toujours que le bon sens est la meilleure sécurité, tout en installant d’innombrables paquets non vérifiés avec une simple ligne de commande

• Quelqu’un disait que « si GitHub supprime en masse des dépôts malveillants, des milliers de systèmes pourraient détruire simultanément les données des utilisateurs »,
  c’est presque une prise d’otages — d’où la blague : « tirez sur les otages »

  • Mais les otages (les utilisateurs) se sont eux-mêmes mis en danger, donc au final c’est la conséquence de leur propre choix

• Moi aussi, je suis victime de cette attaque npm
  J’ai été choqué d’apprendre que GitHub CLI stocke des tokens OAuth en clair dans le répertoire HOME
  Si un attaquant y accède, il peut pratiquement tout faire avec mon compte

  • En réalité, GitHub CLI ne stocke le token en clair que lorsqu’il n’y a pas de keyring
    Sur macOS, il est stocké en sécurité dans le trousseau du système — discussion associée
  • Oui, mais les fichiers de cookies du navigateur ont un problème similaire
    Chrome utilise les protections de l’OS, mais Firefox pas encore
    Au final, le contrôle d’accès fondé sur le sandboxing est la vraie solution de fond
  • Tous les tokens devraient être stockés dans un trousseau protégé
    Mais il n’existe pas de solution cohérente entre les plateformes, et même sur macOS, il n’y a pas de méthode parfaite
  • Moi aussi, j’ai été touché. J’ai été infecté après l’installation de Backstage
    Un répertoire ~/.dev-env est apparu et mon laptop s’est transformé en runner GitHub
    Le système de fichiers en lecture seule de Bluefin Linux a peut-être limité les dégâts

• Tout le monde accuse npm, mais GitHub porte aussi une part importante de responsabilité
  Ils n’ont pas détecté assez vite les dépôts malveillants, alors que le problème des dépôts contenant du malware est déjà grave

  • Malgré tout, le fait que ce soit passé par GitHub a permis à certaines personnes de repérer rapidement le problème
    Si cela avait été discrètement exfiltré vers un serveur externe, cela aurait été bien pire
  • Microsoft ne peut pas tout filtrer à lui seul
    Il faut des outils et des pratiques à l’échelle de la communauté
  • Comme GitHub appartient à Microsoft, il y a aussi un lien avec le dépôt de paquets GoLang
    Si des contraintes commerciales ou des restrictions sur les workflows de build apparaissent, cela pourrait créer de gros problèmes
  • On ne peut pas nier que, des deux côtés, le niveau de sécurité est assez ordinaire
  • Ce malware crée des dépôts selon le même schéma, donc une simple règle aurait probablement suffi à le détecter

• Je me demandais pourquoi seul NPM semblait être visé
  Python et Java sont aussi très populaires, mais récemment c’est plus calme

  • Avec NPM, les post-install hooks permettent d’exécuter des commandes arbitraires,
    et la culture des dépendances avec plage de versions accélère la propagation de l’infection
    En Java, on fige généralement des versions précises, donc ce genre d’incident est plus rare
  • Node a une petite bibliothèque standard et une forte dépendance à la communauté
    Donc un seul paquet peut traîner des dizaines de sous-dépendances
  • JS est le langage le plus populaire sur GitHub, donc la surface d’attaque est vaste,
    et comme beaucoup de développeurs ont peu d’expérience, la sécurité y est plus faible
  • Dans la communauté JS, il existe une vraie obsession des versions les plus récentes
    Dans d’autres écosystèmes, on met à jour après validation, alors qu’en JS on upgrade immédiatement
  • NPM a une frontière de sécurité faible
    Il a longtemps permis d’exécuter librement des scripts à l’installation, contrairement à la JVM ou à Python

• Dans .npmrc,

  ignore-scripts=true
  

  permet de réduire la surface d’attaque
  Article associé

  • Je me demande s’il existe un moyen de vérifier à l’avance si un paquet contient des hooks preinstall/postinstall avant de l’installer
  • Si « ignore scripts » est plus sûr, pourquoi cette option existe-t-elle,
    et y a-t-il un risque de casser des dépendances en la désactivant ?
  • Mais au final, dès qu’on exécute du JS dans un environnement Node, on ne peut pas empêcher l’accès aux variables d’environnement ou aux fichiers
  • Sinon, on peut aussi simplement utiliser pnpm

• Ce qui m’inquiète le plus dans cette attaque, c’est le vol d’identifiants
  Si vous avez installé un paquet infecté, vos variables d’environnement ou vos tokens .npmrc ont peut-être été exfiltrés
  Il faut faire tourner immédiatement les tokens et les clés API
  Une rotation régulière n’est pas une réponse post-incident, c’est une mesure préventive

  • Si un développeur réutilise ses mots de passe, c’est vraiment très grave
    Il ne faut pas stocker les identifiants dans des variables d’environnement ou des fichiers, mais utiliser des clés de sécurité ou des fichiers chiffrés
  • Si vous ne savez pas si vous êtes infecté, il faut d’abord suivre l’ordre détection de l’infection → nettoyage → rotation des tokens
  • Cette attaque n’est pas seulement une infection isolée, elle prend tout l’écosystème en otage, ce qui la rend plus dangereuse
    C’est un peu comme injecter une transaction malveillante dans un registre distribué
  • Les secrets doivent absolument être stockés dans un coffre à secrets (secret locker)
    Le vrai problème, c’est que beaucoup de services gardent encore le stockage en clair comme comportement par défaut
  • Et ce malware tente même de détruire les données une fois que la propagation s’arrête

• Comme ce type d’attaque se répète, je me demande pourquoi les systèmes de détection fondés sur l’IA ne fonctionnent pas
  Microsoft parle tellement d’IA qu’on dirait que ça n’est même pas utilisé pour la sécurité de GitHub

  • Mais dire que « l’IA a détecté l’attaque » est déjà devenu un cliché du marketing de la sécurité
    Comme à l’époque où tout ce qu’un firewall bloquait était compté comme une attaque, le terme a perdu de sa substance
  • Dans notre entreprise, on utilise SonaType Lifecycle, qui est censé bloquer ce genre d’attaque grâce à l’IA
    En interne, c’est pris en charge par SonaType IQ Server
  • L’« IA » actuelle est surtout constituée de modèles génératifs, donc davantage orientés vers la génération que vers l’évaluation
    Le projet curl a d’ailleurs réellement souffert de spam de signalements de sécurité générés par IA

• Je me demande s’il y a encore une raison de continuer à autoriser les scripts postinstall
  Ne vaudrait-il pas mieux demander explicitement à l’utilisateur s’il veut les exécuter ?

  • Mais la plupart des utilisateurs cliqueront sur « oui »,
    et sur les serveurs CI il faut des installations non interactives, donc en pratique cela semble difficile

• L’article était très instructif, mais c’est dommage qu’il se termine par une promotion des fonctions de sécurité de GitLab

  • Pour les utilisateurs de GitLab, cela a peut-être été utile
  • Cela dit, ça n’enlève rien à la qualité des analyses