npm пакет с 27 000 изтегляния безшумно крадеше OpenAI токени

Зловреден npm пакет на име codexui-android прекара неизвестен период, тихомълком крадейки OpenAI токени за удостоверяване от разработчиците, които го инсталираха. С приблизително 27 000 седмични изтегляния, пакетът се представяше като легитимен потребителски интерфейс за модела Codex на OpenAI. Под тази позната външност обаче се извършваше скрита операция по събиране на идентификационни данни, която специалистите по сигурност вече класифицират като учебникарска атака по веригата на доставки в npm, насочена мащабно към OpenAI токени.

Откритието е поредното остро напомняне, че хранилищата на пакети не са безопасни по подразбиране и че популярността сама по себе си не е показател за надеждност.

Как codexui-android скри кражбата на токени в легитимно изглеждащ пакет

Атаката разчиташе на проста, но ефективна заблуда: създай нещо, което разработчиците наистина искат да използват, и добави зловредна логика, която работи тихо във фонов режим. Пакетът codexui-android предлагаше функционален интерфейс за Codex на OpenAI, което означаваше, че разработчиците го инсталираха, тестваха и запазваха в проектите си, често без изобщо да се запитат какво прави пакетът на мрежово ниво.

Този подход е известен като атака с троянизиран пакет. Зловредният код беше вграден в привидно полезен инструмент, заобикаляйки естествения скептицизъм, който би предизвикал един очевидно нефункционален или зле изграден пакет. Пакетът източваше OpenAI refresh токени – дълготрайните идентификационни данни, които позволяват на приложенията да заявяват нови токени за достъп, без да изискват от потребителя да влиза отново.

Името codexui-android също следваше конвенция за именуване, която внушаваше легитимност. То заимстваше брандовия капитал от продукта Codex на OpenAI и добавяше специфичен за платформа суфикс, който го караше да изглежда като целенасочено създаден инструмент, близък до мобилната среда. Разработчиците, търсещи в npm инструменти, свързани с Codex, нямаха очевидна причина да не му се доверят.

Какво всъщност позволяват на нападателите откраднатите OpenAI refresh токени

Refresh токените не са просто пароли. В много системи за удостоверяване те на практика са главни ключове. Когато нападател се сдобие с валиден refresh токен, той може да генерира нови токени за достъп многократно, поддържайки постоянен достъп до акаунт дори след като оригиналната сесия е приключила или паролата е била сменена.

За OpenAI акаунти този достъп може да се изрази в неоторизирано използване на платени API кредити, достъп до запазени подкани или данни от фино настроени модели, потенциално разкриване на проприетарен код, предаден през API, а в организационен контекст – страничен достъп до екипни ресурси, свързани със същия акаунт.

Рискът нараства бързо в средите на разработчиците. Инженерите често работят с API ключове и токени, които имат повишени права. Един-единствен компрометиран refresh токен в CI/CD pipeline или споделена среда за разработка би могъл да даде на нападателя устойчива опорна точка, която е трудна за откриване и още по-трудна за пълно отстраняване. Този каскаден ефект напомня на случилото се при пробива в Dropbox Sign, където събраните идентификационни данни отвориха пътища към взаимосвързани системи далеч отвъд първоначалната точка на компрометиране.

Защо npm екосистемата улеснява мащабирането на атаки по веригата на доставки

npm регистърът хоства над два милиона пакета. Публикуването на нов пакет изисква минимална проверка на самоличността, а отвореният характер на регистъра е точно това, което го прави толкова полезен за глобалната общност от разработчици. Същият този характер го превръща и в повтаряща се мишена за атакуващи по веригата на доставки.

Случаят с codexui-android демонстрира как нападателите експлоатират модела на доверие, на който се крепи разработката с отворен код. Разработчиците обикновено приемат, че пакет със значителен брой изтегляния е преминал известно ниво на обществен контрол. Това предположение става все по-опасно. Броят на изтеглянията може да бъде изкуствено надут, а реалната употреба не означава преглед на сигурността.

По-широкият проблем с атаките по веригата на доставки в npm не е нов, но насочването към AI инструменти бележи еволюция. С навлизането на API за големи езикови модели в производствени системи, токените, които удостоверяват тези интеграции, се превръщат в цели с висока стойност. Нападателите очевидно са наясно с тази промяна. Пакетите, имитиращи инструменти за AI разработчици, са нововъзникваща категория заплахи, срещу която общността по сигурност все още работи, за да противодейства в мащаб.

Задълбочена защита за разработчиците: изолация на идентификационните данни, мрежово сегментиране и отвъд тях

Инцидентът с codexui-android сочи към няколко конкретни практики, които могат да намалят излагането на този клас атаки.

Изолация на идентификационните данни е най-непосредственото противодействие. API токените и refresh токените трябва да бъдат с възможно най-ограничен обхват, да се съхраняват в мениджъри на тайни вместо в променливи на средата или конфигурационни файлове и да се подновяват редовно. Ако даден токен бъде откраднат, ограниченият обхват означава ограничени щети.

Одит на зависимостите трябва да бъде стандартна част от всеки работен процес на разработка. Инструменти като npm audit, както и външни платформи за анализ на софтуерния състав, могат да маркират пакети с необичайно поведение или известни уязвимости. Заключването на версиите на зависимостите в package-lock файловете и преглеждането на промените преди приемане на актуализации също намалява излагането на злонамерени промени.

Наблюдение на изходящия мрежов трафик може да улови опити за източване, които инструментите за одит пропускат. Ако средата за разработка или CI/CD pipeline е конфигурирана да сигнализира за неочаквани изходящи връзки, пакет, който се опитва да предаде откраднати токени, става откриваем.

Принципът на най-малките привилегии важи на всяко ниво. Машините за разработка не трябва да работят с идентификационни данни, които предоставят достъп от производствено ниво. CI/CD pipelines трябва да използват краткотрайни токени, генерирани по време на изпълнение, вместо дългосрочно съхранявани тайни.

И накрая, прегледът на собствените ви инсталирани пакети за всичко, което се докосва до потоците за удостоверяване, е полезно упражнение точно сега. Инцидентът с codexui-android едва ли е изолиран. Одитирайте какво има в node_modules, проверете какви права имат вашите API токени и третирайте всеки пакет, който работи с хранилища за идентификационни данни, с повишено внимание.

Атаките по веригата на доставки успяват, защото експлоатират доверието в мащаб. Преизграждането на тази позиция по сигурност зависимост по зависимост, започвайки с най-чувствителните идентификационни данни във вашия стек, е най-практичният отговор, достъпен за отделните разработчици днес.