OpenAI Codex-authenticatietokens gestolen bij npm-toeleveringsketenaanval
Risicobeheer toeleveringsketen richtte zich traditioneel op softwareafhankelijkheden die kwetsbaarheden in gecompileerde producten introduceren — het soort compromis dat werd vertegenwoordigd door SolarWinds en XZ Utils. De Codex-token-diefstal is een ander model. Het gecompromitteerde pakket introduceert geen kwetsbaarheid in de code van de ontwikkelaar. Het onttrekt inloggegevens uit de ontwikkelomgeving terwijl de ontwikkelaar werkt.
De levenscyclus van de aanval volgt een voorspelbaar patroon: een functioneel pakket wordt gepubliceerd en krijgt downloads via normale kanalen; het pakket wordt onderhouden en bijgewerkt, waardoor een commitgeschiedenis ontstaat die legitimiteit suggereert; op een gegeven moment wordt code toegevoegd die inloggegevens verzamelt; en omdat het pakket correct functioneert, kijken ontwikkelaars niet nauwkeurig. De exfiltratie draait weken of maanden stilletjes voordat deze wordt ontdekt.
De kwaliteit van de vermomming in het geval van Codex is leerzaam. Gestolen inloggegevens werden naar een server-endpoint gestuurd dat een Sentry-foutmeldingsintegratie nabootste — een dienst die routinematig telemetrie ontvangt van ontwikkeltools. Netwerkmonitoring die uitgaande verbindingen naar onbekende domeinen signaleert, zou een verbinding met wat op Sentry lijkt niet markeren. De aanvaller anticipeerde op en omzeilde het meest voorkomende detectiemechanisme voor uitgaande data-exfiltratie.
Programma’s voor risicobeheer voor verkopers die de beveiligingsstatus van softwareleveranciers beoordelen, moeten hun scope uitbreiden naar de package-ecosystemen waarin deze leveranciers opereren. Een npm-pakket is een leveranciersrelatie zonder dat daar een inkoopproces aan vastzit.
5 Belangrijkste Inzichten
1. Een functioneel npm-pakket stal stilletjes Codex OAuth-tokens gedurende een maand.
“codexui-android” — met circa 29.000 wekelijkse downloads — verzamelde OpenAI Codex-authenticatietokens uit lokale opslag en verstuurde complete OAuth-inlogbundels naar een door de aanvaller beheerde server die vermomd was als een Sentry-endpoint. Dezelfde exfiltratielogica verscheen in twee Android-apps met in totaal meer dan 60.000 downloads. Het pakket voerde zijn geadverteerde functie uit terwijl het verzamelen van inloggegevens op de achtergrond draaide — zonder dat ontwikkelaars enig gedragsmatig signaal kregen dat er iets mis was. Pre-publish scans in de toeleveringsketen detecteren dit patroon niet.
2. Refresh tokens verlopen niet — waardoor deze diefstal uniek hardnekkig is.
Het gestolen ~/.codex/auth.json-bestand bevatte refresh tokens, niet alleen access tokens. Een aanvaller met een refresh token kan het slachtoffer stilletjes voor onbepaalde tijd imiteren, nieuwe access tokens genereren wanneer nodig zonder een herauthenticatie-uitdaging te activeren. De meeste slachtoffers van diefstal van inloggegevens weten niet dat er een diefstal heeft plaatsgevonden en trekken daarom niets in — waardoor continue contextuele verificatie duurzamer is dan tokenverval als controlemaatregel.
3. Opslag van inloggegevens in platte tekst is een systemisch risico in ontwikkeltoolchains.
Elk pakket dat een ontwikkelaar installeert, heeft mogelijk toegang tot alle inloggegevens die in de homedirectory zijn opgeslagen. Ditzelfde patroon komt voor bij cloudprovider-CLI’s, versiebeheersystemen, containerregisters en AI-dienstverleners — die allemaal vaak inloggegevens in platte tekst in lokale bestanden opslaan. Frameworks voor risicobeheer voor verkopers die zijn ontwikkeld voor SaaS-leveranciers, hebben een equivalent framework nodig voor open-source package-afhankelijkheden.
4. Gestolen AI-ontwikkelaarsgegevens kunnen bedrijfsdatasystemen bereiken die ver buiten het werkstation liggen.
Codex-tokens geven toegang tot alle bedrijfsystemen waarmee de ontwikkelaar is verbonden — omgevingen voor bestandsoverdracht, MFT-pijplijnen, contentrepositories en interne API’s. Een aanvaller met geldige ontwikkelaarsgegevens kan met deze systemen communiceren via AI-gemedieerde workflows die volledig normaal lijken voor auditlogs die afwijkend menselijk gedrag bewaken.
5. Zero-trust toegangscontrole beperkt de gevolgen, zelfs als inloggegevens zijn gestolen.
Beleidsvoorwaarden gekoppeld aan gevoelige data — niet alleen de identiteit van de inloggegevens — bepalen of toegang wordt verleend. Zero-trust gegevensbescherming betekent dat een gestolen token, gepresenteerd vanaf een onverwachte locatie, op een ongebruikelijk tijdstip, met een verzoek buiten de normale scope, kan falen voor beleidsevaluatie, zelfs als het token technisch geldig is. De Kiteworks Secure MCP Server creëert het knelpunt dat tokens onder controle van een aanvaller niet kunnen omzeilen.
Je vertrouwt erop dat je organisatie veilig is. Maar kun je het bewijzen?
Lees nu
Waarom opslag van inloggegevens in platte tekst een systemisch risico is
Het ~/.codex/auth.json-bestand slaat OAuth-inloggegevens op in platte tekst omdat dit de weg van de minste weerstand is voor ontwikkeltools. Ontwikkelaars willen dat hun tools zonder wrijving kunnen authenticeren. Inlogbestanden op het lokale bestandssysteem, leesbaar door elk proces dat de ontwikkelaar uitvoert, lossen dat probleem efficiënt op — maar creëren tegelijkertijd een enkel faalpunt: elk proces met leesrechten op het bestandssysteem kan alles verzamelen wat nodig is om het account te imiteren.
Dit probleem is niet uniek voor Codex. Ditzelfde patroon komt voor in ontwikkeltoolchains — cloudprovider-CLI’s, versiebeheersystemen, containerregisters en AI-dienstverleners slaan allemaal vaak inloggegevens in platte tekst in lokale bestanden op. Beveiligingsteams die zich richten op netwerktoegangscontroles en perimeterverdediging, negeren vaak dit lokale oppervlak van inloggegevens volledig.
Elk pakket dat een ontwikkelaar installeert, heeft mogelijk toegang tot alle inloggegevens die in de homedirectory zijn opgeslagen. Frameworks voor risicobeheer door derden die zijn ontworpen voor SaaS-leveranciers en cloudproviders, hebben een equivalent framework nodig voor open-source package-afhankelijkheden. Inloggegevens in rust moeten dezelfde behandeling krijgen als gevoelige data in rust: encryptie met sleutels die apart van het versleutelde materiaal worden opgeslagen.
Hoe gestolen AI-inloggegevens leiden tot datalekken in ondernemingen
De Codex-token-diefstal is niet alleen een accountcompromis — het is de eerste stap in een keten die kan eindigen met data-exfiltratie op bedrijfsniveau. Een ontwikkelaar installeert een kwaadaardig pakket; het pakket verzamelt Codex-inloggegevens; de aanvaller gebruikt deze gegevens om toegang te krijgen tot alle bedrijfsystemen die het account van de ontwikkelaar kan bereiken; de aanvaller extraheert vervolgens gevoelige inhoud via kanalen die niet te onderscheiden zijn van legitieme activiteiten van de ontwikkelaar.
De bedrijfsdatasystemen met het grootste risico zijn die waar AI-tools steeds vaker op aansluiten: documentrepositories, beveiligde platforms voor bestandsoverdracht, virtuele dataruimten en beheerde bestandsoverdrachtpijplijnen. Deze systemen bevatten contracten, financiële data, intellectueel eigendom en gereguleerde persoonlijke informatie. Een aanvaller met Codex-inloggegevens van een ontwikkelaar kan met deze systemen communiceren via AI-gemedieerde workflows die volledig normaal lijken voor auditlogs die afwijkend menselijk gedrag bewaken.
Kiteworks onderbreekt deze keten op het niveau van data-toegang. De Secure MCP Server bepaalt welke AI-tools überhaupt met bedrijfsdata mogen werken — als de identiteit van een tool of de beleidscontext niet overeenkomt met de toegestane set, kan deze geen toegang krijgen tot de data, ongeacht de gepresenteerde inloggegevens. ABAC-handhaving gaat verder: er wordt niet alleen gekeken wie er vraagt, maar ook welke attributen het verzoek, de data en de context beschrijven. Een gestolen token, gepresenteerd vanaf een onverwachte geografische locatie, op een ongebruikelijk tijdstip, met een verzoek buiten de normale scope van de ontwikkelaar, kan falen voor beleidsevaluatie, zelfs als het token zelf geldig is.
Reageren op supply chain-compromissen in AI-toolchains
Wanneer een diefstal van inloggegevens van dit type plaatsvindt, verloopt de respons via twee parallelle sporen: het direct beperken van de blootstelling en het bouwen van controles die herhaling voorkomen. Directe beperking vereist het intrekken van alle mogelijk gecompromitteerde tokens — elke ontwikkelaar die het getroffen pakket tijdens het blootstellingsvenster heeft geïnstalleerd, moet zijn auth.json-inloggegevens als gecompromitteerd beschouwen. Het intrekken van tokens is in de meeste OAuth-implementaties een handmatige handeling, en organisaties zonder inventaris van welke ontwikkelaars welke service-inloggegevens hebben, zullen moeite hebben om dit volledig uit te voeren.
Een incident response plan voor AI-toolchain-compromissen moet geautomatiseerde detectie van toegang tot inlogbestanden door ongeautoriseerde processen omvatten, procedures voor het intrekken van tokens met een scope over de hele onderneming, en een review van welke bedrijfsystemen AI-tool-inloggegevens van ontwikkelaars kunnen bereiken. Auditlogs die AI-gemedieerde data-toegang vastleggen zijn essentieel om te bepalen waartoe een aanvaller daadwerkelijk toegang heeft gehad tijdens het blootstellingsvenster — de bewijsbasis die bepaalt of gereguleerde data betrokken was.
Wil je meer weten over het beschermen van je gevoelige data tegen AI-aanvallen in de toeleveringsketen? Plan vandaag nog een persoonlijke demo.
Veelgestelde vragen
De aanvaller leidde gestolen inloggegevens om via een endpoint dat een Sentry-foutmeldingsintegratie nabootste — verkeer dat door de meeste netwerkmonitoring niet wordt gemarkeerd. Het pakket functioneerde daarnaast correct, waardoor ontwikkelaars geen gedragsmatig signaal kregen. Pre-publish registry-scans controleren op bekende kwaadaardige handtekeningen, maar voeren geen gedragsimulatie uit die toegang tot inloggegevens tijdens runtime zou onthullen. Beheersmaatregelen voor risico’s in de toeleveringsketen moeten runtime-gedragsanalyse van geïnstalleerde pakketten omvatten, niet alleen handtekeningcontroles bij installatie.
Access tokens verlopen na minuten of uren. Refresh tokens genereren onbeperkt nieuwe access tokens totdat ze expliciet worden ingetrokken — en de meeste slachtoffers weten niet dat er een diefstal heeft plaatsgevonden en trekken ze daarom nooit in. Zero-trust-principes pakken dit aan via continue contextuele verificatie: tokens die in afwijkende contexten worden gebruikt, worden gemarkeerd, zelfs als ze technisch geldig zijn. De ABAC-handhaving van Kiteworks past deze contextuele evaluatie toe op elk data-accessverzoek, onafhankelijk van de geldigheid van het token.
Ja. OAuth-inloggegevens moeten worden opgeslagen in platformbeheerde keystores — macOS-systeemkeychain, Windows Credential Manager of een hardwarebeveiligingsmodule voor bedrijfsinzet — en niet in platte tekst JSON-bestanden in de homedirectory. Platform-keystores vereisen expliciete gebruikersauthenticatie voordat inloggegevens worden vrijgegeven, waardoor stille achtergrondtoegang door een kwaadaardig pakket aanzienlijk moeilijker wordt. Organisaties moeten ook periodiek controleren welke ontwikkeltools toegang hebben tot bedrijfsinloggegevens als onderdeel van hun programma voor risicobeheer voor verkopers.
Dat hangt af van welke bedrijfsystemen deze inloggegevens kunnen bereiken. Als ze toegang geven tot documentrepositories, beveiligde platforms voor bestandsoverdracht of MFT-pijplijnen, kan een aanvaller via AI-gemedieerde workflows met die systemen communiceren. Gereguleerde data — HIPAA-beschermde PHI, GDPR-gedekte persoonsgegevens, CUI onder CMMC — wordt direct blootgesteld. Behandel gecompromitteerde AI-tool-inloggegevens met dezelfde urgentie als gecompromitteerde bevoorrechte gebruikersgegevens.
Kiteworks handhaaft toegangsbeleid op het dataniveau, niet alleen bij authenticatie. De Secure MCP Server bepaalt welke AI-tools gemachtigd zijn om met bedrijfsdata te werken — een niet-herkende toolidentiteit krijgt geen toegang tot beschermde inhoud, ongeacht de gepresenteerde inloggegevens. De AI Data Gateway en ABAC-handhaving evalueren de volledige context van het verzoek — identiteit, tool, dataclassificatie, omgeving en gedragsprofielen — zodat een gestolen token in een afwijkende context faalt voor beleidsevaluatie, zelfs als het nog niet is ingetrokken. Elke interactie levert een fraudebestendig audittrail op.
Aanvullende bronnen
- Blog Post
Zero‑Trust-strategieën voor betaalbare AI-privacybescherming - Blog Post
Hoe 77% van de organisaties faalt in AI-databeveiliging - eBook
AI Governance Gap: Waarom 91% van de kleine bedrijven Russisch roulette speelt met databeveiliging in 2025 - Blog Post
Er bestaat geen “–dangerously-skip-permissions” voor je data - Blog Post
Toezichthouders zijn klaar met vragen of je een AI-beleid hebt. Ze willen bewijs dat het werkt.