Ein 40-Minuten-Fenster, 195 Terabyte Beute
Ein Supply-Chain-Angriff auf das Open-Source-Werkzeug LiteLLM hat Zugangsdaten in einem Umfang offengelegt, der selbst für Vorfälle dieser Art außergewöhnlich ist. LiteLLM ist ein Proxy, der Anfragen an unterschiedliche KI-Anbieter über eine einheitliche Schnittstelle bündelt und deshalb naturgemäß viele API-Schlüssel sieht. Genau das machte das Paket zum ideal platzierten Einfallstor.
Betroffen sind die Versionen 1.82.7 und 1.82.8, die im März über das offizielle Python Package Index (PyPI) verteilt wurden. Das Zeitfenster, in dem die manipulierten Pakete dort verfügbar waren, betrug rund 40 Minuten. Der eingeschleuste Code las den Arbeitsspeicher der infizierten Maschinen aus und leitete die Inhalte über einen von den Angreifern kontrollierten Kanal ab.
Sicherheitsfirmen, die den Vorfall analysiert haben, sprechen von rund 434.000 betroffenen CI/CD-Pipelines, also automatisierten Bau- und Auslieferungsketten für Software. Zugeordnet werden konnten diese mehr als 2.500 Organisationen. Eine der ausgewerteten Dateien hatte einen Umfang von 195 TB. Woher diese Datei stammt, ist nicht offengelegt.
Was in den Daten steckt
Die abgeflossenen Inhalte sind praktisch ein Vollzugriff auf die Innereien moderner Entwicklungsumgebungen. Genannt werden unter anderem:
- Cloud-Zugangsschlüssel
- Repository-Tokens für GitHub und GitLab
- SSH-Schlüssel
- Kubernetes-Secrets und Service-Account-Tokens
- Zugangsdaten zum Veröffentlichen von Paketen
- Umgebungsvariablen samt aktiver Datenbank-Passwörter
- API-Schlüssel von KI-Anbietern
Ein Teil dieser Daten lässt sich nicht ohne Weiteres einem Unternehmen zuordnen. Viele Pipelines sind generisch konfiguriert, die Variablen enthalten also weder Firmen-Mailadressen noch eigene Domains oder interne Servernamen.
Das bedeutet, dass zahllose Organisationen aktive Secrets in dieser Datenbank liegen haben, ohne von ihrer Offenlegung zu wissen. (sinngemäße Übersetzung der Analyse von Hudson Rock)
Die Kette begann bei einem Sicherheits-Scanner
Der Angriff auf LiteLLM war nicht der Ausgangspunkt, sondern eine Folgestufe. Zuvor war der weit verbreitete Schwachstellen-Scanner Trivy kompromittiert worden, außerdem das Werkzeug KICS und das Telnyx Python SDK. Ausgerechnet ein Sicherheitswerkzeug diente also als Sprungbrett in die Build-Systeme anderer Projekte.
Verschärft wurde das durch einen Verfahrensfehler: Ein Automatisierungs-Token wurde bei Trivy zwar rotiert, aber 20 Tage lang nicht vollständig widerrufen. Damit hatten die Angreifer knapp drei Wochen Zeit, um per Force-Push manipulierten Code in Builds Dritter zu schieben. Rotation ohne Widerruf ist keine Rotation, das ist die vielleicht wichtigste operative Lehre aus dem Vorfall.
Zu dem Angriff bekannt hat sich die Gruppe TeamPCP, die überwiegend aus Jugendlichen bestehen soll. Forscher haben diese Zuschreibung weitgehend bestätigt.
Auch DACH-Konzerne in den Fundstücken
Die Liste der Organisationen, bei denen die Analysten mit hoher Zuversicht von offengelegten Zugangsdaten ausgehen, liest sich wie ein Querschnitt der Weltwirtschaft. Genannt werden unter anderem Microsoft-Umgebungen, AWS, Nvidia, Cisco, Samsung, Salesforce, ServiceNow, Deloitte und FedEx.
Für den deutschsprachigen Raum sind mehrere prominente Namen dabei:
| Organisation | Land |
|---|---|
| Siemens AG | Deutschland |
| Siemens Energy | Deutschland |
| Volkswagen AG | Deutschland |
| Deutsche Bahn AG | Deutschland |
| Carl Zeiss AG | Deutschland |
| Liebherr | Deutschland / Schweiz |
| Munich Re | Deutschland |
| F. Hoffmann-La Roche AG | Schweiz |
Ein Treffer in der Liste bedeutet nicht automatisch einen Einbruch im Kernnetz des jeweiligen Konzerns. In einem dokumentierten Fall führte eine Mailadresse eines US-Medienunternehmens nicht zu diesem selbst, sondern zur Infrastruktur einer Tochtergesellschaft. Genau das macht die Aufarbeitung mühsam: Ohne sauberes Audit lässt sich oft nicht sagen, welches System hinter einem geleakten Schlüssel steckt.
Rotieren allein reicht nicht
Der unabhängige Sicherheitsforscher Kevin Beaumont hat die Echtheit der Daten anhand mehrerer betroffener Organisationen bestätigt. Seine Einordnung fällt deutlich aus.
Es ist ein massiver Supply-Chain-Einbruch wegen schlechter KI-Sicherheit. Nicht weil KI die Bedrohung wäre, sondern weil Teenager Kreise um Organisationen ziehen können, die vom überstürzten KI-Rollout besessen sind und schlechte DevOps-Sicherheit haben. (sinngemäße Übersetzung)
Besonders unangenehm ist ein Nachtrag: Ein betroffener Großkonzern erklärte, alle Zugangsdaten seien rotiert und der Vorfall damit erledigt. Ein Test der geleakten Daten im Rahmen der eigenen Offenlegungsrichtlinie des Unternehmens ergab, dass nahezu alle Zugangsdaten noch funktionierten. Die Schlüssel stammen aus dem März.
Ob die abgeflossenen Cloud-Keys und Tokens darüber hinaus schon für weitere Angriffe genutzt wurden, ist bislang nicht belegt. Angesichts der Menge an noch aktiven Secrets ist das Zeitfenster für Nachahmer allerdings weit offen.
Sofortmaßnahmen für Betreiber eigener KI-Pipelines
Die Analysten empfehlen allen Organisationen, die KI-Proxy-Infrastruktur, externe Schwachstellen-Scanner in der CI/CD-Kette oder abgeleitete KI-Pakete einsetzen, ihre Umgebung sofort auf die Versionen 1.82.7 und 1.82.8 von LiteLLM zu prüfen. Wer sie gefahren hat, sollte grundsätzlich davon ausgehen, dass jedes für die LiteLLM-Umgebung erreichbare Secret kompromittiert ist.
Konkret heißt das: aggressiver Widerruf statt bloßer Rotation, Invalidierung aller Cloud-Schlüssel, Kubernetes-Service-Account-Tokens sowie persönlicher Access-Tokens für GitHub und GitLab, dazu eine Prüfung von Logging und ausgehendem Datenverkehr.
Was das für die Make-or-Buy-Frage bedeutet
Der Vorfall ist kein Argument gegen Open Source und kein Argument für teure Software-Abos. Er ist ein Argument gegen unkontrollierte Abhängigkeiten. Wer KI-Proxies, Token-Gateways und Modell-Routing selbst betreibt, senkt Kosten und Anbieterabhängigkeit, übernimmt dafür aber die volle Verantwortung für die Lieferkette seiner Pakete.
Das Muster ist nicht neu. Erst kürzlich wurde eine kritische Lücke in der KI-Plattform Langflow aktiv ausgenutzt, und automatisierte Agenten haben bereits Open-Source-Projekte auf GitHub angegriffen. Die Angriffsfläche wächst dort, wo neue KI-Werkzeuge schnell und ohne Prüfung in bestehende Build-Ketten wandern.
Praktisch bedeutet das: Versionen festnageln statt automatisch aktualisieren, Abhängigkeiten mit Prüfsummen absichern, Build-Umgebungen ohne Zugriff auf produktive Secrets betreiben und ausgehenden Netzwerkverkehr aus der Pipeline einschränken. Aus Sicht von Hudson-Rock-CTO Alon Gal verschiebt die Größenordnung dieses Falls den Maßstab: Ein einziger Bruch weit oben in der Lieferkette treffe inzwischen Tausende Unternehmen gleichzeitig, was eine andere Art von Reaktion der Sicherheitsbranche erfordere.