27 000 kertaa ladattu npm-paketti varasti hiljaa OpenAI-tokenit

Haitallinen npm-paketti nimeltä codexui-android vietti tuntemattoman ajan hiljaa varastaen OpenAI-todennustokeneita kehittäjiltä, jotka sen asensivat. Noin 27 000 viikoittaisella latauksella paketti esittäytyi laillisena käyttöliittymänä OpenAI:n Codex-mallille. Tämän tutun ulkokuoren alla suoritettiin peitettyä tunnistetietojen keruuta, jota tietoturvatutkijat pitävät nyt oppikirjaesimerkkinä npm:n toimitusketjuhyökkäyksestä, jonka kohteena olivat OpenAI-tokenit laajassa mittakaavassa.

Havainto on jälleen terävä muistutus siitä, että pakettirekisterit eivät ole luonnostaan turvallisia ja että pelkkä suosio ei ole luotettavuuden mittari.

Kuinka codexui-android piilotti tokenvarkauden laillisen näköisen paketin sisään

Hyökkäys perustui yksinkertaiseen mutta tehokkaaseen huijaukseen: rakennettiin jotain, jota kehittäjät oikeasti haluavat käyttää, ja sitten lisättiin haitallista logiikkaa, joka toimi hiljaa taustalla. codexui-android-paketti tarjosi toimivan käyttöliittymän OpenAI:n Codexille, joten kehittäjät asensivat sen, testasivat ja pitivät sen projekteissaan usein koskaan kyseenalaistamatta, mitä paketti teki verkkotasolla.

Tätä lähestymistapaa kutsutaan troijan pakettihyökkäykseksi. Haitallinen koodi upotettiin hyödylliseltä vaikuttavaan työkaluun, välttäen luonnollista epäluuloa, jonka selvästi toimimaton tai huonosti rakennettu paketti herättäisi. Paketti vei ulos OpenAI-päivitystokeneita, pitkäikäisiä tunnistetietoja, joiden avulla sovellukset voivat pyytää uusia käyttötunnisteita tarvitsematta käyttäjän kirjautua uudelleen.

Nimi codexui-android noudatti myös nimeämiskäytäntöä, joka vihjasi laillisuudesta. Se lainasi brändipääomaa OpenAI:n Codex-tuotteelta ja lisäsi alustakohtaisen päätteen, mikä sai sen vaikuttamaan tarkoitukseen rakennetulta mobiililäheiseltä työkalulta. Kehittäjät, jotka etsivät npm:stä Codex-aiheisia työkaluja, eivät olisi löytäneet ilmeistä syytä epäillä sitä.

Mitä varastetuilla OpenAI-päivitystokeneilla hyökkääjät pystyivät tekemään

Päivitystokenit eivät ole pelkkiä salasanoja. Monissa todennusjärjestelmissä ne ovat käytännössä pääavaimia. Kun hyökkääjä saa haltuunsa kelvollisen päivitystokenin, hän voi tuottaa uusia käyttötokeneita toistuvasti ja pitää jatkuvan pääsyn tiliin, vaikka alkuperäinen istunto olisi päättynyt tai salasana olisi vaihdettu.

OpenAI-tileillä tämä pääsy voi merkitä maksullisten API-krediittien luvatonta käyttöä, tallennettujen kehotteiden tai hienosäädettyjen mallidatan pääsyä, API:n kautta kulkevien oman koodin mahdollista paljastumista ja organisaatiokonteksteissa rinnakkaista pääsyä samalle tilille liitettyihin tiimiresursseihin.

Riski kasvaa nopeasti kehitysympäristöissä. Insinöörit työskentelevät usein API-avaimien ja laajennetut oikeudet omaavien tokenien kanssa. Yksikin vaarantunut päivitystoken CI/CD-putkessa tai jaetussa kehitysympäristössä voisi antaa hyökkääjälle pysyvän jalansijan, jota on vaikea havaita ja vielä vaikeampi korjata kokonaan. Tämä kerrannaisvaikutus muistuttaa tapahtunutta Dropbox Sign -tietoturvaloukkauksessa, jossa kerätyt tunnistetiedot avasivat pääsyn toisiinsa kytkettyihin järjestelmiin paljon alkuperäistä murtoa laajemmin.

Miksi npm-ekosysteemi tekee toimitusketjuhyökkäyksistä helppoja skaalata

Npm-rekisteri isännöi yli kahta miljoonaa pakettia. Uuden paketin julkaiseminen vaatii vain minimaalista henkilöllisyyden vahvistamista, ja rekisterin avoin luonne on juuri se, mikä tekee siitä niin hyödyllisen maailmanlaajuiselle kehittäjäyhteisölle. Se on myös syy siihen, miksi se on toistuva kohde toimitusketjuhyökkääjille.

codexui-android-tapaus osoittaa, kuinka hyökkääjät käyttävät hyväkseen avoimen lähdekoodin kehityksen taustalla olevaa luottamusmallia. Kehittäjät yleensä olettavat, että paljon latauksia saanut paketti on käynyt läpi jonkinasteista yhteisön tarkastelua. Tämä oletus on yhä vaarallisempi. Latausmääriä voidaan paisuttaa keinotekoisesti, eikä todellinen käyttö vastaa tietoturva-arviota.

Laajempi npm:n toimitusketjuhyökkäysten ongelma ei ole uusi, mutta tekoälytyökalujen kohdentaminen merkitsee kehitystä. Kun kehittäjät integroivat suuria kielimallirajapintoja tuotantojärjestelmiin, integraatioita todentavat tokenit muuttuvat arvokkaiksi kohteiksi. Hyökkääjät ovat selvästi tietoisia tästä muutoksesta. Tekoälykehitystyökaluja jäljittelevät paketit ovat kehittyvä uhkaluokka, jota tietoturvayhteisö pyrkii yhä torjumaan laajasti.

Puolustus syvyydessä kehittäjille: tunnistetietojen eristäminen, verkon segmentointi ja muuta

codexui-android-tapaus viittaa useisiin konkreettisiin käytäntöihin, jotka voivat vähentää altistumista tämän tyyppisille hyökkäyksille.

Tunnistetietojen eristäminen on välittömin lievennys. API-tokenit ja päivitystokenit tulee rajata mahdollisimman suppeasti, tallentaa salaisuuksien hallintatyökaluihin ympäristömuuttujien tai konfigurointitiedostojen sijaan ja vaihtaa säännöllisesti. Jos token varastetaan, rajattu käyttöalue tarkoittaa rajattua vahinkoa.

Riippuvuuksien tarkastus tulisi olla vakiintunut osa kehitystyönkulkua. Työkalut kuten npm audit yhdistettynä kolmannen osapuolen ohjelmistokokoonpanoanalyysialustoihin voivat merkitä paketteja, joilla on poikkeavaa käytöstä tai tunnettuja haavoittuvuuksia. Riippuvuuksien versioiden lukitseminen package-lock-tiedostoihin ja muutosten tarkistaminen ennen päivitysten hyväksymistä vähentää myös altistumista haitallisille versiopuskureille.

Lähtevän verkkoliikenteen seuranta voi havaita tietojen ulosvientiyrityksiä, jotka tarkastustyökaluilta jäävät huomaamatta. Jos kehitysympäristö tai CI/CD-putki on konfiguroitu hälyttämään odottamattomista ulosmenevistä yhteyksistä, varastettuja tokeneita kotiin päin soittava paketti tulee havaittavaksi.

Vähimpien oikeuksien periaate pätee jokaisella tasolla. Kehityskoneita ei tule käyttää tunnistetiedoilla, jotka antavat tuotantotason pääsyn. CI/CD-putkien tulisi käyttää lyhytikäisiä, ajonaikaisesti luotuja tokeneita pitkäikäisesti tallennettujen salaisuuksien sijaan.

Lopuksi omien asennettujen pakettien tarkistaminen kaikkea todennukseen liittyvän varalta on nyt vaivan arvoista. codexui-android-tapaus tuskin on yksittäinen. Tarkasta, mitä node_modules-kansiossasi on, tarkista, mitä oikeuksia API-tokenisi kantavat, ja suhtaudu korostetulla epäluulolla mihin tahansa pakettiin, joka koskee tunnistetietojen tallentamista.

Toimitusketjuhyökkäykset onnistuvat, koska ne hyödyntävät luottamusta laajassa mittakaavassa. Tämän tietoturva-asennon uudelleenrakentaminen yksi riippuvuus kerrallaan, aloittaen herkimmistä tunnistetiedoista omassa pinossasi, on käytännöllisin kehittäjien tänään käytettävissä oleva vastaus.