Ausnutzung von Schwachstellen
Kennen Sie Ihre Software-Lieferkette? Sollten Sie besser!
Ein aktueller Vorfall rund um eine Lieferkette mit manipulierten Open-Source-Paketen zeigt, dass viele Organisationen bis heute keinen klaren Überblick über die eingesetzten Komponenten und Abhängigkeiten haben. Ohne diese Transparenz wird jede Reaktion zur Krise.
Save to Folio
Angriffe auf Software-Lieferketten sind längst keine abstrakte Gefahr mehr, sondern Realität – und sie treffen genau dort, wo Unternehmen sich am sichersten fühlen: in ihren eigenen Entwicklungsprozessen.
Am 24. März veröffentlichte die Bedrohungsgruppe TeamPCP zwei manipulierte Versionen des Python-Pakets LiteLLM auf PyPI. LiteLLM ist ein Open-Source-Gateway für LLM-APIs, das laut Wiz Research in 36 % aller Cloud-Umgebungen läuft. Die KI-Lieferkette wird also bereits aktiv angegriffen!
Die kompromittierten Versionen enthielten einen Credential Stealer, der SSH-Schlüssel, Cloud-Zugangsdaten und CI/CD-Secrets exfiltriert. Obwohl die manipulierten Pakete nur rund drei Stunden auf PyPI verfügbar waren, erbeutete TeamPCP nach eigenen Angaben allein über LiteLLM rund 500.000 Zugangsdaten — insgesamt sollen es 300 GB komprimierter Credentials sein, mit denen die Gruppe kurz darauf milliardenschwere Unternehmen erpresste.
Dieser Vorfall war kein isolierter Angriff, sondern das dritte Glied in einer Kette. Zuvor hatte TeamPCP den Schwachstellen- und SBOM-Scanner Trivy kompromittiert. Ein dabei erbeutetes API-Token ermöglichte den Zugriff auf die LiteLLM-Publishing-Pipeline. Dass ausgerechnet Sicherheitswerkzeuge das Ziel waren, ist kein Zufall: Sie laufen in CI/CD-Pipelines mit erhöhten Rechten und genießen implizites Vertrauen. Wer sie kompromittiert, hat Zugriff auf die sensibelsten Bereiche der Entwicklungsinfrastruktur.
Es geht nicht um LiteLLM
Der Punkt dabei ist ein systemisches Versäumnis: Die meisten Organisationen kennen ihre Software-Lieferkette nicht und können daher im Falle eines Falles nicht schnell genug reagieren. Die Frage, ob man von LiteLLM, Trivy oder der nächsten kompromittierten Bibliothek betroffen ist, lässt sich nur beantworten, wenn man vorher weiß, was in den eigenen Systemen steckt. Diese Fähigkeit zur schnellen Triage macht den Unterschied zwischen kontrollierter Reaktion und Panik in der Krise aus.
Spätestens seit Log4Shell hätte das klar sein müssen. Ende 2021 stellte die Schwachstelle CVE-2021-44228 genau die gleiche Frage: „Können Sie schnell sagen, ob Sie von dieser Schwachstelle betroffen sind?”. Viereinhalb Jahre später lässt sich festhalten, dass viele Unternehmen diese Lektion leider nicht gelernt haben.
Die Landkarte ist nicht das Gelände
Software Bills of Materials (SBOMs) sind das zentrale Instrument für die Transparenz von Softwareabhängigkeiten. Werkzeuge wie Trivy oder OWASP Dependency Track erzeugen SBOMs automatisiert, korrelieren sie mit Schwachstellendatenbanken und ermöglichen so die schnelle Triage, die bei einem Vorfall wie LiteLLM entscheidend ist. Unter NIS2 ist diese Dokumentation in vielen Fällen nicht mehr nur Best Practice, sondern auch regulatorisch vorgeschrieben.
Doch hier die Warnung: SBOMs sind Dokumentation, nicht Security! Sie sorgen für mehr Transparenz, aber nicht per se für mehr Sicherheit. Wie das G7-Papier „SBOM for AI” diese definiert, sind SBOMs „not explicitly a cybersecurity tool”.
Das heißt, sie entfalten ihren Nutzen erst in Verbindung mit operativen Prozessen. Wer ein SBOM erstellt und in der Schublade verschwinden lässt, hat nichts gewonnen. Dass das BSI im Rahmen der G7 inzwischen ein erweitertes SBOM-Konzept für KI-Systeme, inklusive Modelle, Trainingsdaten und der zugehörigen Infrastruktur, vorantreibt, unterstreicht die Dynamik.
Was Sie tun können
Auffällig bei obigem Vorfall war, dass Docker-Benutzer von LiteLLM mit gepinnten Abhängigkeiten (sicherstellen, dass jedes Mal genau dieselbe Version genutzt wird) nicht betroffen waren. Trivy-Benutzer, die auf unveränderliche Commit-SHAs statt auf veränderliche Tags verwiesen, waren ebenfalls nicht betroffen. Das zeigt, dass Dependency Pinning eine der einfachsten Maßnahmen ist, die sofort wirkt – ohne zusätzliche Infrastruktur.
Wer seine Software-Lieferkette nicht kennt, kann sie auch nicht verteidigen. Schlimmer noch: Ohne geeignete Maßnahmen bemerkt man eine Kompromittierung unter Umständen gar nicht und wird im schlimmsten Fall selbst zum Sprungbrett für Angriffe auf andere.
Genau das zeigt die TeamPCP-Kampagne: Trivy wurde kompromittiert, der erbeutete Token öffnete die Tür zu LiteLLM, und die Kette hätte weitergehen können. Die Werkzeuge, um diese Sichtbarkeit herzustellen, sind vorhanden und frei verfügbar. Was oft fehlt, ist der Wille, sie zu nutzen, bevor der nächste Vorfall diese Entscheidung zunichte macht. Wer erst nach Bekanntwerden einer Schwachstelle beginnt, seine Lieferkette zu kartieren, hat meist schon verloren.
- Erfassen Sie Ihre Software-Lieferkette. Tools wie Trivy (trotz der aktuellen Vorkommnisse) oder OWASP Dependency Track sind Open Source, ausgereift und kostenlos. Integrieren Sie die SBOM-Erstellung in Ihre CI/CD-Pipeline.
- Pinnen Sie Ihre Abhängigkeiten. Verwenden Sie exakte Versionsangaben und Commit-SHAs statt mutabler Tags — insbesondere bei GitHub Actions und Container Images.
- Behandeln Sie SBOMs als lebende Dokumente. Korrelieren Sie sie kontinuierlich mit Schwachstellendatenbanken, und etablieren Sie Prozesse für Alarmierung und Reaktion.
- Fordern Sie SBOMs von Ihren Zulieferern ein. Unter NIS2 haben Sie in vielen Fällen eine regulatorische Grundlage dafür.
- Sichern Sie auch Ihre Sicherheitswerkzeuge ab. TeamPCP zeigt: Scanner und CI/CD-Tools sind wegen ihres erhöhten Vertrauens besonders attraktive Ziele.
Dieser Beitrag (wie auch schon frühere) ist zuerst im connect professional Security Awareness Newsletter erschienen. Interessenten können sich hier kostenlos für den Newsletter anmelden.