27 000 letöltéssel rendelkező npm-csomag észrevétlenül lopott OpenAI tokeneket

Egy codexui-android nevű rosszindulatú npm csomag ismeretlen ideig csendben OpenAI hitelesítési tokeneket lopott el az azt telepítő fejlesztőktől. Hetente körülbelül 27 000 letöltéssel a csomag az OpenAI Codex modelljének legitim felhasználói felületeként tüntette fel magát. A megszokott külső alatt azonban egy titkos hitelesítőadat-gyűjtő művelet futott, amelyet a biztonsági kutatók ma már iskolapéldaként emlegetnek, mint az npm ellátási láncot célzó támadást, amely nagy léptékben OpenAI tokenekre utazik.

A felfedezés újabb éles emlékeztető arra, hogy a csomagregiszterek önmagukban nem biztonságosak, és a népszerűség önmagában nem jelenti a megbízhatóságot.

Hogyan rejtette el a codexui-android a tokenlopást egy legitimnek látszó csomagban

A támadás egyszerű, de hatékony megtévesztésre épült: építsenek valamit, amit a fejlesztők valóban használni szeretnének, majd adjanak hozzá olyan rosszindulatú logikát, amely csendben fut a háttérben. A codexui-android csomag működő felületet kínált az OpenAI Codexhez, ami azt jelentette, hogy a fejlesztők telepítették, tesztelték, és a projektjeikben tartották, gyakran anélkül, hogy valaha is megkérdőjelezték volna, mit csinál a csomag a hálózati rétegben.

Ezt a megközelítést trójai csomagos támadásnak nevezik. A rosszindulatú kód egy hasznosnak tűnő eszközbe volt ágyazva, így kikerülve azt a természetes gyanakvást, amelyet egy nyilvánvalóan nem működő vagy gyengén felépített csomag kiváltana. A csomag OpenAI frissítési tokeneket szivárogtatott ki – ezek olyan hosszú élettartamú hitelesítő adatok, amelyek lehetővé teszik az alkalmazások számára, hogy új hozzáférési tokeneket kérjenek anélkül, hogy a felhasználónak újra be kellene jelentkeznie.

A codexui-android név emellett egy olyan elnevezési konvenciót követett, amely legitimnek tűnt. Kölcsönözte az OpenAI Codex termékének márkanevét, és egy platform-specifikus utótaggal egészítette ki, ami egy célorientált, mobilközeli eszköz benyomását keltette. Azoknak a fejlesztőknek, akik Codex-szel kapcsolatos eszközöket kerestek az npm-en, nem lett volna nyilvánvaló okuk a bizalmatlanságra.

Mit tesznek lehetővé a támadók számára az ellopott OpenAI frissítési tokenek

A frissítési tokenek nem csupán jelszavak. Számos hitelesítési rendszerben gyakorlatilag mesterkulcsok. Amikor egy támadó érvényes frissítési tokenhez jut, ismételten új hozzáférési tokeneket generálhat, így tartós hozzáférést tartva fent egy fiókhoz akkor is, amikor az eredeti munkamenet már lejárt, vagy a jelszót megváltoztatták.

OpenAI-fiókok esetében ez a hozzáférés fizetős API-kreditek jogosulatlan használatához, a tárolt promptokhoz vagy finomhangolt modelladatokhoz való hozzáféréshez, az API-n átküldött saját fejlesztésű kód potenciális kiszivárgásához, szervezeti környezetben pedig az ugyanahhoz a fiókhoz kapcsolódó csapat erőforrásokhoz való oldalirányú hozzáféréshez vezethet.

A kockázat fejlesztői környezetben gyorsan továbbgyűrűzik. A mérnökök gyakran dolgoznak emelt jogosultságú API-kulcsokkal és tokenekkel. Egyetlen feltört frissítési token egy CI/CD csővezetékben vagy egy megosztott fejlesztői környezetben olyan tartós hídfőt adhat a támadónak, amelyet nehéz észlelni, és még nehezebb teljesen felszámolni. Ez a láncreakciószerű hatás hasonlít ahhoz, ami a Dropbox Sign adatszivárgás során történt, ahol a megszerzett hitelesítő adatok utat nyitottak az összekapcsolt rendszerek felé, messze túl a kezdeti kompromittálódási ponton.

Miért teszi az npm ökoszisztéma könnyen skálázhatóvá az ellátási lánc támadásokat

Az npm regiszter több mint kétmillió csomagot tárol. Egy új csomag közzététele minimális személyazonosság-ellenőrzést igényel, és a regiszter nyílt jellege pontosan az, ami olyan hasznossá teszi a globális fejlesztői közösség számára. Ez ugyanakkor az, ami miatt visszatérő célpontja az ellátási láncot támadóknak.

A codexui-android eset jól szemlélteti, hogyan használják ki a támadók a nyílt forráskódú fejlesztés alapját képező bizalmi modellt. A fejlesztők általában azt feltételezik, hogy egy jelentős letöltési számmal rendelkező csomagot a közösség valamilyen szintű ellenőrzésnek vetett alá. Ez a feltételezés egyre veszélyesebb. A letöltési számok mesterségesen felfújhatók, a valós használat pedig nem egyenlő a biztonsági átvilágítással.

Az npm ellátási lánc támadások szélesebb problémája nem új, de az MI-eszközök célba vétele fejlődést jelez. Ahogy a fejlesztők nagy nyelvi modellek API-jait integrálják éles rendszerekbe, az ezeket az integrációkat hitelesítő tokenek nagy értékű célpontokká válnak. A támadók egyértelműen tisztában vannak ezzel a váltással. Az MI-fejlesztői eszközöket utánzó csomagok a fenyegetések egy olyan új kategóriáját alkotják, amelynek nagyléptékű kezelésén a biztonsági közösség még mindig dolgozik.

Mélységi védelem fejlesztőknek: hitelesítő adatok elkülönítése, hálózati szegmentálás és azon túl

A codexui-android incidens több olyan konkrét gyakorlatra mutat rá, amelyek csökkenthetik az ilyen támadásoknak való kitettséget.

Hitelesítő adatok elkülönítése a legközvetlenebb ellenlépés. Az API-tokeneket és a frissítési tokeneket a lehető legszűkebb jogosultsági körre kell korlátozni, lehetőleg titokkezelőkben tárolni környezeti változók vagy konfigurációs fájlok helyett, és rendszeresen cserélni őket. Ha egy token ellopják, a korlátozott hatókör korlátozott kárt jelent.

Függőségellenőrzés a fejlesztési munkafolyamat szabványos részét kell, hogy képezze. Az olyan eszközök, mint az npm audit, valamint harmadik féltől származó szoftverösszetétel-elemző platformok jelezhetik a szokatlan viselkedésű vagy ismert sérülékenységű csomagokat. A függőségi verziók zárolása a package-lock fájlokban és a változtatások átvizsgálása a frissítések elfogadása előtt szintén csökkenti a rosszindulatú verziókjuttatások kockázatát.

Kimenő hálózati forgalom figyelése elkaphatja azokat a kiszivárogtatási kísérleteket, amelyeket az audit eszközök kihagynak. Ha a fejlesztői környezet vagy a CI/CD csővezeték úgy van konfigurálva, hogy riasztást adjon váratlan kimenő kapcsolatok esetén, akkor egy ellopott tokenekkel hazatelefonáló csomag észlelhetővé válik.

Legkisebb jogosultság elve minden szinten érvényes. A fejlesztői gépek ne fussanak olyan hitelesítő adatokkal, amelyek éles környezet szintű hozzáférést biztosítanak. A CI/CD csővezetékek inkább futásidőben generált, rövid élettartamú tokeneket használjanak, mint hosszú távon tárolt titkokat.

Végül pedig érdemes most átnézni a saját telepített csomagjainkat, különös tekintettel minden olyanra, ami hitelesítési folyamatokat érint. A codexui-android incidens valószínűleg nem elszigetelt eset. Ellenőrizzük, mi található a node_modules könyvtárban, nézzük meg, milyen jogosultságokkal rendelkeznek az API-tokenjeink, és kezeljünk fokozott figyelemmel minden olyan csomagot, amely hitelesítőadat-tároláshoz nyúl.

Az ellátási lánc támadások azért sikeresek, mert nagy léptékben használják ki a bizalmat. Ennek a biztonsági helyzetnek az újjáépítése egy-egy függőséggel kezdve, a verem legérzékenyebb hitelesítő adataival indítva a legpraktikusabb válasz, ami jelenleg az egyes fejlesztők rendelkezésére áll.