… und die nächste Supply Chain Attack!!

Erst Anfang der Woche haben wir es geschrieben, dass die nächste Attacke nicht lange auf sich warten lassen wird. Dabei war sie schon unterwegs!

Zunächst haben wir die Berichte über diesen Wurm für eine übertriebene Version der Darstellung der letzten Attacke gehalten. Aber es ist wohl tatsächlich eine weitaus schlimmere Version der Vorhergehenden. Was ist dieses Mal passiert?

Playbook

Bereits im vorherigen, durchaus faszinierend komponierten Angriff wurden mit Hilfe infizierter NPM-Pakete die Credentials von Entwicklern geraubt und in public Repositories exportiert. Das ist unangenehm und nervig. lässt sich aber – wenn rechtzeitig bemerkt – noch reparieren, indem alle publik gewordenen Credentials erneuert und die Zugänge / Systeme entsprechend überwacht werden; kein Kindergarten, nicht geschenkt, aber machbar.

Dieser Fall ist aber wesentlich grimmiger, da die Attacke um ein Wurm-Element ergänzt wurde. Nachdem die Credentials publiziert wurden, nutzt das System diese, um sich in andere Repos zu verteilen. Dabei schlüpft es in die package.json, indem es bundle.js als postinstall-Script hinzufügt. Diese führt dann unbeobachtet die schädlichen Aktionen aus und persistiert sich sogar in eigenen Branches mit eigene workflows. Details sind alle in diesem Artikel beschrieben.

Im Ergebnis werden Tokens und Credentials eingesammelt und publiziert. Aber nicht genug. Mit Hilfe der Workflows versucht der Wurm private Repositories in public-Versionen  zu überführen/klonen und sich entsprechen zu verbreiten, indem er sich in alle Pakete, auf die er Zugriff bekommt injiziert und die infizierten Pakete publiziert.

Indicators

Um herauszufinden, ob man bereits betroffen ist, ist die Suche nach bundle.js in den package.json Dateien erforderlich. Wir werden bis Montag (22.9.25) eine Erweiterung für unser ts-scan-Tool zur Verfügung stellen, der beim Scannen die package.json ohnehin liest und dann entsprechende Warnungen _vor_ dem Ausführen des Builds ausgeben kann, sodass de Build abgebrochen werden kann. Um dieses interaktive Element nutzen zu können, empfiehlt sich eine manuell Ausführung. Wir arbeiten derzeit noch an einer Erweiterung für das automatisierte Scannen gesamter Repo-Bäume.

Ergänzend sollten die bestehenden Repositories bzw. Repository-Listen der Organisation auf Repositories mit dem Namen Shai-Hulud – Dune Fans werden es zuordnen können – untersucht werden. Entsprechende Repositories sind klare Hinweise auf eine Infektion. Suchen Sie auch nach Branches mit dem Namen. Diese können u.a. Worfklows enthalten, die weitere, schädliche Aktionen ausführen. Ein weiterer Indikator auf Repository-Ebene sind *_migration benannte public Repositories.

Protection

Wir können es nicht oft genug wiederholen: Der Sicherheitsgewinn, sich einen Package-Proxy einzurichten ist nicht zu überbieten! Auch wenn es fast and fancy ist, sich mal eben rasch etwas zu installieren, sind die Opportunitätskosten einfach zu hoch. Wenn Ihre Entwicklung noch keine Proxy-Package-Server nutzt oder diese einfach nur neue Paketanforderungen ungeprüft durchreichen – bspw. Standard-Einstellung der AWS-Codpipeline-Prooxies – ändern Sie das schnellstmöglich! Gerne unterstützen wir Sie dabei.

Sollten Builds die public Registry nutzen, empfiehlt sich ein sofortiger Stopp aller Pipelines, um einer möglichen, weiteren Verbreitung entgegen zu treten. Dann gilt es, mögliche Infektionen zu identifizieren (s. oben, Indicators). Hierzu kann dann unser ts-scan tool genutzt werden.

Die infizierten Repos sind entsprechend zu bereinigen, idealerweise sollten kompromittierte Repos auf den Stand _vor_ der Infektion zurückgerollt werden. Um es klar auszudrücken: Sie sollten gelöscht und aus dem Backup auf den Stand vor der Infektion (13.9.25) gebracht werden.

Zudem müssen alle Entwickler die mit diesen Repos gearbeitet haben, ihre aktuellen Entwicklungsstände verwerfen und die wiederhergestellten Repos neu klonen. Auch sollten sie zuvor – haben sie auf den infizierten Repos gearbeitet – ihre Entwicklungsrechner neu aufsetzen.

Solange Build-Umgebungen einfach alles zulassen – die Problematik, dass derNode-Build-Prozess alles untergeschoben bekommen kann, ist nicht neu, s. bspw. diesen gut acht Jahre alten Stackoverflow-Artikel – wird das Bauen von Paketen einen gefährliche Sache bleiben. Ein Integritätsprüfung vor dem Bau wäre hier eine gute Idee. Andere Eco-Systeme – bspw. swift oder rust – lösen das, in dem sie den Bau nur in Sandboxes erlauben. Dies ist eine klare Aufforderung an die Node-Community, sich um die Sicherheit ihres System zu kümmern! (Hallo @OpenSSF?)

Outlook

Die Kreativität der Angreifer ist enorm. Und sie wird nicht nachlassen. Die zunehmenden politischen Spannungen verbreitern die Basis auf der sich Bad Actors wohlfühlen und das Ausdenken neuer Angriffsvektoren, bzw. Mechanismen sich rentiert. Somit ist, wie bereits im vorletzten Post aufgezeigt, mit weiteren Aktionen und Szenarien zu rechnen, die wir heute noch nicht sehen. Um dennoch nicht als Opfer zu enden, empfiehlt es sich, sich zu rüsten. In guten Zeiten zu überlegen und mögliche Lücken zu identifizieren, Folgen abzuschätzen. Threat Modelling heißt das Gebot der Stunde.

Das ist keine arkane Wissenschaft. Es ist sogar relativ einfach. Man muss es nur machen. Und wer es lernen möchte, kann unseren kostenlosen Threat Modelling Kurs dazu nutzen.

Aber wenn man es einmal gemacht hat, ist es nicht vorbei. Man sollte die Aufgaben auch nachhalten. Das geht beispielsweise mit der neuen Version von TrustSource wunderbar. In den neuen Risk Management Modul lassen sich Aufgaben terminieren und Verantwortliche direkt an die identifizierten Risiken binden. Mit entsprechenden Berichten und Übersichten wird es somit jedem CTO möglich, seine Entwicklungsorganisation fest im Griff zu haben.

Sprechen Sie uns gerne an, um den richtigen Fahrplan für Ihre Organisation zu definieren