Wie vierzig Minuten kompromittierter KI-Code die digitalen Tresore von Tech-Giganten leerten

Ein moderner Sicherheits-Stack für Unternehmen kostet Millionen von Dollar an Lizenz- und Personalkosten. Diese Organisationen setzen erstklassige Schwachstellen-Scanner und strenge Zugriffskontrollen ein, um einen robusten Perimeter aufrechtzuerhalten. Dennoch bewies ein vierzigminütiges Zeitfenster im März, dass eine einzige bösartige Abhängigkeit in einem beliebten KI-Tool ausreicht, um diese Abwehrmechanismen vollständig zu umgehen. Der LiteLLM-Supply-Chain-Angriff führte zur Exfiltration von Terabytes sensibler Zugangsdaten aus einigen der sichersten Umgebungen des Planeten, darunter solche, die von Microsoft, Amazon und Samsung verwaltet werden.

Aus Risikoperspektive offenbart dieser Vorfall ein systemisches Versagen bei der Überprüfung der Tools, die zum Erstellen KI-gestützter Software verwendet werden. Die Sicherheitsverletzung geschah nicht aufgrund eines Fehlers in der künstlichen Intelligenz selbst. Sie geschah, weil die DevOps-Infrastruktur, die wir zur Bereitstellung von KI nutzen, fragil ist. Als Entwickler bei 2.500 Organisationen die Versionen 1.82.7 und 1.82.8 von LiteLLM aus dem Python Package Index herunterluden, luden sie unwissentlich ein digitales Trojanisches Pferd in ihre sensibelsten Systeme ein.

Das Paradoxon des sicheren Scanners

Der erschreckendste Aspekt dieser Sicherheitsverletzung ist ihr Ursprung. Die Infektion begann mit einem Supply-Chain-Angriff auf Trivy, einen weithin angesehenen Open-Source-Schwachstellen-Scanner. Organisationen nutzen Trivy gezielt, um Sicherheitslücken zu finden. Indem sie das Tool infizierten, das für Sicherheit sorgen sollte, erlangten die Angreifer eine Position absoluten Vertrauens. Hinter den Kulissen nutzten die Angreifer ein Versäumnis bei der Verwaltung von Automatisierungs-Token durch die Trivy-Entwickler aus. Obwohl das Team versuchte, einen kompromittierten Token zu rotieren, versäumten sie es, ihn für zwanzig Tage vollständig zu widerrufen. Dieses Versehen gab den Bedrohungsakteuren ein dreiwöchiges Zeitfenster, um bösartigen Code per Force-Push in nachgelagerte Builds einzuschleusen.

Diese Infektion verbreitete sich auf andere Softwarepakete, einschließlich KICS und das Telnyx Python SDK, bevor sie in LiteLLM landete. Dies schafft ein architektonisches Paradoxon, bei dem genau die Tools, die zur Härtung der Angriffsfläche entwickelt wurden, zum primären Vektor für die Ausnutzung werden. In meiner Erfahrung bei der Prüfung von Cloud-Umgebungen stelle ich oft fest, dass Teams ihren Sicherheits-Tools blind vertrauen. Sie gehen davon aus, dass die Integrität eines Scanners garantiert ist, wenn er offiziell und beliebt ist. Dieser Vorfall beweist, dass eine solche Annahme eine kritische Schwachstelle darstellt.

Ein vierzigminütiges Fenster in das Herz der Cloud

Das tatsächliche Fenster der aktiven Infektion für LiteLLM war bemerkenswert kurz. Nur vierzig Minuten lang waren die kompromittierten Versionen im offiziellen Python Package Index (PyPI)-Repository verfügbar. In dieser kurzen Zeit zogen automatisierte CI/CD-Pipelines und Entwickler auf der ganzen Welt den bösartigen Code. Die Geschwindigkeit der modernen Softwarebereitstellung bedeutet, dass vierzig Minuten mehr als genug Zeit sind, um Hunderttausende von Systemen zu infizieren.

Die Sicherheitsfirmen CloudSEK und Hudson Rock analysierten die Folgen, nachdem sie eine 195 TB große Datei mit den gestohlenen Daten erhalten hatten. Die schiere Menge an Informationen ist atemberaubend. Der Dump enthält Cloud-Keys, Repository-Token, SSH-Keys und Kubernetes-Secrets. Dies sind die Hauptschlüssel zum digitalen Königreich. Proaktiv betrachtet deutet die Tatsache, dass ein vierzigminütiges Fenster Terabytes an Daten liefern konnte, darauf hin, dass der infizierte Code hocheffizient bei der Identifizierung und Exfiltration hochwertiger Geheimnisse war.

Memory Scraping und der toxische Vermögenswert gespeicherter Geheimnisse

Der Mechanismus des Angriffs war sowohl einfach als auch verheerend. Die kompromittierten Versionen von LiteLLM enthielten Code, der darauf ausgelegt war, auf den Arbeitsspeicher der infizierten Maschine zuzugreifen. Die meisten Entwickler glauben, dass ein Geheimnis sicher ist, wenn es nicht in einer Textdatei gespeichert wird. Das ist ein Trugschluss. Der bösartige Code durchsuchte den Inhalt des Systemlaufzeit-Speichers nach Umgebungsvariablen und aktiven Sitzungs-Token.

Daten sind ein toxischer Vermögenswert, wenn sie unsachgemäß gehandhabt werden. In diesem Fall bestanden die "Daten" aus den Zugangsdaten, die zur Verwaltung von 434.000 CI/CD-Pipelines erforderlich sind. Diese Pipelines sind die Fließbänder der Softwareentwicklung. Wenn ein Angreifer über die Zugangsdaten für eine Pipeline verfügt, kann er seinen eigenen Code in jedes zukünftige Update injizieren, das das Unternehmen an seine Kunden ausliefert. Die Forscher stellten fest, dass viele dieser Zugangsdaten Klartextvariablen im Speicher waren, die völlig ungeschützt vorlagen. Die geernteten Daten umfassen aktive Datenbankpasswörter und API-Schlüssel von Drittanbietern, denen jegliche identifizierende Informationen fehlen, was es für Forscher schwierig macht, die korrekten Opfer überhaupt zu benachrichtigen.

Die Bedrohung durch Teenager und die Realität der DevOps-Kurzsichtigkeit

Die Verantwortung für den Angriff liegt bei TeamPCP, einer Gruppe, die größtenteils aus Teenagern besteht. Obwohl ihre Methoden möglicherweise keine hochkomplexen Zero-Day-Exploits beinhalteten, ist ihr Erfolg unbestreitbar. Der unabhängige Sicherheitsforscher Kevin Beaumont stellte fest, dass diese Angreifer Kreise um Organisationen ziehen, die derzeit davon besessen sind, KI-Produkte überhastet auf den Markt zu bringen.

Dieser Ansturm erzeugt eine DevOps-Kurzsichtigkeit. Organisationen priorisieren die Geschwindigkeit der KI-Integration gegenüber der grundlegenden Hygiene der Sicherheit der Software-Lieferkette. Wenn ich mit White-Hat-Hackern über verschlüsselte Kanäle kommuniziere, ist der Konsens immer derselbe: Man braucht keinen ausgeklügelten Exploit, wenn das Ziel die Tür unverschlossen lässt. Durch die Konzentration auf das "nächste große Ding" in der KI ignorierten viele Firmen die grundlegende Anforderung, die Integrität ihrer Abhängigkeiten zu überprüfen.

Das Scheitern der unvollständigen Rotation von Zugangsdaten

Der vielleicht besorgniserregendste Teil dieser Geschichte ist die reaktive Haltung der betroffenen Organisationen. Nachdem die Sicherheitsverletzung bekannt wurde, behaupteten mehrere große Tech-Unternehmen, sie hätten ihre Schlüssel bereits rotiert und der Vorfall sei eine Belanglosigkeit. Überprüfungsbemühungen der Sicherheits-Community erzählten jedoch eine andere Geschichte.

Kevin Beaumont berichtete, dass er, nachdem ein großes US-Technologieunternehmen behauptet hatte, alle Zugangsdaten seien rotiert worden, die geleakten Schlüssel gegen deren öffentlich zugängliche Infrastruktur testete. Fast jeder Schlüssel funktionierte noch. Dies deutet auf einen oberflächlichen Ansatz bei der Reaktion auf Vorfälle hin. Das Rotieren eines Schlüssels ist nicht dasselbe wie dessen Widerruf. Wenn der alte Schlüssel in einem sekundären System oder einer Legacy-Umgebung weiterhin gültig ist, bleibt die Sicherheitsverletzung aktiv. Im Falle einer Sicherheitsverletzung dieser Größenordnung muss eine Organisation davon ausgehen, dass jedes Geheimnis, auf das die infizierte Umgebung Zugriff hatte, kompromittiert ist. Eine teilweise Rotation ist im Grunde gar keine Rotation.

Praktische Schritte für die Resilienz der Lieferkette

Wenn Ihre Organisation LiteLLM, Trivy oder eine andere KI-Proxy-Infrastruktur nutzt, ist die Zeit für eine passive Reaktion vorbei. Die Bewertung der Angriffsfläche erfordert eine detaillierte Prüfung jedes Zugangsdatums, das in den letzten sechs Monaten durch Ihre CI/CD-Pipelines geflossen ist.

Checkliste für sofortige Abhilfemaßnahmen:

• Versionen überprüfen: Prüfen Sie Ihre Umgebung auf die LiteLLM-Versionen 1.82.7 und 1.82.8. Selbst wenn Sie inzwischen aktualisiert haben, wurden die Daten wahrscheinlich während des Zeitfensters exfiltriert, in dem diese Versionen aktiv waren.
• Aggressiver Widerruf von Zugangsdaten: Aktualisieren Sie nicht einfach nur Passwörter. Invalidieren und rotieren Sie jeden Cloud-Key (AWS/Azure/GCP), jedes Kubernetes-Service-Account-Token und jedes Git Personal Access Token (PAT), das in Ihren Umgebungsvariablen vorhanden war.
• Audit-Protokollierung und Egress: Suchen Sie im Monat März nach ungewöhnlichem ausgehendem Datenverkehr zu unbekannten IP-Adressen. Die Exfiltration von Terabytes an Daten hätte Egress-Filter-Alarme auslösen müssen, wenn diese ordnungsgemäß konfiguriert gewesen wären.
• Pinning und Hashing implementieren: Erlauben Sie Ihren CI/CD-Pipelines künftig nicht mehr, die "neueste" Version eines Pakets zu ziehen. Verwenden Sie Dependency Pinning und überprüfen Sie die SHA-256-Hashes jeder externen Bibliothek, bevor sie in Ihre Build-Umgebung gelangt.

Das Ausmaß dieses Angriffs drängt die Branche in eine neue Realität. Der Netzwerkperimeter ist ein veralteter Burggraben in einer Ära, in der wir alle paar Minuten freiwillig Code aus dem Internet herunterladen. Als Gegenmaßnahme müssen Organisationen jede externe Abhängigkeit als potenziell bösartig behandeln, bis das Gegenteil bewiesen ist. Sicherheit ist keine Checkliste, die man einmal im Jahr abarbeitet; es ist ein kontinuierlicher Prozess der Verifizierung.

Quellen:

• CloudSEK Threat Intelligence Report on LiteLLM Supply Chain Attack
• Hudson Rock Analysis of TeamPCP Data Dump
• MITRE ATT&CK Framework: Supply Chain Compromise (T1195)
• NIST Software Supply Chain Security Guidance

Haftungsausschluss: Dieser Artikel dient ausschließlich Informations- und Bildungszwecken und ersetzt keine professionelle Cybersicherheitsprüfung oder einen Incident-Response-Service.