En septembre, j'ai publié un article sur l'incident NPM et expliquant pourquoi l'exploitation initiale n'est que le point de départ d'une attaque.
Cette attaque était ciblée et assez simple. Un responsable de maintenance a été victime d'une tentative d'hameçonnage, quelques paquets ont été corrompus, et l'objectif se limitait au vol de cryptomonnaie.
Shai-Hulud adopte une approche très différente. Il ne repose pas sur le fait que la victime clique sur quoi que ce soit et ne s'arrête pas à la première machine sur laquelle il atterrit. Au contraire, il utilise la confiance intégrée dans l'écosystème logiciel pour passer d'un environnement à l'autre. Ce faisant, il transforme la chaîne d'approvisionnement elle-même en un réseau de distribution.
Un Worm à la vue de tous
Wiz Research vient de publier une excellente analyse des comportements techniques derrière Shai-Hulud. Voici un bref résumé du worm ce worm dans la pratique :
1. L'installation devient exécution
Dès qu'un développeur ou un pipeline CI installe un paquet infecté, la charge utile s'exécute automatiquement. Aucun message ni indicateur évident ne signale qu'un événement inhabituel est en cours. Le worm dans les étapes de compilation courantes, ce qui explique pourquoi son exécution initiale passe inaperçue.
2. Il contourne les contrôles de sécurité courants en changeant de runtime.
La plupart des développements JavaScript s'appuient sur Node.js, le moteur derrière npm et celui que la plupart des équipes surveillent. Les outils de sécurité, la journalisation et l'analyse sont conçus autour de Node.
Shai-Hulud contourne cette difficulté en téléchargeant et en exécutant sa charge utile avec Bun, un nouveau runtime haute performance qui n'est généralement pas surveillé. Pour le système, Bun ressemble à un outil de développement comme les autres. Pour l'attaquant, c'est une voie discrète avec beaucoup moins de contrôles.
Ce simple décalage d'exécution aide le worm à contourner bon nombre des garde-fous sur lesquels les équipes comptent s'appuyer.
3. Il collecte tous les accès qu'il peut trouver.
Une fois lancé, le malware recherche systématiquement un accès. Il recherche :
- jetons NPM
- Identifiants GitHub
- Secrets CI/CD
- Clés API
- Cloud provenant des services de métadonnées
Les ordinateurs portables des développeurs, les serveurs de compilation et cloud sont traités de la même manière. Si un système a accès, le worm le worm .
4. Il divulgue les données volées au public de manière intentionnelle.
Au lieu de renvoyer les données à un serveur de commande et de contrôle, le worm crée des référentiels GitHub publics sous le compte de la victime et y télécharge les secrets volés. Cela élimine le besoin d'une infrastructure cachée et expose les identifiants sensibles à toute personne sachant où les trouver.
Comme Dmitriy l'a dit lors du podcast que nous avons enregistré sur Shai Hulud : «C'est comme diffuser des informations volées sur une radio publique. »
5. Il se propage en utilisant la confiance existante de la victime.
Si un responsable compromis gère plusieurs paquets, Shai-Hulud republie des versions malveillantes sur l'ensemble de ceux-ci. Si un jeton GitHub donne accès à plusieurs référentiels, ces référentiels deviennent les prochains points d'injection. Le worm en profitant de la confiance que la victime accorde déjà à l'écosystème. C'est ainsi qu'il passe d'une poignée de paquets à des centaines.
6. Il installe une porte dérobée persistante via GitHub Actions.
Le malware installe un runner GitHub Actions auto-hébergé sur la machine de la victime et dépose un workflow qui se déclenche chaque fois que quelqu'un ouvre une discussion GitHub. Cela permet à l'attaquant d'avoir un point d'ancrage discret et durable.
Les commandes exécutées via un fil de discussion s'exécutent directement sur le système compromis tout en s'intégrant à l'automatisation normale.
7. Il est équipé d'un essuie-glace pour les retours en arrière destructifs.
Dans certaines conditions, le malware effacer des fichiers de l'hôte. Tous les environnements ne déclenchent pas cette fonctionnalité, mais celle-ci ajoute un niveau de risque supplémentaire : l'attaque ne se limite pas au vol, elle peut également perturber complètement le développement.
Le problème sous-jacent : les chaînes d'approvisionnement propagent la confiance plus rapidement que les défenseurs ne peuvent la surveiller
Tout ce que fait Shai-Hulud s'aligne sur les processus normaux de développement et d'automatisation :
- installation des dépendances
- exécution de scripts
- packages de publication
- parler à GitHub
- interrogation cloud
Aucun de ces comportements n'est suspect en soi. Il s'agit d'opérations courantes.
C'est ce qui rend le worm . Il ne se comporte pas comme malware. Il se comporte comme un outil de développement et s'appuie sur la confiance dont bénéficient par défaut les workflows de développement :
- Les machines des développeurs conservent des jetons à longue durée de vie.
- Les pipelines CI exécutent automatiquement le code.
- Cloud comportent des autorisations étendues.
- Le contrôle de source sert à la fois de plateforme collaborative et de moteur d'automatisation.
Shai-Hulud suit simplement la confiance.
Observer le Worm son comportement, et non ses signatures
Les attaques modernes visant la chaîne d'approvisionnement se révèlent à travers des schémas d'activité plutôt que des indicateurs statiques. Shai-Hulud laisse des signaux tels que :
- Un jeton GitHub créant des dizaines de dépôts à partir de rien
- Un programme CI lisant cloud à un volume qui ne correspond pas à sa tâche.
- Un poste de travail exécutant soudainement un nouveau programme d'automatisation
- cloud utilisant des services qu'elle n'a jamais touchés
- Une machine qui télécharge de grandes quantités de données vers GitHub
Chaque action est ordinaire. La séquence ne l'est pas. C'est là que Vectra AI en jeu. La plateforme n'essaie pas de bloquer les installations de paquets. Elle observe ce qui se passe après l'exécution du code, à travers les systèmes d'identité, les réseaux et cloud . Elle met en corrélation les activités inhabituelles des comptes, les mouvements de données inattendus et cloud qui ne correspondent pas aux modèles établis. Ce contexte aide les équipes de sécurité à voir la chaîne d'attaque dans son ensemble plutôt qu'une série d'événements isolés. Et dans les incidents liés à la chaîne d'approvisionnement comme Shai-Hulud, le contexte est primordial.
Si vous souhaitez découvrir comment la Vectra AI fonctionne dans la pratique, vous pouvez la découvrir dans notre démo autoguidée.