Eine weit verbreitete Bibliothek für die KI-Entwicklung wurde bei einem kürzlich erfolgten Angriff auf die Lieferkette kompromittiert und könnte eine große Zahl von Systemen einem Risiko ausgesetzt haben.
Schädliche LiteLLM-Pakete auf PyPI wurden mit einer Hintertür versehen und konnten unbemerkt Zugangsdaten, Token und sensible Infrastrukturdaten aus Entwicklungs- und Produktionsumgebungen stehlen.
„Die Kompromittierung von LiteLLM zeigt, wie schnell Angriffe auf die Lieferkette eskalieren können und wie blind wir sind, wenn wir uns nur auf bekannte Schwachstellen verlassen“, sagte Dr. Zulfikar Ramzan, Chief Technology & AI Officer von Point Wild in einer E-Mail an eSecurityPlanet.
„Dieser Vorfall zwingt uns zu einer umfassenderen Diskussion darüber, wie Unternehmen mit ihrem Abhängigkeitsgraphen umgehen. Zero Trust wurde auf Benutzer, Geräte und Netzwerke angewendet. Abhängigkeiten verdienen dieselbe Prüfung“, sagte Jacob Krell, Senior Director of Secure AI Solutions & Cybersecurity bei Suzu Labs in einer E-Mail an eSecurityPlanet.
„Das sollte uns Sorge bereiten, weil die Abhängigkeit der Branche von öffentlichen Repositories ohne lokale Hash-Überprüfung oder ‚Lockfiles‘ das Internet faktisch in eine ungeprüfte Produktionsabhängigkeit verwandelt hat“, sagte Noelle Murata, Sr. Security Engineer bei Xcape, Inc in einer E-Mail an eSecurityPlanet.
„Das grundlegende Problem ist, dass die Software-Lieferkette noch immer auf zu viel implizitem Vertrauen und zu wenig Unveränderlichkeit oder Verifizierung beruht“, sagte Cory Michal, CISO bei AppOmni in einer E-Mail an eSecurityPlanet.
Der Angriff auf die LiteLLM-Lieferkette im Überblick
Der Angriff zielt auf LiteLLM, eine Open-Source-Bibliothek mit etwa 95 Millionen Downloads pro Monat, die Anfragen über eine einzige Schnittstelle an mehrere LLM-Anbieter weiterleitet.
Da LiteLLM in Produktions- und Cloud-Umgebungen weit verbreitet ist, hat die Bibliothek häufig Zugriff auf sensible Daten wie API-Schlüssel, Cloud-Zugangsdaten und Kubernetes-Konfigurationen.
Forscher führen den Angriff auf TeamPCP zurück, einen Bedrohungsakteur, der mit jüngsten Kompromittierungen der Lieferkette im Zusammenhang steht, bei denen Tools wie Trivy und KICS betroffen waren.
So wurde die Hintertür eingeschleust
Der Schadcode wurde in die PyPI-Distribution eingeschleust, während das GitHub-Repository sauber blieb. Das bedeutet, dass Entwickler bei der Prüfung des Quellcodes nichts Verdächtiges sahen, während installierte Pakete mit einer Hintertür versehen waren.
Der Vorfall legt eine kritische Schwachstelle in der Software-Lieferkette offen: Viele Unternehmen vertrauen Paketregistern, ohne unabhängig zu überprüfen, ob die verteilten Artefakte mit ihrer Quelle im Upstream übereinstimmen.
Der mehrstufige Angriff im Überblick
Nach der Installation verwendet die Schadsoftware eine mehrstufige Ausführungskette, die auf Heimlichkeit und Persistenz ausgelegt ist.
Der anfängliche Auslöser ist trügerisch simpel – ein kleiner Abschnitt eingeschleusten Codes, der eine verborgene Payload dekodiert und ausführt, sobald das betroffene Modul importiert wird.
Die Angreifer trieben die Technik weiter voran, indem sie eine schädliche .pth-Datei einbanden. Diese bewirkt, dass die Payload bei jedem Start des Python-Interpreters automatisch ausgeführt wird – selbst wenn LiteLLM nie direkt verwendet wird.
Dadurch vergrößert sich der Schadensradius, und jede Python-Ausführung wird zu einem potenziellen Angriffspunkt.
Nach der Ausführung durchläuft die Schadsoftware drei koordinierte Phasen.
Zunächst bereitet ein Orchestrierungsskript die Angriffskette vor und startet sie.
Als Nächstes sammelt eine Komponente zum Abgreifen von Zugangsdaten systematisch sensible Daten vom Host, darunter SSH-Schlüssel, Zugangsdaten von Cloud-Anbietern, Kubernetes-Secrets, .env-Dateien, Datenbankkonfigurationen und andere besonders wertvolle Artefakte.
Schließlich etabliert die Schadsoftware Persistenz, indem sie eine Backdoor auf Systemebene installiert, die regelmäßig von Angreifern kontrollierte Infrastruktur kontaktiert, um zusätzliche Payloads und Anweisungen abzurufen.
Der Angriff dient nicht nur dem einfachen Datendiebstahl, sondern ist auf Ausweitung ausgelegt.
Die Schadsoftware ermöglicht laterale Bewegungen in Kubernetes, indem sie privilegierte Pods auf mehreren Nodes bereitstellt, um den Zugriff der Angreifer auszuweiten.
Vor der Exfiltration werden die gestohlenen Daten verschlüsselt und an von Angreifern kontrollierte Domains übertragen, was die Erkennung erschwert.
Risiken in der Software-Lieferkette eindämmen
Unternehmen, die möglicherweise den kompromittierten LiteLLM-Paketen ausgesetzt waren, sollten schnell handeln, um das Risiko zu bewerten und potenzielle Schäden einzudämmen.
Angesichts des Umfangs des Angriffs und seines Fokus auf den Diebstahl von Zugangsdaten und Persistenz reichen standardmäßige Maßnahmen zur Behebung möglicherweise allein nicht aus.
Sicherheitsteams sollten betroffene Umgebungen als potenziell kompromittiert behandeln und sowohl die sofortige Bereinigung als auch eine langfristige Härtung priorisieren.
- Kompromittierte LiteLLM-Versionen entfernen, eine verifizierte saubere Version neu installieren und betroffene Systeme ausgehend von einer bekannten guten Basis neu aufbauen, statt eine Bereinigung im laufenden Betrieb zu versuchen.
- Nach Persistenzmechanismen und Kompromittierungsindikatoren suchen, darunter verdächtige systemd-Dienste, unerwartete Dateien und nicht autorisierte Kubernetes-Pods oder privilegierte Workloads.
- Alle offengelegten Zugangsdaten rotieren und widerrufen, darunter Cloud-Token, API-Schlüssel, SSH-Schlüssel und aktive Sitzungen; außerdem sollten IAM-Rollen und der Zugriff auf Secrets auf Anzeichen eines Missbrauchs geprüft werden.
- CI/CD-Pipelines und Entwicklungsumgebungen auf nachgelagerte Kompromittierungen prüfen, Pipeline-Secrets rotieren und Protokolle auf den Verlust von Zugangsdaten oder anomale Aktivitäten prüfen.
- Netzwerk- und Netzwerk- und System-verhalten auf Anzeichen von Exfiltration und lateralen Bewegungen überwachen, darunter ungewöhnlichen ausgehenden Datenverkehr, regelmäßige Beaconing-Aktivität und abnormale Muster bei der Prozessausführung.
- Die Sicherheit der Lieferkette durch das Fixieren von Abhängigkeiten, die Überprüfung von Paketen anhand der Upstream-Quellen, den Einsatz vertrauenswürdiger Publishing-Verfahren und die Aufrechterhaltung der SBOM-Transparenz in allen Umgebungen stärken.
- Regelmäßig Pläne zur Reaktion auf Vorfälle testen und Tabletop-Übungen zu Angriffsszenarien auf die Software-Lieferkette durchführen.
Zusammengenommen helfen diese Maßnahmen Unternehmen, ihre Widerstandsfähigkeit gegen Angriffe auf die Lieferkette zu stärken und gleichzeitig die Gefährdung durch kompromittierte Abhängigkeiten und verborgene Bedrohungen zu verringern.
Vertrauenswürdige Tools werden zu Zielen
Der Vorfall um LiteLLM spiegelt einen breiteren Wandel wider: Angreifer konzentrieren sich zunehmend auf Tools, die bereits Zugriff auf sensible Systeme und Daten haben.
Indem sie diese Komponenten mit hohem Vertrauensniveau ins Visier nehmen, können Bedrohungsakteure traditionelle Abwehrmaßnahmen leichter überwinden und ihre Reichweite innerhalb einer Umgebung ausweiten.
Der Vorfall zeigt auch, wie sich Angriffe über mehrere Ökosysteme erstrecken können: Gruppen wie TeamPCP nutzen gestohlene Zugangsdaten aus einer Kompromittierung, um den nächsten Angriff über CI/CD-Pipelines, Paketregister und nun auch KI-Tools zu ermöglichen.
Für Unternehmen unterstreicht dies die Notwendigkeit, die Integrität von Softwareabhängigkeiten kontinuierlich zu überprüfen.
Genau hier kann ein Zero-Trust-Ansatz dazu beitragen, die Abwehr gegen moderne Angriffe auf die Lieferkette zu stärken.