Wenn ein KI-Tool zur Hintertür wird: 153 GB Zugangsdaten aus fremden Pipelines

Was ist passiert?

Eine Angreifergruppe hatte bereits im März manipulierte Versionen mehrerer verbreiteter Entwickler-Werkzeuge in PyPI hochgeladen — dem zentralen Paketverzeichnis für die Programmiersprache Python. Betroffen waren unter anderem LiteLLM, ein weit genutztes Werkzeug zur Anbindung von KI-Modellen, sowie Sicherheits- und Analyse-Tools.

Die manipulierten Pakete taten etwas Unauffälliges und sehr Wirksames: Sie sammelten beim Einsatz Zugangsdaten aus automatisierten Bauprozessen ein — also aus den Systemen, in denen Software gebaut, getestet und ausgeliefert wird. Genau dort liegen die Schlüssel zu Cloud-Konten, Datenbanken und Produktivsystemen.

Jetzt, rund fünf Monate später, ist das Ergebnis aufgetaucht: ein 153 Gigabyte großer Datensatz mit Tokens, Schlüsseln und Zugangsdaten aus den Pipelines von 2.488 Unternehmen. Berichten von Golem und Help Net Security zufolge finden sich darunter auch große deutsche Konzerne wie Siemens, Volkswagen, BMW, Bosch und die Deutsche Bahn. Und das Unangenehmste: Ein Teil der Zugangsdaten ist weiterhin gültig.

Warum ist das schlimmer als ein normaler Datenabfluss?

Weil hier keine Kundendaten abgeflossen sind, sondern Schlüssel. Ein Datensatz mit Adressen ist ein Schaden, der abgeschlossen ist. Ein gültiges Zugangstoken ist eine offene Tür, die weiter offen steht, bis jemand sie schließt.

Dazu kommt der Ort: In der Bau- und Auslieferungsumgebung (oft „CI/CD-Pipeline" genannt — die Kette aus Bauen, Testen, Ausliefern) sind Zugangsdaten hinterlegt, die weitreichende Rechte haben. Sie müssen Software auf Produktivsysteme bringen können, also können sie es auch für jemand anderen.

Und der zeitliche Abstand macht es doppelt unangenehm: Zwischen dem Einschleusen im März und dem Auftauchen des Datensatzes im August liegen fünf Monate, in denen niemand etwas bemerkt hat. Wer jetzt erst reagiert, hat einen entsprechend langen Zeitraum ungeklärt.

Betrifft das ein Unternehmen, das gar nicht programmiert?

Häufiger, als man denkt — auf drei Wegen. Erstens direkt: Wenn Sie eine individuell entwickelte Anwendung, ein Kundenportal oder einen Webshop betreiben lassen, existiert irgendwo eine solche Pipeline. Sie steht meist bei Ihrer Agentur oder Ihrem Softwarehaus — die Zugangsdaten darin gehören aber zu Ihren Systemen.

Zweitens über KI-Werkzeuge: LiteLLM ist genau die Art Baustein, die derzeit überall eingezogen wird, wo Unternehmen eigene KI-Funktionen anbinden — vom Chatbot bis zur Dokumentenauswertung. Wer in den letzten Monaten etwas in dieser Richtung gebaut hat, sollte genau hinsehen.

Drittens als Zulieferer: Hängen Ihre Systeme in der Pipeline eines Kunden, betrifft Sie dessen Vorfall unmittelbar. Das ist dasselbe Muster wie bei den zuvor beschriebenen Fällen — beim npm-Wurm Shai-Hulud und beim Bitwarden-Vorfall. Neu ist hier nicht der Weg, sondern die Beute: nicht Daten, sondern Schlüssel.

Was sollten Sie jetzt konkret klären?

Fünf Fragen an Ihre IT, Ihre Agentur oder Ihren Softwaredienstleister — schriftlich, mit Datum:

• Nutzen wir LiteLLM oder eines der betroffenen Pakete? Auch in Nebenprojekten und Testumgebungen.
• Wurde seit März gebaut oder installiert? Das ist das Zeitfenster.
• Welche Zugangsdaten liegen in unseren Pipelines? Cloud-Schlüssel, Datenbank-Passwörter, API-Tokens, Signaturzertifikate.
• Wurden diese seit März erneuert? Wenn nein: jetzt, unabhängig davon, ob eine Betroffenheit nachweisbar ist.
• Sehen wir ungewöhnliche Zugriffe? Anmeldungen zu untypischen Zeiten oder aus untypischen Regionen.

Wichtig ist die Reihenfolge: Erst erneuern, dann untersuchen. Solange ein Schlüssel gültig ist, nützt die beste Analyse nichts.

Wie verhindern Sie, dass sich das wiederholt?

Die einzelnen Bausteine kann man nicht absichern — den Umgang mit Schlüsseln schon:

• Kurzlebige Zugangsdaten: Tokens, die nach Stunden ablaufen, sind fünf Monate später wertlos.
• Minimale Rechte: Ein Bau-Prozess braucht selten Vollzugriff auf alles. Was er nicht darf, kann auch niemand missbrauchen.
• Schlüssel nicht im Code: Zugangsdaten gehören in einen Tresor, nicht in eine Konfigurationsdatei.
• Feste Versionen statt automatischer Sprünge im Produktivsystem, plus automatische Prüfung auf bekannte Schadversionen.
• Regelmäßige Rotation als Routine — nicht erst im Schadensfall.

Für die meisten Mittelständler heißt das nicht, das selbst aufzubauen, sondern es vertraglich einzufordern: Wer Software für Sie betreibt, sollte diese Punkte nachweisen können.

Was sollten Sie als Nächstes tun?

Wenn Sie in den letzten Monaten KI-Funktionen entwickeln lassen haben, ist dieser Fall Ihr Anlass für eine unangenehme, aber kurze Frage an den Dienstleister: Welche unserer Schlüssel liegen bei euch, und wann wurden sie zuletzt erneuert?

Kommt darauf keine belastbare Antwort, ist das der eigentliche Befund — unabhängig von diesem Vorfall. Gern gehen wir das mit Ihnen durch: Wir verschaffen Ihnen einen Überblick, welche Zugänge zu Ihren Systemen außerhalb Ihres Hauses liegen, und legen fest, wer sie in welchem Rhythmus erneuert.