Die Fork-Bombe hat uns gerettet

Die Schadsoftware in LiteLLM 1.82.8 enthielt eine .pth-Datei, die bei jedem Start von Python ausgeführt wurde. Sie sammelte SSH-Schlüssel, Cloud-Zugangsdaten, Kryptowallets und CI/CD-Secrets ein, verschlüsselte sie mit einem 4096-Bit-RSA-Schlüssel und schleuste das Archiv an eine vom Angreifer kontrollierte Domain aus. Die Payload war sauber konstruiert. Die Verschlüsselung war solide. Die Exfiltration lief reibungslos.¹ Dieser Vorfall gehört zu meiner Reihe über Agentensicherheit, in der es um reale Fehlschläge geht, die prägen, wie wir Vertrauen in automatisierte Systeme aufbauen.⁵

Die .pth-Datei startete für ihre Arbeit außerdem einen Python-Kindprozess. Dieser Kindprozess löste die .pth-Datei erneut aus. Was wiederum einen weiteren Kindprozess startete. Der sie erneut auslöste. Eine exponentielle Fork-Bombe, die binnen Sekunden 100 % CPU und über 5 GB RAM verschlang.²

Die Fork-Bombe war ein Bug. Der Angreifer wollte nicht, dass die Schadsoftware sichtbar wird. Eine korrekt umgesetzte Fassung wäre auf jedem infizierten System bei jedem Aufruf von Python still gelaufen, womöglich über Wochen. Stattdessen bemerkten Entwickler, wie ihre Rechner in die Knie gingen, forschten nach und stießen auf den Zugangsdatendieb. PyPI stellte beide Versionen 46 Minuten nach der Veröffentlichung unter Quarantäne.¹

46.000 Installationen in 46 Minuten. Der Erkennungsmechanismus war ein Umsetzungsfehler in der Schadsoftware selbst.

Wenn die Abhängigkeit eines KI-Agenten ein Paket mit einer Fork-Bombe installiert, verschlingt das exponentielle Erzeugen von Prozessen binnen Sekunden 100 % CPU und mehrere Gigabyte RAM — die Maschine wird unbenutzbar. Beim Vorfall um LiteLLM 1.82.8 war genau diese versehentliche Fork-Bombe der einzige Grund, warum eine Payload zum Abgreifen von Zugangsdaten überhaupt auffiel: Entwickler bemerkten, wie ihre Rechner einbrachen, und gingen der Sache nach. Ohne den Fehler hätte die Schadsoftware wochenlang unbemerkt SSH-Schlüssel, Cloud-Zugangsdaten und Kryptowallets ausgeleitet, bevor jemand sie gefunden hätte.

TL;DR

• Der Fehler: Der Zugangsdatendieb in LiteLLM 1.82.8 enthielt eine Fork-Bombe, die infizierte Rechner lahmlegte. Ohne sie wäre er wochenlang still gelaufen.
• Die Lücke: Statische Analyse, Verhaltensüberwachung und Code-Review haben den Angriff allesamt übersehen. Jede Erkennungsschicht verließ sich darauf, dass eine andere zugreift. Keine tat es.³
• Die Kurve: Angreifer werden mit jeder Iteration besser. Die .pth-Technik ist inzwischen öffentlich dokumentiert. Der nächste Angreifer übernimmt sie ohne den Fehler.
• Was ohne Glück funktioniert: Prüfung des Domain-Alters beim ausgehenden Verkehr, Verhaltensbaselines für Paketinstallationen, Köderdateien im Dateisystem, isolierte Installation. Jede dieser Maßnahmen wirkt unabhängig von der Qualität der Payload.
• Die Asymmetrie: Die Verteidigung bestimmt die Umgebung. Gibt es in der Installationsumgebung keine Zugangsdaten, erbeutet auch eine perfekte Payload nichts.

Wir hatten Glück

Nimmt man die Fork-Bombe aus der Payload heraus, gelingt der Angriff lautlos. Die .pth-Datei läuft vor jedem Import, vor jedem Anwendungscode, vor jeder Sandbox auf Python-Ebene. Es gibt keinen Ansatzpunkt für einen Hook. Es gibt keinen Logeintrag. Der Zugangsdatendieb läuft, verschlüsselt, exfiltriert – und der Python-Prozess macht ganz normal weiter. Die Entwickler sehen nichts. Die CI-Pipeline sieht nichts. Der Sicherheitsscanner sieht nichts, denn der Sicherheitsscanner war von vornherein der Angriffsvektor.³

Die Erkennungsgeschichte zu LiteLLM 1.82.8 lautet nicht „unsere Überwachung hat es bemerkt”. Sie lautet „der Angreifer hat einen Bug ausgeliefert”.

Das ist kein bequemes Fundament für die Sicherheit der Lieferkette. Wie ich in Ihre Agenten-Sandbox ist nur ein Vorschlag darlege, sind die Grenzen, die wir zwischen vertrauenswürdigem und nicht vertrauenswürdigem Code vermuten, weit durchlässiger, als die meisten Teams annehmen.

Die Qualitätskurve der Angreifer

Softwarequalität wächst mit jeder Iteration. Das gilt für Angreifer ebenso wie für Verteidiger. Die Kampagne von TeamPCP traf binnen einer Woche fünf Ökosysteme: GitHub Actions, Docker Hub, npm, Open VSX und PyPI.⁴ Jede Kompromittierung nutzte Zugangsdaten, die im vorherigen Ökosystem erbeutet worden waren. Die Kampagne zeigte operative Reife: Domainregistrierung 24 Stunden vor Auslieferung der Payload, Tag-Hijacking auf veränderlichen Referenzen und das Unterlaufen der Zugangsdaten-Rotation durch unvollständige Schlüsselwechsel bei Aqua Security.

Die Fork-Bombe war der einzige Fehler in einer ansonsten kompetenten Operation. Die nächste Kampagne wird ihn nicht wiederholen. Die Technik mit der .pth-Datei ist inzwischen öffentlich dokumentiert und wurde von CrowdStrike, Microsoft, Wiz und Palo Alto analysiert.³ Der nächste Angreifer erbt die Technik – ohne den Bug.

Die Fähigkeiten der Angreifer folgen derselben Verbesserungskurve wie die der Verteidiger. Die Technik ist öffentlich. Die Analyse ist öffentlich. Der nächste Angreifer beginnt dort, wo TeamPCP aufgehört hat. Was diese Kurve für autonome Systeme bedeutet, untersuche ich in was ohne Aufsicht wirklich kaputtgeht.

Erkennung darf nicht von Fehlern der Angreifer abhängen

Das derzeitige Erkennungsmodell für die Lieferkette hat drei Schichten – und bei LiteLLM versagten alle drei:

Die statische Analyse hat nichts gefunden. Die .pth-Datei ist ein legitimes Feature von Python. Die Payload war doppelt base64-codiert und wurde erst zur Laufzeit decodiert. Statische Scanner, die nach bekannten Schadmustern suchen, finden nichts, weil das Muster neu ist.

Die Verhaltensüberwachung hat nichts gefunden. Der Zugangsdatendieb setzte einen einzigen ausgehenden HTTPS-POST an eine Domain ab, die nach einem legitimen Dienst aussah (models.litellm.cloud). Eine Überwachung des ausgehenden Verkehrs, die Zieldomains prüft, hätte wissen müssen, dass genau diese Domain 24 Stunden zuvor registriert worden war. Die wenigsten prüfen das Alter einer Domain.

Das Code-Review hat nichts gefunden. Die bösartigen Versionen wurden direkt auf PyPI veröffentlicht und umgingen die CI/CD-Pipeline auf GitHub vollständig. Es gab keinen Pull Request zu prüfen, kein Diff zu inspizieren. Der Angreifer lud mit gestohlenen Veröffentlichungs-Zugangsdaten fertig gebaute Pakete hoch.

Jede Erkennungsschicht ging davon aus, ein anderer Teil der Angriffskette werde das Problem abfangen. Keine tat es. Abgefangen hat es die Fork-Bombe.

Was stille Schadsoftware wirklich aufspürt

Wer sich nicht auf Fehler der Angreifer verlassen kann, braucht Erkennungsmechanismen, die unabhängig von der Umsetzungsqualität greifen.

Das Domain-Alter bei ausgehenden Anfragen prüfen. Die Exfiltrationsdomain war 24 Stunden vor dem Angriff registriert worden. Eine Firewall-Regel, die ausgehende Anfragen an Domains markiert, die jünger als sieben Tage sind, hätte das erkannt. Die Regel ist simpel, die Fehlalarmquote beherrschbar, und sie erwischt das häufigste Exfiltrationsmuster.

Verhaltensbaselines für Python-Prozesse. Ein pip install, das plötzlich HTTPS-POSTs an eine unbekannte Domain schickt, ist eine Anomalie. Eine Verhaltensüberwachung auf Prozessebene, die den Netzwerkverkehr während der Paketinstallation verfolgt, würde darauf anschlagen.

Köderdateien im Dateisystem. Legen Sie einen gefälschten SSH-Schlüssel an einem Köderpfad ab und eine gefälschte AWS-Zugangsdatei an einem zweiten. Überwachen Sie, ob irgendein Prozess diese Dateien liest. Ein Zugangsdatendieb, der die üblichen Pfade abgrast, liest die Köder mit. Ein legitimer Prozess tut das nicht. Der Köder schlägt Alarm, bevor die Exfiltration abgeschlossen ist.

Die Installation isolieren. Führen Sie pip install in einer Umgebung aus, die keinen Zugriff auf echte Zugangsdaten hat. Kopieren Sie die installierten Pakete anschließend in die Produktivumgebung. Die .pth-Datei feuert im Python-Prozess von pip selbst, der Zugangsdatendieb läuft also bereits während der Installation. Gibt es in der Installationsumgebung nichts zu stehlen, geht der Angriff leer aus.

Keiner dieser Mechanismen setzt voraus, dass der Angreifer einen Fehler macht. Sie wirken unabhängig von der Qualität der Payload. Hinter dem architektonischen Muster – Umgebungen so zu bauen, dass selbst ein perfekter Angriff nichts erbeutet – steckt dasselbe Prinzip wie in Ausrollen und verteidigen: das Vertrauensparadox bei Agenten.

Die Asymmetrie

Die Verteidigung hat einen strukturellen Vorteil: Sie bestimmt die Umgebung. Der Angreifer muss mit der Umgebung arbeiten, in die das Paket installiert wird. Enthält diese Umgebung keine Zugangsdaten, keinen Netzwerkzugang und dafür Köderdateien, gelingt die Payload technisch, scheitert aber operativ.

Der Angriff auf LiteLLM funktionierte, weil die Installationsumgebung dieselbe Umgebung war, in der Veröffentlichungs-Zugangsdaten, SSH-Schlüssel und Cloud-Tokens lagen. Für die Sicherheitsarchitektur war die Fork-Bombe belanglos. Entscheidend war sie für den Zeitverlauf.

Beim nächsten Mal wird die Fork-Bombe fehlen. Die Zugangsdaten werden weiterhin in derselben Umgebung liegen wie der Paketmanager. Die Frage ist, ob Sie die Umgebung geändert haben, bevor der nächste Angreifer eine saubere Payload ausliefert. Meine Analyse zur Ralph-Agentenarchitektur zeigt, wie sich Agentensysteme so strukturieren lassen, dass kompromittierte Komponenten ihre Isolationsgrenze nicht überschreiten können.

FAQ

Warum ist dem Angreifer die Fork-Bombe beim Testen nicht aufgefallen?

Dass eine .pth-Datei einen Kindprozess startet, ist eine plausible Umsetzung, wenn eine Payload laufen soll, ohne den Elternprozess zu blockieren. Die rekursive Auslösung entsteht aus einem subtilen Zusammenspiel zwischen .pth und der Initialisierung von site.py in Python. So ein Fehler zeigt sich im Integrationstest, nicht im Unit-Test – und Schadsoftware-Autoren haben nur begrenzt Gelegenheit, in realistischen Umgebungen integrativ zu testen.

Könnte die Fork-Bombe Absicht gewesen sein?

Unwahrscheinlich. Sie machte die Schadsoftware sofort sichtbar, also genau das Gegenteil dessen, was der Angreifer wollte. Ein stiller Zugangsdatendieb, der wochenlang läuft, erbeutet um Größenordnungen mehr als einer, der nach 46 Minuten auffliegt.

Lässt sich die Prüfung des Domain-Alters im großen Maßstab umsetzen?

Ja. Das Domain-Alter lässt sich über WHOIS oder über APIs für das DNS-Registrierungsdatum abfragen. Die Prüfung kostet Millisekunden pro Anfrage. Die meisten Organisationen können bekannte neue Domains auf eine Positivliste setzen.

Quellen