Ein Angriff auf die Lieferkette im Open-Source-KI-Ökosystem zeigt, wie Bedrohungsakteure zunehmend Entwicklertools und KI-Infrastruktur missbrauchen, um Zugangsdaten zu stehlen und Cloud-Umgebungen zu kompromittieren.
Forscher stellten fest, dass TeamPCP LiteLLM kompromittiert hatte – eine weit verbreitete Open-Source-Python-Bibliothek, die Anwendungen über mit OpenAI kompatible APIs mit mehr als 100 LLM-Anbietern verbindet.
Der Angriff nutzte Berichten zufolge manipulierte LiteLLM-Pakete, um Zugangsdaten für KI-Plattformen, Cloud-Dienste, Kubernetes-Umgebungen und Entwickler-Pipelines zu stehlen.
Zentrale Erkenntnisse der Untersuchung zu TeamPCP
- TeamPCP kompromittierte LiteLLM durch einen Software-Lieferkettenangriff auf die Infrastruktur für die KI-Entwicklung.
- Die Angreifer manipulierten zunächst Trivy, um Token aus CI/CD-Pipelines zu stehlen und schädliche LiteLLM-Pakete auf PyPI zu veröffentlichen.
- Manipulierte LiteLLM-Versionen nutzten Quellcode-Injektionen und unauffällige Ausführungstechniken über .pth-Dateien zur Persistenz.
- Die Malware zielte auf Zugangsdaten für OpenAI, Anthropic, Azure, AWS, Kubernetes und Entwicklerumgebungen.
- Der Vorfall verdeutlicht die zunehmenden Risiken in KI-Ökosystemen, CI/CD-Pipelines und vertrauenswürdigen Open-Source-Abhängigkeiten.
Der Angriff begann mit einer Trivy-Kompromittierung
Laut der Analyse begann der Angriff, bevor LiteLLM selbst ins Visier genommen wurde.
TeamPCP kompromittierte zunächst Trivy, einen Schwachstellen-Scanner, der in viele CI/CD-Pipelines integriert ist.
Die Angreifer nutzten Berichten zufolge gefälschte Identitäten von Maintainerinnen und Maintainer und imitierten Commits, um das Trivy-Repository zu manipulieren und schädliche Binärdateien über GitHub Releases, Docker Hub und Amazon ECR zu verbreiten.
Da LiteLLM Trivy innerhalb seiner CI/CD-Pipeline nutzte, konnte der kompromittierte Scanner sensible Token aus der Build-Umgebung auslesen.
Die Forscher erklärten, dass die Malware das PYPI_PUBLISH-Token von LiteLLM direkt aus dem Speicher des CI/CD-Runners auslas. Dadurch konnten die Angreifer schädliche LiteLLM-Pakete veröffentlichen, ohne das offizielle Quellcode-Repository selbst zu kompromittieren.
Mit den gestohlenen Zugangsdaten stellte TeamPCP schädliche LiteLLM-Versionen auf PyPI bereit.
Zwei verschiedene Methoden zur Malware-Injektion
Die Angreifer nutzten in jeder Version der schädlichen Pakete unterschiedliche Techniken zur Bereitstellung der Malware.
LiteLLM Version 1.82.7 nutzte Berichten zufolge eine direkte Quellcode-Injektion, bei der eine Base64-codierte Nutzlast in die Datei proxy_server.py eingebettet wurde, die beim Start des LiteLLM-Proxydienstes ausgeführt wurde.
Version 1.82.8 nutzte eine unauffälligere Persistenztechnik mit einer schädlichen .pth-Datei namens litelllm_init.pth im site-packages-Verzeichnis von Python.
Da .pth-Dateien beim Start des Python-Interpreters automatisch ausgeführt werden, konnte die Malware laufen, selbst wenn die Anwendung LiteLLM nie ausdrücklich importierte.
Die Forscher stellten fest, dass bereits eine einfache Installation von LiteLLM 1.82.8 die Nutzlast in allen nachfolgenden Python-Prozessen auf dem betroffenen Host aktivierte.
Diebstahl von Zugangsdaten und Persistenz
Die Malware konzentrierte sich stark auf das Abgreifen von Zugangsdaten und die Persistenz.
Laut der Analyse durchsuchte die Nutzlast Systeme nach Umgebungsvariablen und Konfigurationsdateien, die großen KI-Anbietern und Cloud-Diensten zugeordnet waren.
Zu den angeblich anvisierten Zugangsdaten gehörten API-Schlüssel für OpenAI, Anthropic und Azure-KI-Dienste sowie Cloud-Zugangsdaten für AWS, Google Cloud und Microsoft-Azure-Umgebungen.
Die Malware versuchte außerdem, lokale Konfigurationsdateien wie Kubernetes-Konfigurationen und AWS-Zugangsdaten auszulesen, die in den Home-Verzeichnissen der Benutzer gespeichert waren.
Nach der Datensammlung verschlüsselte die Malware die Informationen und packte sie anschließend zur Exfiltration in ein komprimiertes Archiv.
Anschließend wurden die Daten an eine von den Angreifern kontrollierte entfernte Domain übertragen, die mit der Kampagne in Verbindung stand.
Die Malware etablierte außerdem Persistenz mithilfe einer Polling-basierten Hintertür zur Remote-Code-Ausführung, die regelmäßig einen sekundären Command-and-Control-Endpunkt kontaktierte, um zusätzliche Nutzlasten und Ausführungsanweisungen abzurufen.
So können Unternehmen das Risiko von KI-Lieferketten reduzieren
Da Angriffe auf Software-Lieferketten weiterhin Entwicklertools und KI-Ökosysteme betreffen, legen Unternehmen zunehmend Wert auf die Absicherung von Build-Pipelines und Abhängigkeits-Workflows.
Sicherheitsteams sollten darauf hinarbeiten, die Offenlegung von Zugangsdaten zu reduzieren, die Integrität von Paketen zu validieren, die Transparenz über Entwickleraktivitäten zu verbessern und sich auf mögliche Vorfälle in der Lieferkette vorzubereiten.
- CI/CD-Pipelines, Paket-Repositories und Entwicklerumgebungen auf nicht autorisierte Paketänderungen, verdächtige Veröffentlichungsaktivitäten und anomales Authentifizierungsverhalten überwachen.
- Den Zugriff auf Veröffentlichungstoken beschränken, API-Schlüssel und Cloud-Zugangsdaten, gleichzeitig das Prinzip der geringsten Rechte durchsetzen und MFA in Entwickler- und Build-Systemen verwenden.
- Die Paketintegrität mithilfe signierter Releases validieren, Prüfsummenverifizierung, Abhängigkeits-Scanning und Tools zur Software Composition Analysis (SCA), bevor die Bereitstellung erfolgt.
- Build-Umgebungen segmentieren und unnötige ausgehende Konnektivität begrenzen aus CI/CD-Runnern, um die Offenlegung von Zugangsdaten und die Risiken lateraler Bewegungen zu reduzieren.
- Python-Pakete kontinuierlich überwachen, KI-Bibliotheken und Open-Source-Abhängigkeiten auf schädliche Updates, Typosquatting und unerwartetes Installationsverhalten.
- Die Endpunktsichtbarkeit und Funktionen zur Verhaltenserkennung stärken , um Diebstahl von Zugangsdaten, Persistenzmechanismen und verdächtige Aktivitäten des Python-Interpreters zu erkennen.
- Regelmäßig Pläne zur Reaktion auf Vorfälle, Eindämmungs- und Wiederherstellungspläne testen , die sich auf Kompromittierungen von Software-Lieferketten, schädliche Pakete und Sicherheitsverletzungen in CI/CD-Pipelines beziehen.
Zusammengenommen können diese Maßnahmen Unternehmen helfen, ihre Gefährdung durch Software-Lieferketten zu reduzieren und ihre operative Resilienz zu stärken.
KI-Infrastruktur wird zum neuen Ziel
Die Kompromittierung von LiteLLM verdeutlicht die zunehmenden Risiken für KI-Infrastruktur und Software-Lieferketten, da Angreifer immer häufiger auf vertrauenswürdige Entwicklertools und CI/CD-Umgebungen abzielen.
Da LiteLLM als Gateway zu mehreren KI-Anbietern dient, kann eine einzige Kompromittierung potenziell Zugangsdaten für OpenAI, Anthropic, Azure und andere verbundene Dienste offenlegen.
Der Vorfall zeigt außerdem, wie Angreifer vertrauenswürdige Beziehungen innerhalb von Software-Pipelines missbrauchen können, indem sie eine frühere Kompromittierung von Trivy nutzen, um schädliche Pakete über legitime Repositories und nachgelagerte Entwicklungsumgebungen zu verbreiten.
Um Risiken in KI-Entwicklungs-Pipelines und vertrauenswürdigen Software-Ökosystemen zu reduzieren, setzen Unternehmen auf Zero-Trust-Strategien, die dazu beitragen, Zugriffskontrollen, Segmentierung und die Identitätssicherheit zu stärken.