npm-pakke med 27.000 downloads stjal lydløst OpenAI-tokens
Et ondsindet npm-pakke kaldet codexui-android brugte en ukendt periode på i stilhed at stjæle OpenAI-godkendelsestokens fra de udviklere, der installerede den. Med omkring 27.000 ugentlige downloads udgav pakken sig for at være en legitim brugergrænseflade til OpenAIs Codex-model. Under den velkendte overflade kørte den en skjult høstning af legitimationsoplysninger, som sikkerhedsforskere nu klassificerer som et skoleeksempel på et npm-forsyningskædeangreb, der er målrettet OpenAI-tokens i stor skala.
Opdagelsen er endnu en skarp påmindelse om, at pakkeregistre ikke er iboende sikre, og at popularitet alene ikke er nogen indikator for troværdighed.
Sådan skjulte codexui-android token-tyveri i en tilsyneladende legitim pakke
Angrebet var baseret på et enkelt men effektivt bedrag: Byg noget, udviklere faktisk ønsker at bruge, og tilføj derefter ondsindet logik, der kører i stilhed i baggrunden. Pakken codexui-android tilbød en funktionel grænseflade til OpenAIs Codex, hvilket betød, at udviklere installerede den, testede den og beholdt den i deres projekter – ofte uden nogensinde at stille spørgsmålstegn ved, hvad pakken foretog sig på netværkslaget.
Denne tilgang kaldes et trojaniseret pakkeangreb. Den ondsindede kode var indlejret i det, der lignede et nyttigt værktøj, og omgik den naturlige skepsis, som en åbenlyst ikke-funktionel eller dårligt bygget pakke ville invitere til. Pakken eksfiltrerede OpenAI-refresh-tokens – de langlivede legitimationsoplysninger, der gør det muligt for applikationer at anmode om nye adgangstokens uden at brugeren skal logge ind igen.
Navnet codexui-android fulgte også en navngivningskonvention, der antydede legitimitet. Det lånte mærkeværdi fra OpenAIs Codex-produkt og tilføjede et platformspecifikt suffiks, der fik det til at ligne et specialbygget værktøj tæt på mobiludvikling. Udviklere, der søgte på npm efter Codex-relaterede værktøjer, havde ingen indlysende grund til at mistro det.
Hvad stjålne OpenAI-refresh-tokens faktisk giver angribere mulighed for
Refresh-tokens er ikke bare adgangskoder. I mange godkendelsessystemer fungerer de reelt som hovednøgler. Når en angriber får fat i et gyldigt refresh-token, kan de generere nye adgangstokens igen og igen og dermed opretholde vedvarende adgang til en konto, selv efter at den oprindelige session er afsluttet, eller en adgangskode er blevet ændret.
For OpenAI-konti kan denne adgang betyde uautoriseret brug af betalte API-kreditter, adgang til gemte prompter eller finjusterede modeldata, mulig eksponering af proprietær kode sendt gennem API’en og i organisatoriske sammenhænge lateral adgang til teamressourcer knyttet til den samme konto.
Risikoen forstærkes hurtigt i udviklermiljøer. Ingeniører arbejder ofte med API-nøgler og tokens, der har udvidede tilladelser. Et enkelt kompromitteret refresh-token i en CI/CD-pipeline eller et delt udviklingsmiljø kan give en angriber et vedvarende fodfæste, der er svært at opdage og endnu sværere at afhjælpe fuldt ud. Denne dominoeffekt spejler det, der skete i Dropbox Sign-sikkerhedsbruddet, hvor høstede legitimationsoplysninger åbnede veje til sammenkoblede systemer langt ud over det oprindelige kompromitteringspunkt.
Hvorfor npm-økosystemet gør forsyningskædeangreb lette at skalere
npm-registret rummer over to millioner pakker. At udgive en ny pakke kræver minimal identitetsbekræftelse, og registrets åbne karakter er netop det, der gør det så nyttigt for det globale udviklerfællesskab. Det er også det, der gør det til et tilbagevendende mål for forsyningskædeangribere.
Sagen om codexui-android viser, hvordan angribere udnytter den tillidsmodel, der understøtter open source-udvikling. Udviklere antager generelt, at en pakke med et betydeligt antal downloads har overlevet en vis grad af gennemsyn fra fællesskabets side. Denne antagelse er i stigende grad farlig. Download-tal kan pustes op kunstigt, og faktisk brug er ikke lig med sikkerhedsgennemsyn.
Det bredere problem med npm-forsyningskædeangreb er ikke nyt, men målretningen af AI-værktøjer markerer en udvikling. Efterhånden som udviklere integrerer API'er til store sprogmodeller i produktionssystemer, bliver de tokens, der autentificerer disse integrationer, mål af høj værdi. Angribere er tydeligvis opmærksomme på dette skifte. Pakker, der efterligner AI-udviklingsværktøjer, er en ny kategori af trusler, som sikkerhedsfællesskabet stadig arbejder på at imødegå i stor skala.
Forsvar i dybden for udviklere: Isolering af legitimationsoplysninger, netværkssegmentering og mere
Hændelsen med codexui-android peger på flere konkrete praksisser, der kan reducere eksponeringen for denne type angreb.
Isolering af legitimationsoplysninger er den mest umiddelbare afbødning. API-tokens og refresh-tokens bør have så snævert et scope som muligt, opbevares i secret managers frem for miljøvariabler eller konfigurationsfiler og roteres regelmæssigt. Hvis et token bliver stjålet, betyder et begrænset scope en begrænset skade.
Afhængighedsrevision bør være en standarddel af enhver udviklingsarbejdsgang. Værktøjer som npm audit sammen med tredjepartsplatforme til softwarekompositionsanalyse kan markere pakker med usædvanlig adfærd eller kendte sårbarheder. Låsning af afhængighedsversioner i package-lock-filer og gennemsyn af ændringer, før opdateringer accepteres, reducerer også eksponeringen for ondsindede versionsopdateringer.
Overvågning af netværksudgående trafik kan fange eksfiltreringsforsøg, som revisionsværktøjer overser. Hvis et udviklingsmiljø eller en CI/CD-pipeline er konfigureret til at advare om uventede udgående forbindelser, kan en pakke, der forsøger at kontakte sit hjem med stjålne tokens, blive opdaget.
Princippet om mindste privilegium gælder på alle niveauer. Udviklingsmaskiner bør ikke køre med legitimationsoplysninger, der giver adgang på produktionsniveau. CI/CD-pipelines bør bruge kortlivede tokens genereret på kørselstidspunktet i stedet for gemte, langsigtede hemmeligheder.
Endelig er det lige nu en god idé at gennemgå dine egne installerede pakker for alt, der berører autentificeringsflows. Hændelsen med codexui-android er næppe en isoleret hændelse. Gennemgå, hvad der ligger i din node_modules, tjek hvilke tilladelser dine API-tokens bærer, og behandl enhver pakke, der kommer i kontakt med opbevaring af legitimationsoplysninger, med skærpet opmærksomhed.
Forsyningskædeangreb lykkes, fordi de udnytter tillid i stor skala. At genopbygge den sikkerhedsposition én afhængighed ad gangen – begyndende med de mest følsomme legitimationsoplysninger i din stak – er det mest praktiske svar, der er tilgængeligt for den enkelte udvikler i dag.
