FAMArtPhotography – shutterstock.com
Heutige Anwendungen basieren auf zahlreichen Komponenten, von denen jede zusammen mit den Entwicklungsumgebungen selbst eine Angriffsfläche darstellt. Unabhängig davon, ob Unternehmen Code intern entwickeln oder sich auf Drittanbieter verlassen, sollten CISOs, Sicherheitsexperten und Entwickler der Software-Supply-Chain besondere Aufmerksamkeit schenken.
Zu den Risiken zählen zum Beispiel React2Shell, Shai-Hulud oder XZ Utils, alles Schwachstellen in der Software-Lieferkette, die im Kleinen angefangen haben und später massive Auswirkungen hatten. Shai-Hulud sticht dabei besonders heraus, es signalisiert das Ende der „passiven Ära” der Angriffe auf Lieferketten und den Beginn der „aktiven Wurm”-Ära. Diese Veränderung verspricht verheerende Folgen für Software-Pipelines.
Traditionell waren Angriffe auf die Lieferkette passive Fallen. Ein Angreifer lud ein falsch geschriebenes Paket (Typosquatting) wie „reqeusts“ anstelle von „requests“ hoch, lehnte sich zurück und wartete darauf, dass ein müder Entwickler einen Fehler machte. Der Explosionsradius war linear und eher langsam.
Mit Shai-Hulud wurden die Spielregeln verändert, indem es eine wurmähnliche Verbreitung einführte. Sobald es auf dem Rechner eines Entwicklers landet, sammelt es aktiv Anmeldedaten (NPM-Token, GitHub-Geheimnisse). Es nutzt diese gestohlenen Anmeldedaten, um infizierte Versionen anderer legitimer Pakete, die das Opfer verwaltet, automatisch zu veröffentlichen. Im Gegensatz zu Spyware, die verborgen bleiben will, enthalten Varianten von Shai-Hulud einen „Dead Man Switch“. Wenn er feststellt, dass er blockiert oder analysiert wird, versucht er, das System des Opfers zu löschen und dabei alle Spuren von sich selbst vollständig zu entfernen.
Das Ziel ist nicht mehr nur die Anwendung, sondern die Identität des Entwicklers und die automatisierten CI/CD-Pipelines, die ihm implizit vertrauen. Was wäre nun, wenn die nächste Variante des Shai-Hulud andere Code-Sprachen betrifft?
Code-Sprachen als tickende Zeitbomben
Ein Beispiel dafür wäre Python, sie ist die Sprache der KI und der Data Science. Die nächste Evolutionsstufe des Supply-Chain-Wurms wird wahrscheinlich nicht nur AWS-Schlüssel stehlen, sondern auch den Aufstieg von KI-Codierungsassistenten nutzen.
Sicherheitsforscher beobachten bereits „Halluzinations-Hijacking“, bei dem Angreifer Pakete registrieren, deren Existenz KI-Tools fälschlicherweise vorhersagen. Ein Wurm im Stil von Shai-Hulud könnte den Laptop eines Data Scientists infizieren, dessen lokalen LLM-Chatverlauf nach privaten Paketnamen durchsuchen und automatisch bösartige Versionen öffentlich registrieren. Ein Wurm in diesem Ökosystem würde nicht nur eine Website zum Absturz bringen, sondern könnte auch Finanzmodelle subtil vergiften, medizinische Forschungsdaten verändern oder Backdoors in KI-Trainingssets von Unternehmen einbauen – Schäden, die möglicherweise jahrelang unentdeckt bleiben.
Weitere Beispiele könnten die Code-Sprachen Java/JVM oder Rust/Go betreffen, auch hier wären die Auswirkungen katastrophal.
Die Polyglot Supply-Chain-Attacke
Die erschreckendste Aussicht ist jedoch das Zusammentreffen dieser Bedrohungen in einer Polyglot-Supply-Chain-Attacke. Derzeit arbeiten Sicherheitsteams isoliert voneinander. AppSec überwacht den Code, CloudSec überwacht AWS, NetworkSec überwacht den Perimeter. Ein Polyglot-Angriff ist darauf ausgelegt, diese Silos nahtlos zu durchbrechen.
Dies geschieht folgendermaßen: Ein Wurm dringt über eine Low-Level-JavaScript-Abhängigkeit in den Laptop eines Frontend-Entwicklers ein. Er erkennt, dass der Entwickler auch Zugriff auf das Backend-Rust-Repository des Unternehmens hat, stiehlt diese Anmeldedaten und injiziert bösartige Build-Skripte in die Rust-CI-Pipeline. Die Rust-Pipeline stellt eine kompromittierte Binärdatei in einem Kubernetes-Cluster bereit.
Der Angriff könnte in NPM beginnen, jedoch als kompilierte Binär-Backdoor in der produktiven Cloud-Infrastruktur enden. Das JavaScript-Sicherheitsteam wird ihn nicht entdecken, da er ihren Bereich sofort verlassen hat. Dem Cloud-Sicherheitsteam würde die Bedrohung ebenfalls nicht auffallen, da sie von einer vertrauenswürdigen CI-Pipeline unter Verwendung gültiger Anmeldedaten bereitgestellt wurde. Darauf müssen sich CISOs einstellen und entsprechende Vorkehrungen treffen.
Lesetipp: Wie Sie Ihre Software-Supply-Chain schützen
Handlungsempfehlungen für CISOs
Handlungsempfehlungen für CISOs birgt der EU Cyber Resilience Act (CRA). Er schreibt die Absicherung digitaler Produkte für Hersteller, Importeure und Händler vor, damit diese in sicheres Design bereits bei der Entwicklung, aber auch bei der Wartung investieren. Die dort formulierten Anforderungen müssen schrittweise bis Ende 2027 umgesetzt werden und umfassen auch die Sicherheit vernetzter Hardware und Software durch die Behandlung von Schwachstellen und deren Veröffentlichung, beziehungsweise Meldung an die zuständigen Behörden. Darüber hinaus müssen die drei genannten Akteure in SBOMs auch die Bestandteile der Software dokumentieren.
Die nun in Kraft getretene NIS2-Richtlinie enthält ähnliche Anforderungen für KRITIS-Betreiber, die im NIS2-Umsetzungsgesetz (NIS2UmsuCG) und im KRITIS-Dachgesetz in Bezug auf Produkte und Lieferanten festgehalten werden. Einen lesenswerten Überblick gibt OpenKRITIS.
Um sich vor Shai-Hulud und Co. zu schützen, sollten CISOs mit ihren Teams gemeinsam folgende Schritte umsetzen:
Sie müssen das „implizite Vertrauen“ in Identitäten beenden. Bei den eingangs beschriebenen Szenarien um Shai-Hulud bestand das Problem darin, dass CI/CD-Systemen zu oft blind vertraut wird. Deshalb sollten CISOs dafür sorgen, dass ihre Teams einen kritischen Blick auf ihre Pipeline-Security werfen. CI/CD-Systeme dürfen nicht automatisch davon ausgehen, dass eine Aktivität legitim ist, nur weil sie mit einem gültigen Entwickler-Token signiert wurde. Sie müssen stattdessen den Identitätsschutz priorisieren. Es wurde bereits beobachtet, dass Angreifer gezielt Anmeldedaten wie NPM-Token und GitHub-Geheimnisse stehlen, um infizierte Pakete automatisch zu veröffentlichen. Maßnahmen zum Schutz dieser Identitäten muss daher oberste Priorität eingeräumt werden.
Sicherheits-Silos sollten aufgelöst werden. Viele Security-Aspekte laufen immer noch nicht in einem übergeordneten Management zusammen. Tools sowie Abteilungen der Application Security, Infrastructure Security, Cloud Security, Network Security und viele andere sorgen für zahlreiche Inseln im Meer der Security-Strategie. Sie alle müssen noch enger zusammenarbeiten und vom CISO koordiniert werden. Ein zentrales Risiko stellt die bereits beschriebene Polyglot-Supply Chain-Attacke dar, die diese Silos nahtlos durchbricht. Für CISOs gilt daher, ein abteilungs- und bereichsübergreifendes Monitoring einzuführen. Um die Gefahr nochmals zu verdeutlichen: Ein Angriff könnte bei einem JavaScript beginnen, sich über Build-Skripte fortsetzen und als Backdoor in der Cloud enden. Oftmals herrscht keine integrierte Sichtbarkeit, um all das nachzuvollziehen. Das JavaScript-Team sieht den Angriff nicht mehr, sobald er seinen Bereich verlässt, während das Cloud-Team der CI-Pipeline vertraut. CISOs müssen deshalb Systeme etablieren, die den gesamten Pfad über das Software Development zum Build bis zur Runtime hinweg überwachen. Abhilfe schaffen SBOMs, in denen die gesamte verwendete Software dokumentiert wird.
Auf aktive Würmer vorbereiten und den Schutz von KI-Tools gewährleisten. Für die Absicherung von KI-gestützten Risiken, gilt es, das Highjacking von KI-Tools und deren Manipulation zu verhindern. Zahlreiche Softwareentwickler arbeiten mit diesen Werkzeugen, um ihre Software zu schreiben. Sicherheitsforscher beobachten bereits, dass Angreifer Pakete einsetzen, die KI-Tools halluzinieren lassen. Aktive Würmer sind die nächste Stufe von Bedrohungen. Die Security-Strategie sollte deshalb über den Schutz vor Tippfehlern hinausgehen. Gefährdungen wie Shai-Hulud verbreiten sich wurmähnlich und exponentiell. Manuelle Prozesse zur Überprüfung von Paketen reichen bei dieser Geschwindigkeit nicht mehr aus. Diese Art von Supply-Chain-Würmern verfügt darüber hinaus über einen „Dead Man Switch“, der das System des Opfers löscht, wenn eine Analyse detektiert wird. CISOs sollten sicherstellen, dass Protokolle also auch außerhalb des Entwicklerrechners abgesichert werden, um bei einer forensischen Untersuchung die Spuren des Angriffs zu bewahren. (jm)
No Responses