OpenAI Codex-Authentifizierungstoken bei npm-Supply-Chain-Angriff gestohlen
Das Risiko in der Lieferkette konzentrierte sich traditionell auf Softwareabhängigkeiten, die Schwachstellen in kompilierte Produkte einbringen – wie bei SolarWinds und XZ Utils. Der Codex-Token-Diebstahl folgt einem anderen Modell. Das kompromittierte Paket bringt keine Schwachstelle in den Code des Entwicklers ein, sondern entwendet Zugangsdaten direkt aus der Entwicklungsumgebung während der Arbeit.
Der Angriffsverlauf folgt einem vorhersehbaren Muster: Ein funktionierendes Paket wird veröffentlicht und über normale Kanäle heruntergeladen; das Paket wird gepflegt und aktualisiert, wodurch ein Commit-Verlauf entsteht, der Legitimität signalisiert; irgendwann wird Code zum Sammeln von Zugangsdaten hinzugefügt; und weil das Paket weiterhin wie erwartet funktioniert, prüfen Entwickler es nicht genauer. Die Exfiltration läuft wochen- oder monatelang unbemerkt, bevor sie entdeckt wird.
Die Qualität der Tarnung im Codex-Fall ist lehrreich. Gestohlene Zugangsdaten wurden an einen Server gesendet, der eine Sentry-Fehlerberichts-Integration nachahmte – ein Dienst, der routinemäßig Telemetriedaten von Entwickler-Tools empfängt. Netzwerküberwachung, die ausgehende Verbindungen zu unbekannten Domains meldet, würde eine Verbindung zu einer scheinbaren Sentry-Adresse nicht auffällig finden. Der Angreifer hat das gängigste Erkennungsverfahren für ausgehende Datenabflüsse vorausgesehen und umgangen.
Programme zum Management von Lieferantenrisiken, die die Sicherheitslage von Softwareanbietern bewerten, müssen ihren Fokus auf die Paket-Ökosysteme ausweiten, in denen diese Anbieter agieren. Ein npm-Paket ist eine Lieferantenbeziehung – jedoch ohne jeden Beschaffungsprozess.
5 Wichtige Erkenntnisse
1. Ein funktionierendes npm-Paket stahl einen Monat lang unbemerkt Codex-OAuth-Tokens.
„codexui-android“ – mit ca. 29.000 wöchentlichen Downloads – sammelte OpenAI Codex-Authentifizierungs-Tokens aus dem lokalen Speicher und sendete vollständige OAuth-Zugangsdaten-Bundles an einen vom Angreifer kontrollierten Server, der als Sentry-Endpunkt getarnt war. Die gleiche Exfiltrationslogik fand sich in zwei Android-Apps mit insgesamt über 60.000 Downloads. Das Paket erfüllte seine beworbene Funktion, während im Hintergrund Zugangsdaten abgegriffen wurden – für Entwickler gab es keinerlei Anzeichen für ein Problem. Pre-Publish-Scans in der Lieferkette erkennen dieses Muster nicht.
2. Refresh Tokens laufen nicht ab – dieser Diebstahl ist daher besonders hartnäckig.
Die gestohlene Datei ~/.codex/auth.json enthielt Refresh Tokens, nicht nur Access Tokens. Ein Angreifer mit einem Refresh Token kann das Opfer dauerhaft und unbemerkt imitieren, da er jederzeit neue Access Tokens generieren kann, ohne eine erneute Authentifizierung auszulösen. Die meisten Opfer eines Credential-Diebstahls wissen nichts davon und widerrufen daher nichts – kontinuierliche kontextbezogene Verifizierung ist als Kontrollmechanismus nachhaltiger als das reine Ablaufen von Tokens.
3. Die Speicherung von Zugangsdaten im Klartext ist ein systemisches Risiko in Entwickler-Toolchains.
Jedes installierte Paket hat potenziellen Zugriff auf alle im Home-Verzeichnis gespeicherten Zugangsdaten. Das gleiche Muster findet sich bei Cloud-Provider-CLIs, Versionskontrollsystemen, Container-Registries und KI-Dienstleistern – sie speichern Zugangsdaten häufig als Klartextdateien lokal. Frameworks für das Lieferantenrisikomanagement, die für SaaS-Anbieter entwickelt wurden, benötigen ein entsprechendes Pendant für Open-Source-Paketabhängigkeiten.
4. Gestohlene KI-Entwickler-Zugangsdaten können Unternehmensdaten weit über den Arbeitsplatz hinaus kompromittieren.
Codex-Tokens gewähren Zugriff auf alle Unternehmenssysteme, mit denen der Entwickler verbunden ist – Filesharing-Umgebungen, Managed File Transfer-Pipelines, Content-Repositories und interne APIs. Ein Angreifer mit gültigen Entwickler-Zugangsdaten kann mit diesen Systemen über KI-gestützte Workflows interagieren, die für Audit-Logging-Systeme, die auf anomales menschliches Verhalten achten, völlig unauffällig erscheinen.
5. Zero-trust-Zugriffskontrolle begrenzt die Folgen selbst bei gestohlenen Zugangsdaten.
Richtlinienbedingungen für sensible Daten – nicht nur die Identität des Credentials – entscheiden, ob Zugriff gewährt wird. Zero-trust-Datenschutz bedeutet: Ein gestohlenes Token, das von einem unerwarteten Ort, zu einer ungewöhnlichen Zeit oder für Daten außerhalb des normalen Bereichs verwendet wird, kann bei der Richtlinienprüfung durchfallen, auch wenn das Token technisch gültig ist. Der Kiteworks Secure MCP Server bildet den Kontrollpunkt, den angreiferkontrollierte Tokens nicht umgehen können.
Sie Vertrauen Darauf, Dass Ihr Unternehmen Sicher Ist. Doch Können Sie Es Nachweisen?
Jetzt Lesen
Warum Die Speicherung von Zugangsdaten im Klartext Ein Systemisches Risiko Ist
Die Datei ~/.codex/auth.json speichert OAuth-Zugangsdaten im Klartext, weil dies für Entwickler-Tools der Weg des geringsten Widerstands ist. Entwickler benötigen eine reibungslose Authentifizierung ihrer Tools. Zugangsdaten-Dateien im lokalen Dateisystem, die von jedem Prozess des Entwicklers lesbar sind, lösen dieses Problem effizient – schaffen aber auch einen Single Point of Failure: Jeder Prozess mit Lesezugriff kann alles abgreifen, was zur Nachahmung des Kontos nötig ist.
Das ist kein Codex-spezifisches Problem. Das gleiche Muster findet sich in Entwickler-Toolchains – Cloud-Provider-CLIs, Versionskontrollsysteme, Container-Registries und KI-Dienstleister speichern Zugangsdaten häufig als Klartextdateien lokal. Sicherheitsteams, die sich auf netzwerkbasierte Zugriffskontrollen und Perimeter-Schutz konzentrieren, übersehen diese lokale Credential-Oberfläche oft völlig.
Jedes installierte Paket hat potenziellen Zugriff auf alle im Home-Verzeichnis gespeicherten Zugangsdaten. Risikomanagement-Frameworks für Drittparteien, die für SaaS-Anbieter und Cloud-Provider entwickelt wurden, benötigen ein entsprechendes Framework für Open-Source-Paketabhängigkeiten. Zugangsdaten im ruhenden Zustand sollten genauso behandelt werden wie sensible Daten im ruhenden Zustand: Verschlüsselung mit Schlüsseln, die getrennt vom verschlüsselten Material gespeichert werden.
Wie Gestohlene KI-Zugangsdaten Zu Unternehmensweiten Datenpannen Werden
Der Codex-Token-Diebstahl ist nicht nur eine Konto-Kompromittierung – er ist der erste Schritt in einer Kette, die mit dem Abfluss von Unternehmensdaten enden kann. Ein Entwickler installiert ein bösartiges Paket; das Paket sammelt Codex-Zugangsdaten; der Angreifer nutzt diese Zugangsdaten, um auf alle Unternehmenssysteme zuzugreifen, die das Entwicklerkonto erreichen kann; der Angreifer extrahiert sensible Inhalte über Kanäle, die vom legitimen Entwicklerverhalten nicht zu unterscheiden sind.
Am stärksten gefährdet sind Unternehmensdaten-Systeme, mit denen KI-Tools zunehmend verbunden werden: Dokumenten-Repositories, sichere Filesharing-Plattformen, virtuelle Datenräume und Managed File Transfer-Pipelines. Diese Systeme enthalten Verträge, Finanzdaten, geistiges Eigentum und regulierte personenbezogene Informationen. Ein Angreifer mit Codex-Zugangsdaten eines Entwicklers kann mit diesen Systemen über KI-gestützte Workflows interagieren, die für Audit-Logging-Systeme, die auf anomales menschliches Verhalten achten, völlig unauffällig erscheinen.
Kiteworks unterbricht diese Kette auf der Datenzugriffsebene. Der Secure MCP Server steuert, welche KI-Tools überhaupt mit Unternehmensdaten interagieren dürfen – stimmt die Identität oder der Richtlinienkontext eines Tools nicht mit dem erlaubten Satz überein, erhält es keinen Zugriff, unabhängig von den präsentierten Zugangsdaten. ABAC-Prüfungen gehen noch weiter: Sie bewerten nicht nur, wer anfragt, sondern auch, welche Attribute die Anfrage, die Daten und den Kontext beschreiben. Ein gestohlenes Token, das von einem unerwarteten geografischen Standort, zu einer ungewöhnlichen Zeit oder für Daten außerhalb des normalen Entwicklerbereichs verwendet wird, kann bei der Richtlinienprüfung durchfallen – selbst wenn das Token gültig ist.
Reaktion Auf Kompromittierungen Der KI-Toolchain-Lieferkette
Tritt ein solcher Credential-Diebstahl auf, erfolgt die Reaktion auf zwei Ebenen: Sofortige Eindämmung der aktuellen Gefährdung und Aufbau von Kontrollen zur Vermeidung künftiger Vorfälle. Die sofortige Eindämmung erfordert das Widerrufen aller potenziell kompromittierten Tokens – jeder Entwickler, der das betroffene Paket im Gefährdungszeitraum installiert hat, sollte seine auth.json-Zugangsdaten als kompromittiert betrachten. Das Widerrufen von Tokens ist in den meisten OAuth-Implementierungen ein manueller Prozess, und Unternehmen ohne Übersicht darüber, welche Entwickler welche Service-Zugangsdaten besitzen, werden Schwierigkeiten haben, dies umfassend umzusetzen.
Ein Incident-Response-Plan für Kompromittierungen der KI-Toolchain sollte die automatisierte Erkennung von Zugriffen auf Credential-Dateien durch unautorisierte Prozesse, Token-Widerrufsverfahren mit unternehmensweiter Reichweite und eine Überprüfung, auf welche Unternehmenssysteme Entwickler-KI-Tool-Zugangsdaten zugreifen können, umfassen. Audit-Trails, die KI-gestützte Datenzugriffe erfassen, sind entscheidend, um festzustellen, auf welche Daten ein Angreifer während des Gefährdungszeitraums tatsächlich zugegriffen hat – die Beweisgrundlage, um zu klären, ob regulierte Daten betroffen waren.
Erfahren Sie mehr darüber, wie Sie Ihre sensiblen Daten vor KI-Lieferkettenangriffen schützen können – vereinbaren Sie noch heute eine individuelle Demo.
Häufig Gestellte Fragen
Der Angreifer leitete gestohlene Zugangsdaten über einen Endpunkt um, der eine Sentry-Fehlerberichts-Integration nachahmte – ein Datenverkehr, der von den meisten Netzwerküberwachungen nicht auffällt. Das Paket funktionierte zudem korrekt, sodass Entwickler keine Auffälligkeiten bemerkten. Pre-Publish-Scans in Paketregistern prüfen auf bekannte bösartige Signaturen, führen aber keine Verhaltenssimulationen durch, die Credential-Zugriffe zur Laufzeit aufdecken würden. Lieferketten-Risikomanagement muss daher auch Verhaltensanalysen installierter Pakete zur Laufzeit umfassen, nicht nur Signaturprüfungen bei der Installation.
Access Tokens laufen nach Minuten oder Stunden ab. Refresh Tokens erzeugen unbegrenzt neue Access Tokens, bis sie explizit widerrufen werden – und die meisten Opfer wissen nichts vom Diebstahl und widerrufen sie daher nie. Zero-trust-Prinzipien begegnen dem durch kontinuierliche kontextbezogene Verifizierung: Tokens, die in anomalen Kontexten verwendet werden, werden auch dann erkannt, wenn sie technisch gültig sind. Die ABAC-Prüfung von Kiteworks wendet diese kontextbezogene Bewertung auf jede Datenzugriffsanfrage an – unabhängig von der Token-Gültigkeit.
Ja. OAuth-Zugangsdaten sollten in plattformverwalteten Keystores gespeichert werden – etwa im macOS-Systemschlüsselbund, Windows Credential Manager oder einem Hardware-Sicherheitsmodul bei Unternehmenseinsatz – und nicht als Klartext-JSON-Dateien im Home-Verzeichnis. Plattform-Keystores verlangen eine explizite Benutzer-Authentifizierung, bevor Zugangsdaten freigegeben werden, wodurch ein stiller Hintergrundzugriff durch bösartige Pakete deutlich erschwert wird. Unternehmen sollten zudem regelmäßig prüfen, welche Entwickler-Tools auf Unternehmens-Zugangsdaten zugreifen können – als Teil ihres Lieferantenrisikomanagements.
Das hängt davon ab, auf welche Unternehmenssysteme diese Zugangsdaten Zugriff gewähren. Autorisieren sie den Zugang zu Dokumenten-Repositories, sicheren Filesharing-Plattformen oder Managed File Transfer-Pipelines, kann ein Angreifer über KI-gestützte Workflows mit diesen Systemen interagieren. Regulierte Daten – etwa HIPAA-geschützte Gesundheitsdaten, DSGVO-relevante personenbezogene Daten oder CUI unter CMMC – sind dann direkt gefährdet. Behandeln Sie kompromittierte KI-Tool-Zugangsdaten mit derselben Dringlichkeit wie kompromittierte privilegierte Anwender-Zugangsdaten.
Kiteworks erzwingt Zugriffskontrollen auf Datenebene, nicht nur bei der Authentifizierung. Der Secure MCP Server steuert, welche KI-Tools zum Zugriff auf Unternehmensdaten berechtigt sind – eine nicht erkannte Tool-Identität erhält keinen Zugriff auf geschützte Inhalte, unabhängig von den präsentierten Zugangsdaten. Das AI Data Gateway und die ABAC-Prüfung bewerten den gesamten Anfragekontext – Identität, Tool, Datenklassifizierung, Umgebung und Verhaltensmuster – sodass ein gestohlenes Token im anomalen Kontext die Richtlinienprüfung nicht besteht, selbst wenn es noch nicht widerrufen wurde. Jede Interaktion erzeugt einen manipulationssicheren Audit-Trail.
Weitere Ressourcen
- Blogbeitrag
Zero‑Trust-Strategien für kosteneffizienten KI-Datenschutz - Blogbeitrag
Wie 77 % der Unternehmen bei der KI-Datensicherheit scheitern - eBook
AI Governance Gap: Warum 91 % der kleinen Unternehmen 2025 beim Datenschutz Russisches Roulette spielen - Blogbeitrag
Für Ihre Daten gibt es kein „–dangerously-skip-permissions“ - Blogbeitrag
Aufsichtsbehörden fragen nicht mehr, ob Sie eine KI-Policy haben. Sie wollen den Nachweis, dass sie funktioniert.