Was zwischen 09:35 und 11:44 UTC ausgeliefert wurde

Die erste vergiftete Veröffentlichung war keyv in der Version 6.0.0, publiziert am 4. August um 09:35 UTC. Semgrep, das der Kampagne den Namen ChainDrop gab, zählte im darauf folgenden Schub zwischen 09:40 und 11:44 UTC 1.557 bösartige Versionen über 435 Pakete. Wiz verfolgte denselben Vorfall, kam auf mehr als 400 verschiedene Pakete und führte ihn auf ein Betreuerkonto zurück, dessen Zugangsdaten entwendet worden waren. Es handelte sich nicht um Tippfehler-Imitate und nicht um neue Pakete. Es waren die echten Bibliotheken, neu veröffentlicht unter dem Namen des echten Betreuers, mit einer zusätzlichen Datei versehen.

Innerhalb einer halben Stunde überschritt die Ausbreitung die Grenzen einzelner Organisationen. Betroffen waren unter anderem die Namensräume @deliveroo, @ornikar, @qlik, @servicetitan, @onereach, @or-sdk, @arv-bedrock und @adminide-stack sowie die Familien keyv und cacheable selbst. Diese Organisationen teilen weder Quellcode noch Eigentümer. Geteilt wurde ein gestohlenes Veröffentlichungstoken: jede Infektion sammelte npm-Zugangsdaten von dem Rechner ein, der das Paket installierte, und veröffentlichte damit alles neu, was dieses Token erreichen konnte. Genau das macht die Sache zu einem Wurm und nicht zu einer einzelnen vergifteten Veröffentlichung.

Die Träger sind Pakete, die niemand ausgewählt hat

Wir haben die Download-Zahlen aus dem npm-Register für die 30 Tage bis zum 3. August abgerufen, also bis zum Tag vor der Kompromittierung. keyv kam auf 619,7 Millionen Downloads. flat-cache auf 579,8 Millionen. file-entry-cache auf 571,2 Millionen. cacheable-request auf 137,0 Millionen, cacheable auf 30,1 Millionen und cache-manager auf 16,3 Millionen. Diese sechs Bibliotheken zusammen ergeben rund 1,95 Milliarden Downloads in dem Monat, bevor sie vergiftet wurden.

Fast niemand installiert flat-cache oder file-entry-cache absichtlich. Es sind Zwischenspeicher-Helfer, die unter Linting- und Build-Werkzeugen mitkommen, mehrere Ebenen tief in einem Abhängigkeitsbaum, in Projekten, deren Verantwortliche keinen der beiden Namen je eingegeben haben. Das ist der unangenehme Teil der Rechnung. Die Pakete mit der größten Sprengweite sind genau jene, die auf der von Ihnen geprüften und genehmigten Abhängigkeitsliste fehlen, weshalb eine Prüfung Ihrer eigenen Entscheidungen über diesen Vorfall sehr wenig aussagt. Die Zahl, die Ihr Risiko vorhersagt, ist die Anzahl der Build-Läufe am 4. August.

Die Schadsoftware suchte den KI-Assistenten

Der Mechanismus war ein preinstall-Hook, und das ist entscheidend, weil er während der Auflösung der Abhängigkeiten läuft und nicht darauf wartet, dass Ihr Code irgendetwas importiert. Die Ladedateien setup.mjs und math_init.js holten eine eigenständige Bun-Laufzeitumgebung und führten eine verschleierte zweite Stufe aus. Wiz erkannte den Verkehr am User-Agent Bun/1.3.13. Der Sammler zielte auf npm-Token, Cloud-Zugangsdaten, SSH-Schlüssel, CI-Geheimnisse, Kryptowährungs-Wallets und Konfigurationsdateien von KI-Werkzeugen.

Er verankerte sich außerdem in den Verzeichnissen .claude und .vscode, was eine bewusste Entscheidung darüber ist, wo Entwickler heute ihr Vertrauen ablegen. Ein Editor und ein KI-Assistent verfügen über Zugriff auf das Repository, über Shell-Rechte und zunehmend über die Befugnis, Befehle auszuführen. Die Steuerung war in einem Ethereum-Smart-Contract versteckt, der mit einem eth_call gelesen wurde und die Domain npm-cache[.]com zurückgab, sodass die Betreiber ihre Infrastruktur ohne neue Schadsoftware umleiten können. Die Daten flossen in GitHub-Repositories ab, die unter den übernommenen Identitäten angelegt und mit Shai-Hulud: Here We Go Again betitelt wurden, dem Namen der Schadsoftware-Familie, von der dieser Code abstammt.

Zwei Stunden genügen für einen NIS2-Befund

Für einen Betrieb in der EU oder im Vereinigten Königreich lautet die Compliance-Frage nicht nur, ob Sie betroffen waren, sondern ob Sie beschreiben können, was geschehen ist. Zwei der betroffenen Namensräume gehören Deliveroo und Ornikar, einer britischen Lieferplattform und einem französischen Fahrschulunternehmen. Keines der beiden ist ein unbekannter Laden, und keines hat sich für diesen Vorfall entschieden. NIS2 legt die Sicherheit der Lieferkette in die Hände der Geschäftsführung und nicht des Sicherheitsteams, und DORA verlangt von Finanzunternehmen dieselben Nachweise über IKT-Risiken bei Dritten.

Die Dokumentation zählt also genauso viel wie die Bereinigung. Klären Sie, ob am 4. August zwischen 09:35 und etwa 15:00 UTC ein Build gelaufen ist, dem Zeitpunkt, an dem der Ethereum-Steuerkanal dokumentiert wurde und die Analyse noch andauerte. Wechseln Sie jede Berechtigung, die ein Runner erreichen konnte, nicht nur das npm-Token: Cloud-Schlüssel, GitHub-Token, SSH-Schlüssel, Kubernetes- und Terraform-Zugänge. Bauen Sie die Runner neu auf, statt sie zu reinigen. Schreiben Sie dann auf, was Sie wann gewechselt haben, denn genau dieses Dokument verlangen Aufsicht, Prüfer oder Versicherer. In Deutschland ist das BSI die Stelle, bei der ein meldepflichtiger Vorfall landet.

Weiterlesen: 16.000 Firmen bündeln ihr Lieferantenrisiko. Sie nicht  |  Die Korrektur signiert neue Dateien, nicht Ihr Archiv