Im Jahr 2026 evaluierte ein Sicherheitsunternehmen die KI-Plattform Baseten, die mit 13 Milliarden Dollar bewertet wird. In nur 25 Minuten erlangten sie Administratorrechte für die internen Kern-Code-Repositories. Dieser nahezu reibungslose Eindringungsprozess kam von Anfang bis Ende völlig ohne Software-Schwachstellen aus.
Das Durchsuchen öffentlicher Image-Historien bringt höchste Systemrechte
Strix ist ein Sicherheitsunternehmen, das autonome Penetrations-Agenten entwickelt. Vor der geplanten Datenübergabe führten sie einen routinemäßigen Vorab-Scan von Baseten ohne Zugangsdaten durch. Der Ausgangspunkt der Aufklärung war eine Container-Image-Registry, vergleichbar mit einem Frachtcontainer für Softwarepakete. Ein Projekt innerhalb der Registry war für alle vollständig öffentlich zugänglich. Jeder konnte ohne Passwort die Dateiliste einsehen und sogar ein anonymes Token anfordern, um Daten herunterzuladen.
Der fatale Fehler war in einem Protokoll namens “Build-Historie” verewigt. Wenn Docker Software verpackt, wird jeder Build-Befehl wie eine mit einem Zeitstempel versehene Quittung in der Historie festgehalten. Ein Konfigurationsbefehl zeigte eine Variable namens GITHUB_TOKEN direkt im Klartext an.
Entwickler nutzten dieses Token als Passwortersatz, in der Absicht, den Code-Pull-Prozess für das System reibungsloser zu gestalten. Die offizielle Dokumentation warnt ausdrücklich davor, dass Build-Parameter protokolliert werden. Doch aus Bequemlichkeit schrieben die Ingenieure die Variable direkt in den Befehl. Sicherheitsstandards wichen der Entwicklungsgeschwindigkeit, und branchenbekannte rote Linien wurden mühelos überschritten.
Bild: Das Token in der Docker-Build-Historie und die von GitHub zurückgegebenen Kontoinformationen. Quelle: Strix Postmortem
Ein drei Jahre lang nicht erneuertes Token übergibt die Kontrolle über das Kern-Repository
Dieser offengelegten Spur folgend, sicherte sich Strix ein aktives Token, das zu einer internen Baseten-Organisation gehörte. Dieses Token gewährte ihnen Zugriff auf sieben interne Repositories. Drei Hochrisikobereiche verfügten sogar über Administratorrechte und die höchste Befugnis zum Pushen von Code. Diese drei Knotenpunkte bildeten die komplette Lieferkette von der Codeentwicklung bis zum Kunden-Deployment.
Sobald das Haupt-Produkt-Repository kompromittiert ist, können Eindringlinge heimlich bösartige Logik in den Code einschleusen, der KI-Modelle ausführt. Das GitOps-Repository ist die direkte Autobahn zur Produktionsumgebung; es enthielt sogar Unterverzeichnisse, die nach Kundennamen kategorisiert waren. Die Übernahme der Verteilungs-Toolchain ist gleichbedeutend mit dem Öffnen einer Hintertür auf den Computern aller Entwickler, die dieses Tool verwenden.
Der aufgezeichnete Zeitstempel blieb am 3. März 2023 stehen. Bis zu seiner Entdeckung im Juli 2026 funktionierte dieses Token völlig uneingeschränkt. Die Zerstörungskraft von Zugangsdaten, die drei Jahre überfällig sind, übersteigt bei weitem die eines sorgfältig programmierten Trojaners. Unternehmen geben Unsummen für Firewalls aus, um externe Angriffe abzuwehren. Interne Berechtigungen, die jahrelang nicht aktualisiert wurden, werden jedoch ignoriert.
Bild: Der von GitHub zurückgegebene Token-Scope und die zugehörige Organisation. Quelle: Strix Postmortem
Eine 13-Milliarden-Dollar-Lektion, die durch eine lokale Überprüfung vermeidbar gewesen wäre
Nach Erhalt des Berichts reagierte das Sicherheitsteam von Baseten schnell, erneuerte das Token am darauffolgenden Nachmittag und sperrte das öffentliche Projekt. Das mit 13 Milliarden Dollar bewertete Unternehmen zeigte die nötige Entschlossenheit, um die Ausbreitung der Katastrophe zu stoppen. Die Zugangsdaten waren bereits in der Build-Historie durchgesickert. Das Ändern der Build-Datei zu diesem Zeitpunkt konnte heruntergeladene Images nicht zurückholen. Die einzige Abhilfe bestand darin, das Token an der Quelle zu widerrufen.
Die direkte Ursache des Vorfalls war, dass Ingenieure den Befehl git config verwendeten, um eine URL mit dem Token in die globale Konfiguration zu schreiben. Das Standardverfahren besteht darin, temporär gemountete, verschlüsselte Zugangsdaten zur Authentifizierung zu verwenden. Tokens müssen nach dem “Lesen und Verbrennen”-Prinzip behandelt werden und dürfen niemals auf Festplatten oder in Historienprotokollen verbleiben.
Um ein derartiges Leak von Zugangsdaten zu verhindern, ist lediglich ein einfacher lokaler Keyword-Matching-Filter erforderlich, bevor Code produktiv geschaltet wird. Wenn obligatorische Überprüfungsschritte im Entwicklungsprozess fehlen, wandern Anfängerfehler ungehindert bis in die Produktionsumgebung.
Der Zusammenbruch der Systemverteidigung wurzelt in den Alltagsgewohnheiten der Ingenieure
Die Bereiche, in denen Verteidiger leicht ihre Wachsamkeit verlieren, sind oft vergessene historische Ecken. Teams konzentrieren sich auf Kernanwendungen und die neuesten Code-Repositories, vergessen dabei aber oft ein Container-Image, das seine Wartungsphase längst überschritten hat. Selbst wenn man die Inhaltsdateien des Images scannt, bleibt das tödliche Token auf freiem Fuß, wenn man vergisst, die Build-Historie zu überprüfen.
Der Einbruch nutzte drei Schwachstellen aus, die alle von Menschen konfiguriert wurden: ein öffentlich lesbares Repository, falsch protokollierte Parameter und ein seit drei Jahren nicht erneuertes Token. Es gab keine überwältigende unbekannte Technologie, nur Türen, die von den Wächtern selbst weit offen gelassen wurden.
Die Sicherheitsdefizite von KI-Lieferketten verbergen sich oft in den grundlegendsten Konfigurations- und Hygienegewohnheiten der Ingenieure. Der Beweis, dass man die Kern-Assets eines 13-Milliarden-Dollar-Unternehmens in 25 Minuten übernehmen kann, setzt die deutlichste sicherheitstechnische Untergrenze: Selbst der teuerste Systemschutz kann einen übersprungenen Überprüfungsbefehl nicht ersetzen.
Referenzlinks:
- Strix Postmortem
