Schadcode steckte in Red Hats eigenen npm-Paketen und verbreitete sich von selbst

Eine Zeit lang arbeiteten einige der Software-Bausteine, die unter dem Namen Red Hat ausgeliefert werden, im Stillen gegen die Menschen, die sie installierten. In mehr als 30 Paketen der öffentlichen Sammlung @redhat-cloud-services steckte ein kleines Skript, das anlief, sobald ein Entwickler eines davon installierte. Eingerichtet war es als sogenannter preinstall-Schritt, eine jener automatischen Aufgaben, die das Werkzeug npm von allein ausführt, bevor auch nur eine Zeile der eigentlichen Software lädt. Seine Aufgabe war es, Passwörter zu finden und sich dann auszubreiten.

Red Hat baut keine Apps, die die meisten Menschen mit Namen kennen, doch der Code des Unternehmens liegt unter einem großen Teil dessen, was sie täglich nutzen: den Cloud-Oberflächen, über die eine Bank anmeldet, den Systemen, auf denen Krankenhäuser und Behörden laufen, den Werkzeugen, mit denen andere Firmen ihre eigenen Produkte bauen. Wird Code mit diesem Etikett feindlich, betrifft das nicht eine App. Es betrifft alles, was darauf aufgebaut ist.

Das versteckte Skript machte Jagd auf die Schlüssel, die das moderne Rechnen aufsperren. Laut der Sicherheitsfirma StepSecurity, die als Erste auf die Pakete hinwies, griff es Zugangstoken für Amazon Web Services, Google Cloud, Microsoft Azure, Kubernetes, HashiCorp Vault, npm selbst und den Automatisierungsdienst CircleCI ab, dazu die Geheimnisse aus den Build-Abläufen von GitHub. Um an sie heranzukommen, las es den rohen Speicher des laufenden Build-Prozesses aus, ein Kniff, der an den Schutzmechanismen vorbeischlüpft, die Geheimnisse aus den Protokollen heraushalten sollen.

Was einen gewöhnlichen Datendiebstahl in etwas verwandelt, das einem Ausbruch näherkommt, ist das, was der Code als Nächstes tat. Mit gestohlenen npm-Veröffentlichungstoken versuchte er, frisch manipulierte Versionen aller anderen Pakete hochzuladen, auf die das gekaperte Konto zugreifen konnte, mithilfe einer Einstellung, die die sonst übliche Zwei-Faktor-Prüfung beiseiteschiebt. Ein Diebstahl, der sich selbst kopiert, bleibt nicht bei seinen ersten Opfern. Er wandert entlang desselben Vertrauens, auf dem das ganze System ruht.

Auf den Rechnern der Entwickler selbst ging die Schadlast noch weiter: Sie hinterlegte Anweisungen in den Aufgaben-Einstellungen von Visual Studio Code und in der Konfiguration von Claude Code, dem KI-Programmierassistenten, um lange nach Abschluss der Installation weiterzulaufen. Gerade jene, die solche Pakete am ehesten installieren, die Ingenieure, die die Software aller anderen pflegen, waren auch jene, deren Laptops zum Einfallstor wurden.

Das unangenehmste Detail ist die Herkunft der schlechten Versionen. Die Entwickler von Red Hat, die das Problem im öffentlichen Projekt-Tracker einräumten, und die Forscher, die den Code zerlegten, sind sich einig: Die vergifteten Versionen gingen über Red Hats eigene automatische Veröffentlichungskette hinaus, die Maschinerie, die Code aus den Repositorien nimmt und in die Welt schickt. Die Angreifer gaben sich nicht als Red Hat aus. Für eine gewisse Zeit konnten sie als Red Hat veröffentlichen. Das Siegel des Vertrauens und das, dem vertraut wurde, fielen auseinander.

Es ist nicht das erste Mal, dass die Lieferkette quelloffener Software zur Zustellroute wird. Manipulierte Browser-Erweiterungen und gekaperte Entwicklerkonten tauchten im Frühjahr immer wieder auf, alle nutzten dieselbe Gewohnheit aus: Moderne Software wird aus Tausenden kostenloser Bausteine zusammengefügt, die niemand von Grund auf neu schreibt. Was diesen Fall schwerer wiegen lässt, ist der Name auf der Verpackung. Der ganze Grund, Code von einem Anbieter wie Red Hat zu beziehen und nicht von einem anonymen Mitwirkenden, ist, dass dieser Name die Garantie sein soll.

Es lohnt sich, klar zu sagen, was der Vorfall nicht bedeutet. Bislang gibt es keinen Hinweis darauf, dass Geräte gewöhnlicher Nutzer infiziert wurden oder dass die kostenpflichtigen Unternehmensprodukte von Red Hat und die Produktivsysteme seiner Kunden eingebrochen wurden. Die schädlichen Versionen zielten auf die unübersichtliche Mitte der Softwareentwicklung, die automatischen Build-Server und die Maschinen der Ingenieure, und viele der betroffenen Pakete sind Oberflächen- und Entwicklerwerkzeuge, nicht der Kern eines laufenden Dienstes. Das Bild ist zudem noch in Bewegung, und die genaue Zahl der verseuchten Pakete verschob sich, während Red Hat und externe Forscher die Liste durchgehen. Der Schaden, der am meisten zählt, die gestohlenen Zugangsdaten, bleibt unsichtbar, bis jemand sie benutzt.

Red Hat hat die schädlichen Versionen nach und nach entfernt, und die kompromittierten Veröffentlichungen werden aus npm gezogen. Wer sie im betroffenen Zeitfenster installiert hat, soll jedes Token, das der Build sehen konnte, als verbrannt betrachten und erneuern. Die Offenlegung kam Anfang Juni, und die Aufräumarbeiten werden die Schlagzeilen überdauern. Das strukturelle Problem wird die Aufräumarbeiten überdauern: Das Internet wird in hohem Tempo aus Millionen kleiner Teile zusammengesetzt, gepflegt von Menschen, die wir nie kennenlernen, und zunehmend von automatischen Systemen, die gekapert werden können, um diese Teile an ihrer Stelle zu signieren.

Schlagwörter: Cybersicherheit, npm, Lieferkettenangriff, malware