Die Fork-Bomb hat uns gerettet

Die Malware in LiteLLM 1.82.8 enthielt eine .pth-Datei, die bei jedem Python-Start ausgeführt wurde. Sie sammelte SSH-Schlüssel, Cloud-Zugangsdaten, Kryptowährungs-Wallets und CI/CD-Secrets, verschlüsselte sie mit einem 4096-Bit-RSA-Schlüssel und exfiltrierte das Archiv an eine vom Angreifer kontrollierte Domain. Der Payload war sauber konstruiert. Die Verschlüsselung war solide. Die Exfiltration war unauffällig.¹ Dieser Vorfall ist Teil meiner Serie über Agent Security — die realen Sicherheitsvorfälle, die bestimmen, wie wir Vertrauen in automatisierte Systeme aufbauen.

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

Die Fork-Bomb war ein Bug. Der Angreifer hatte nicht beabsichtigt, dass die Malware sichtbar wird. Eine korrekt implementierte Version hätte bei jedem Python-Aufruf auf jedem infizierten System still im Hintergrund laufen können — potenziell wochenlang. Stattdessen bemerkten Entwickler, dass ihre Rechner zum Stillstand kamen, untersuchten die Ursache und fanden den Credential-Stealer. PyPI stellte beide Versionen 46 Minuten nach der Veröffentlichung unter Quarantäne.¹

Sechsundvierzigtausend Installationen in sechsundvierzig Minuten. Der Erkennungsmechanismus war ein Implementierungsfehler in der Malware.

TL;DR

• Der Bug: Der Credential-Stealer in LiteLLM 1.82.8 enthielt einen Fork-Bomb-Bug, der infizierte Rechner lahmlegte. Ohne den Bug hätte der Stealer wochenlang unbemerkt laufen können.
• Die Lücke: Statische Analyse, Verhaltensüberwachung und Code-Review — alle versagten. Jede Erkennungsschicht ging davon aus, dass eine andere den Angriff abfangen würde. Keine tat es.³
• Die Kurve: Die Qualität der Angreifer verbessert sich mit jeder Iteration. Die .pth-Technik ist inzwischen öffentlich dokumentiert. Der nächste Angreifer erbt sie — ohne den Bug.
• Was ohne Glück funktioniert: Domain-Alter-Prüfung bei ausgehendem Datenverkehr, Verhaltensbaselines bei Paketinstallationen, Dateisystem-Canaries und Installationsisolierung. Jede dieser Maßnahmen funktioniert unabhängig von der Payload-Qualität.
• Die Asymmetrie: Der Verteidiger bestimmt die Umgebung. Wenn in der Installationsumgebung keine Zugangsdaten vorhanden sind, erntet selbst ein perfekter Payload nichts.

Wir hatten Glück

Entfernt man die Fork-Bomb aus dem Payload, gelingt der Angriff lautlos. Die .pth-Datei wird vor jedem Import ausgeführt, vor jeglichem Anwendungscode, vor jeder Python-Sandbox. Es gibt keinen Hook-Punkt. Es gibt keinen Log-Eintrag. Der Credential-Stealer läuft, verschlüsselt, exfiltriert — und der Python-Prozess fährt normal fort. Der Entwickler bemerkt nichts. Die CI-Pipeline bemerkt nichts. Der Sicherheitsscanner bemerkt nichts, denn der Sicherheitsscanner war von Anfang an der Angriffsvektor.³

Die Erkennungsgeschichte von LiteLLM 1.82.8 lautet nicht „unser Monitoring hat es erkannt”. Sie lautet: „Der Angreifer hat einen Bug ausgeliefert.”

Das ist keine belastbare Grundlage für Supply-Chain-Sicherheit. Wie ich in Your Agent Sandbox Is a Suggestion darlege, sind die Grenzen zwischen vertrauenswürdigem und nicht vertrauenswürdigem Code weitaus durchlässiger, als die meisten Teams annehmen.

Die Qualitätskurve der Angreifer

Softwarequalität verbessert sich durch Iteration — das gilt für Angreifer ebenso wie für Verteidiger. Die Kampagne von TeamPCP traf innerhalb einer Woche fünf Ökosysteme: GitHub Actions, Docker Hub, npm, Open VSX und PyPI.⁴ Jeder Kompromiss eines Ökosystems nutzte Zugangsdaten, die aus dem vorherigen erbeutet worden waren. Die Kampagne zeigte operationelle Raffinesse: Domain-Registrierung 24 Stunden vor der Payload-Auslieferung, Tag-Hijacking auf veränderlichen Referenzen und Umgehung der Credential-Rotation durch unvollständige Schlüsseländerungen bei Aqua Security.

Die Fork-Bomb war der einzige Fehler in einer ansonsten kompetenten Operation. Die nächste Kampagne wird diesen Fehler nicht wiederholen. Die .pth-Technik ist inzwischen öffentlich dokumentiert und von CrowdStrike, Microsoft, Wiz sowie Palo Alto analysiert worden.³ 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. In What Actually Breaks Unsupervised untersuche ich, was diese Kurve für autonome Systeme bedeutet.

Erkennung darf nicht von Fehlern der Angreifer abhängen

Das aktuelle Supply-Chain-Erkennungsmodell besteht aus drei Schichten — und alle drei versagten bei LiteLLM:

Statische Analyse hat versagt. Die .pth-Datei ist ein legitimes Python-Feature. Der Payload war doppelt Base64-kodiert und wurde erst zur Laufzeit dekodiert. Statische Scanner, die nach bekannten bösartigen Mustern suchen, finden nichts, weil das Muster neu ist.

Verhaltensüberwachung hat versagt. Der Credential-Stealer führte einen einzigen ausgehenden HTTPS-POST an eine Domain durch, die wie ein legitimer Dienst aussah (models.litellm.cloud). Egress-Monitoring, das Zieldomains überprüft, müsste wissen, dass genau diese Domain erst 24 Stunden zuvor registriert wurde. Die meisten Egress-Monitore prüfen das Domain-Alter nicht.

Code-Review hat versagt. Die bösartigen Versionen wurden direkt auf PyPI veröffentlicht und umgingen die GitHub-CI/CD-Pipeline vollständig. Es gab keinen Pull Request zur Überprüfung. Es gab kein Diff zur Inspektion. Der Angreifer nutzte gestohlene Veröffentlichungs-Zugangsdaten, um vorgefertigte Pakete hochzuladen.

Jede Erkennungsschicht ging davon aus, dass ein anderer Teil der Angriffskette das Problem auffangen würde. Keine tat es. Die Fork-Bomb fand das Problem.

Was tatsächlich stille Malware erkennt

Wenn Sie sich nicht auf Fehler der Angreifer verlassen können, brauchen Sie Erkennungsmechanismen, die unabhängig von der Implementierungsqualität funktionieren.

Domain-Alter-Prüfung bei ausgehenden Anfragen. Die Exfiltrations-Domain wurde 24 Stunden vor dem Angriff registriert. Eine Firewall-Regel, die ausgehende Anfragen an Domains markiert, die weniger als 7 Tage alt sind, hätte dies erkannt. Die Regel ist einfach, die Falsch-Positiv-Rate überschaubar, und sie erkennt das häufigste Exfiltrationsmuster.

Verhaltensbaselines für Python-Prozesse. Ein pip install, das plötzlich HTTPS-POST-Anfragen an eine unbekannte Domain sendet, ist anomal. Prozessbasierte Verhaltensüberwachung, die Netzwerkaktivität während der Paketinstallation verfolgt, würde dies als verdächtig einstufen.

Dateisystem-Canaries. Platzieren Sie einen gefälschten SSH-Schlüssel an einem Canary-Pfad und gefälschte AWS-Zugangsdaten an einem weiteren. Überwachen Sie, ob irgendein Prozess diese Dateien liest. Ein Credential-Stealer, der Standardpfade durchsucht, wird die Canaries lesen. Ein legitimer Prozess hingegen nicht. Der Canary löst einen Alarm aus, noch bevor die Exfiltration abgeschlossen ist.

Installationsisolierung. 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 Produktionsumgebung. Die .pth-Datei wird während des eigenen Python-Prozesses von pip ausgelöst — der Credential-Stealer läuft also während der Installation. Wenn die Installationsumgebung keine Zugangsdaten enthält, erntet der Angriff nichts.

Keine dieser Maßnahmen erfordert, dass der Angreifer einen Fehler macht. Sie funktionieren unabhängig von der Payload-Qualität. Das architektonische Prinzip — Umgebungen so zu gestalten, dass selbst ein perfekter Angriff ins Leere läuft — ist dasselbe Prinzip, das hinter Deploy and Defend: The Agent Trust Paradox steht.

Die Asymmetrie

Die Verteidigung hat einen strukturellen Vorteil: Der Verteidiger bestimmt die Umgebung. Der Angreifer muss mit der jeweiligen Umgebung arbeiten, in die das Paket installiert wird. Wenn diese Umgebung keine Zugangsdaten enthält, keinen Netzwerkzugang bietet und Dateisystem-Canaries bereithält, gelingt der Payload technisch — scheitert aber operativ.

Der LiteLLM-Angriff funktionierte, weil die Installationsumgebung dieselbe Umgebung war, die Veröffentlichungs-Zugangsdaten, SSH-Schlüssel und Cloud-Tokens enthielt. Die Fork-Bomb war für die Sicherheitsarchitektur irrelevant. Relevant war sie nur für den Zeitablauf.

Beim nächsten Mal wird die Fork-Bomb nicht da sein. Die Zugangsdaten werden sich weiterhin in derselben Umgebung befinden wie der Paketmanager. Die Frage ist, ob Sie die Umgebung geändert haben werden, bevor der nächste Angreifer einen fehlerfreien Payload ausliefert. Meine Analyse der Ralph Agent Architecture zeigt, wie Agentensysteme so strukturiert werden können, dass kompromittierte Komponenten nicht über ihre Isolierungsgrenze hinaus eskalieren können.

FAQ

Warum hat der Angreifer die Fork-Bomb nicht durch Tests entdeckt?

Das Starten eines Kindprozesses durch die .pth-Datei ist eine nachvollziehbare Implementierungsentscheidung, um einen Payload auszuführen, ohne den Elternprozess zu blockieren. Der rekursive Trigger ist eine subtile Interaktion zwischen .pth und der site.py-Initialisierung von Python. Es handelt sich um die Art von Bug, die bei Integrationstests auffällt, nicht jedoch bei Unit-Tests — und Malware-Autoren haben nur begrenzte Möglichkeiten, in realistischen Umgebungen Integrationstests durchzuführen.

Könnte die Fork-Bomb absichtlich gewesen sein?

Unwahrscheinlich. Die Fork-Bomb machte die Malware sofort sichtbar — das genaue Gegenteil dessen, was der Angreifer bezweckte. Ein stiller Credential-Stealer, der wochenlang läuft, erbeutet um Größenordnungen mehr Zugangsdaten als einer, der nach 46 Minuten entdeckt wird.

Ist die Prüfung des Domain-Alters im großen Maßstab praktikabel?

Ja. Das Domain-Alter ist über WHOIS oder DNS-Registrierungsdatum-APIs verfügbar. Die Prüfung fügt pro Anfrage Millisekunden an Latenz hinzu. Die meisten Organisationen können bekannte neue Domains auf eine Whitelist setzen.

Sources