Est-ce que c'est le jour du ver npm?

La communauté Dev! À peine le dernier spectre a-t-il été banni du code que le prochain cauchemar frappe à la porte, sous la forme d'une Une nouvelle version plus agressive du tristement célèbre ver npm, Cette fois-ci, les analystes de la sécurité Shai-Hulud 2.0 baptême.

Et cette fois, non seulement il est plus rapide, mais il vise également une proie encore plus grande: À propos 27 000 données d'accès ont déjà été volés, et le ver attaque maintenant même des célébrités Plates-formes low-code Comme Zapier et Postman. Il semble que les assaillants aient appris de leurs erreurs et aient élégamment contourné tous les cous de bouteilles de la première vague.

Jetons un coup d'œil à ce qui se passe (encore) dans l'écosystème npm, quels paquets sont affectés et ce que vous devez faire maintenant pour que ce ver de sable ne vous arrache pas les identifiants.

Élimine le goulot de la bouteille: La deuxième vague est plus agressive

Les mêmes agresseurs derrière Shai-Hulud 2.0 Comme la première fois, ce n'est pas clair, mais le résultat est le même: une infestation massive de paquets npm.

Lundi après-midi était bruyant heise.de déjà Plus de 425 paquets npm infectés ensemble au-dessus de 100 millions de téléchargements mensuels à venir. Parmi eux, il y a des poissons vraiment épais, comme des paquets de:

• AsyncAPI
• Domaines ENS (Ethereum Name Service)
• Diverses plates-formes API, Low et No-Code, en particulier Zapier et Postman (Regardez l'énorme liste ci-dessous, c'est vraiment mauvais!)

Le ver a apparemment frappé le week-end (du 21 au 23 novembre), les paquets «go-template» et divers référentiels sous «AsyncAPI» ayant été touchés en premier.

Comment vole-t-il les secrets?

Le génie (et l'horreur !) de cette nouvelle version réside dans la manière dont les données d'accès volées sont publiées:

1. Le logiciel malveillant prend le contrôle d'un référentiel.
2. Elle recherche les données d'accès (secrets).
3. Les données volées sont directement sur le compte de la victime sur Github.

Le nouveau dépôt où atterrissent les Secrets porte le titre indéniable «Sha1-Hulud: The Second Coming». Ce faisant, les assaillants ont contourné le plus grand point faible de la dernière éruption: À l'époque, ils utilisaient une plate-forme Webhook dont le point de terminaison était rapidement bloqué. Maintenant, ils utilisent Github lui-même comme emplacement central, ce qui fait du nettoyage de Github un combat contre les moulins à vent, car de nouveaux répertoires de codes sont constamment créés. Lundi après-midi, il y en avait déjà plus de 27 800!

La tactique: Flux de travail décomposés et serveurs C&C

Shai-Hulud 2.0 est construit assez ingénieusement et utilise plusieurs mécanismes pour s'installer:

• Porte dérobée par C&C: Plusieurs workflows Github sont responsables de l'extraction des données d'accès et installent un Backdoor sur la machine infectée. Cette backdoor est pilotée par les Fonction de discussion dans les dépôts infectés, un serveur Command&Control auto-hébergé (C&C) directement sur Github!
• Le code formateur: Un deuxième flux de travail portant le nom inoffensif «Code Formatter» recherche les secrets du compte Github attaqué, puis les charge dans le Format JSON haut.
• Plateforme croisée: Le ver n'est pas difficile et semble avoir un code malveillant personnalisé Linux, Windows et macOS soutenir.

Le moment est d'ailleurs remarquable: L'attaque ne survient que quelques jours avant que npm 9. décembre supprimer les « jetons classiques » pour l’authentification. Les développeurs de Sha1-Hulud voulaient probablement une fois de plus faire un gros plan avant que ce changement de sécurité ne se produise.

Mesures d'urgence: Ce que vous devez faire maintenant

Les travaux de nettoyage battent leur plein, mais tout le monde doit être vigilant et agir maintenant! Wizz, Koi et Aikido ont rapidement signalé la menace.

1. Vérification et élimination

• Vérifiez votre infrastructure: Vérifiez l'ensemble de votre infrastructure de développement pour déceler les signes suspects et, surtout, l'utilisation des éléments suivants: Paquets infectés connus.
• Éliminer immédiatement: Si vous utilisez l'un des paquets: Débarrassez-vous-en immédiatement de votre projet.
• Mises à jour à partir de: Désactivez les mises à jour automatiques des paquets jusqu'à ce que la situation se calme.

2. Tout tourner (IMPORTANT!)

Si vous avez le moindre soupçon d'infection ou si vous avez utilisé un paquet affecté, c'est absolument critique:

• Rotation de toutes les données d'accès! Cela ne s'applique pas seulement aux Github et NPM, mais aussi pour les comptes hyperscalers tels que GCP, AWS et Azure. Tous les secrets doivent être nouveaux!

Les spécialistes sont encore prudents dans l'attribution, mais les méthodes sont similaires à celles du prédécesseur. Il est temps de lever les boucliers!

Liste des paquets concernés (sélection & Principaux)

Pour que vous puissiez vérifier rapidement si vous êtes affecté, voici une sélection des paquets infectés les plus importants et les plus importants, tels qu'ils ont été signalés lundi après-midi:

• @asyncapi/ (de nombreux paquets sont concernés)
• @ensdomains/ (presque tous les paquets sont concernés !)
• @posthog/ (Beaucoup de paquets sont concernés !)
• @postman/ (Beaucoup de paquets sont concernés !)
• @trigo/ (Beaucoup de paquets sont concernés !)
• @zapier/ (Beaucoup de paquets sont concernés. zapier-platform-cli)
• go-template
• posthog-js
• … et malheureusement beaucoup, beaucoup plus!

La liste complète est énorme! Assurez-vous de les regarder si vous utilisez l'une des technologies mentionnées ci-dessus:

Lien vers koi.ai, alternativement Lien vers aikido.dev pour être sûr, mais les plus importants à ce jour sont mentionnés ci-dessus. Vous devriez vous-même faire correspondre vos dépendances avec la liste officielle actuelle!

Contre-mesures
TL:DR

Shai-Hulud 2.0 Liste de contrôle d'urgence pour les équipes de développement

Ces étapes sont essentielles pour arrêter une infection en cours et prévenir d'autres dommages.

I. Détection & Isolation

action	détails
Vérification de toutes les dépendances	Semblable à ceux actuellement utilisés npm paquets avec la liste complète des paquets infectés (en particulier go-template, AsyncAPI, ENS, Postman, Zapier paquets).
Isoler les paquets infectés	Tous les paquets infectés immédiatement Supprimer les dépendances du projet.
Arrêter les mises à jour automatiques	Désactive temporairement toutes les mises à jour automatiques des paquets pour éviter la réinfection.
Effectuer une analyse du système	Effectue des analyses virales sur les machines de développement, car le ver installe des portes dérobées.

II. Rotation critique des données d'accès (secrets)

Adoption: S'attend à ce que tous les secrets utilisés par une machine infectée ou dans un référentiel infecté: compromise sont.

Plate-forme/service	Qu'est-ce que la rotation?
npm	Tous Jeton npm des membres de l'équipe, en particulier les jetons de publication.
GitHub/GitLab/Bitbucket	Tous Tokens d'accès personnel (PAT) et Clé SSH l'utilisateur concerné.
Outils CI/CD	Tous les secrets utilisés dans les flux de travail ou les pipelines (GitHub Actions Secrets, Jenkins, variables CI GitLab, etc.).
Fournisseur de cloud	Tous Clés API, clés d'accès, clés secrètes (par exemple, AWS, GCP, Azure) doivent être renouvelés.
Services internes	Toutes les données d'accès à la base de données, les jetons Slack ou d'autres clés API internes stockées sur les systèmes affectés.

III. Restauration du système & Prévention

action	détails
Réinitialiser les systèmes	Idéalement, redémarrez toutes les machines de développement concernées pour vous assurer que les backdoors sont retirées.
Authentification multifactorielle (MFA)	Vérifie si l'AMF est activée et forcée sur tous les comptes critiques (npm, GitHub, Cloud).
Principe du moindre privilège	Assurez-vous que les jetons CI/CD et les jetons personnels Droits minimum nécessaires avoir.
Surveiller les sources	Faites attention aux mises à jour officielles de npm, GitHub et des chercheurs en sécurité (Wizz, Koi, Aikido).

Vous avez l'air familier? Journée des marmottes? C'est parce que nous avons tout En septembre, j'ai déjà eu. Après tout, cette hantise et une hantise similaire se terminent au plus tard après le 9. décembre, lorsque Github met en œuvre les mesures de sécurité annoncées.

---

Préparez votre équipe à commencer avec cette liste.

Restez en sécurité et vérifiez vos deps! Le week-end est peut-être terminé, mais le travail ne s'arrête jamais pour les développeurs dans la crise de sécurité quasi permanente.