В началото на август изследователите от GitGuardian установиха, че нов вариант на инфостийлър червея Shai-Hulud е еволюирал и вече сканира за идентификационни данни в 469 локации в среди за разработка, инструменти за непрекъсната интеграция и внедряване (CI/CD), облачни конфигурации и дори настройки на AI среди.

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

Веригите за доставка на софтуер винаги са разчитали на доверие.

Разработчиците се доверяват на регистрите с пакети. Организациите се доверяват на поддържащите лица. CI/CD системите се доверяват на предоставените им идентификационни данни и идентичности. Приложенията се доверяват на зависимостите, които изтеглят по време на компилиране.

Киберпрестъпниците са осъзнали, че няма нужда да компрометират това доверие. Трябваше само да намерят къде вече се съхраняват идентификационните данни и постоянните права за достъп.

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

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

Shai-Hulud превръща откраднатите данни в продължителна атака срещу веригата за доставки

Shai-Hulud принадлежи към нарастващ клас атаки срещу веригата за доставки, които търсят компрометирани среди за идентификационни данни, с които да продължат атаката.

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

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

Събирането на данни за достъп осигурява на атакуващите следваща стъпка

Модерните среди за разработка съдържат много повече данни за автентификация от самото хранилище на изходния код. Идентификационните данни се появяват на очаквани места, като .env файлове, история на шела и конфигурации на мениджъри на пакети. Но също така има тайни в CLI кешове, CI/CD конфигурации и настройки на IDE. Все по-често екипите откриват ключове за достъп в конфигурациите, използвани от AI инструменти за разработка.

Ето защо авторите на зловреден код за събиране на данни продължават да разширяват радиуса на търсене. Атакуващият не знае задължително кои данни са най-важни преди събирането им. Той може да събере наличното и след това да анализира какво отключва всеки ключ.

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

Правото за публикуване създава път за разпространение

Данните за публикуване на пакети заслужават специално внимание, тъй като те превръщат кражбата на данни в разпространение на софтуер, пренасяйки атаката напред.

Токените, използвани от разработчиците за публикуване, носят права върху доверен пакет, който други разработчици, системи за компилация и организации автоматично ще консумират. Атакуващите злоупотребяват именно с това доверие. Това създава ясен първостепенен приоритет за екипите по сигурност: да намалят броя на наличните постоянни данни за публикуване, които могат да бъдат откраднати.

Организациите трябва да намалят зависимостта си от дълготрайни токени за публикуване. Трябва да се насърчават всички разработчици на софтуер да приемат краткотрайна, потвърдена автентификация чрез OpenID Connect (OIDC) или подобни механизми с ограничен обхват. Последните актуализации на Docker и GitHub Actions тласнаха екосистемата в тази посока, включително чрез по-строга автентификация и по-широко използване на доверено публикуване.

Всеки останал дълготраен идентификационен дан за публикуване трябва да се третира като високочувствителна инфраструктура.

Идентификационните данни свързват системи, които екипите по сигурност управляват отделно

Екипите по сигурност традиционно разглеждат организациите си според категориите сигурност: сигурност на управлението на изходния код, CI/CD сигурност, облачна сигурност, сигурност на крайните точки и сигурност на приложенията. Идентификационните данни пресичат всички тези разделения и изисквания за разделение на отговорностите. Един разработчик може да се автентифицира в GitHub, npm, AWS, Kubernetes, вътрешни API и инфраструктура за компилация в рамките на един обикновен ден, а CI/CD каналите често носят също толкова разнороден набор от данни.

Идентификационен дан, оставен в средата за разработка, може да представлява права за достъп до съвсем различно място. Файлът може да се намира на лаптоп, докато данните управляват облачен ресурс или предоставят права за публикуване на пакети.

Мястото, където се открива дадена тайна, разкрива само част от цялата картина.