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

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

Пътят на атаката първоначално е започнал с компрометиране на инструмента за сканиране Trivy, използван в процеса на компилация на LiteLLM.

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

Анализаторите от HudsonRock идентифицираха 153 GB архив, свързан с кампанията, съдържащ 433 909 файла и 118 829 дъмпа от CI runner-и, свързани с 2488 корпоративни домейна.

HudsonRock заяви в доклад, споделен с Cyber Security News (CSN), че материалът сочи към сериозно излагане на тайни по време на компилация, а не към доказателство, че всяка посочена организация е претърпяла завършено проникване.

Мащабът е от значение, тъй като средите за изпълнение на CI/CD (CI/CD runners) често съхраняват мощни, краткотрайни или дълготрайни идентификационни данни.

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

Докладваният 40-минутен прозорец подчертава скоростта на автоматизираната злоупотреба с веригата за доставки.

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

Ето защо по-ранната атака срещу веригата за доставки на LiteLLM заслужава подновено внимание.

Възстановените записи включват AWS идентификационни данни, GitLab идентичности, Azure тайни, API токени, конфигурационни файлове и ключове за AI услуги.

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

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

Атаката не е трябвало да се насочва към всяка компания една по една. Тя е злоупотребила с доверието в споделен инструмент за разработчици – модел, описан и в отразяването на инцидента с компрометирания скенер Trivy.

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

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

Засегнатите екипи трябва да потвърдят излагането на риск чрез собствените си регистрационни файлове, историята на runner-ите и облачните одитни записи.

Какво трябва да направят екипите по сигурност сега

Организациите, които са използвали версии на LiteLLM 1.82.7 или 1.82.8, или са изпълнявали засегнатите инструменти в съответния период, трябва да третират всяка тайна, достъпна за тези среди за изпълнение, като потенциално компрометирана.

Първият приоритет е ротацията: заменете облачните ключове за достъп, токените за хранилища, SSH ключовете, идентификационните данни за подписване, Kubernetes токените и ключовете за AI доставчици, след което анулирайте старите стойности.

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

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

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

Фиксирането на зависимостите към проверени версии или коммит хешове също може да направи неоторизираната замяна по-лесна за забелязване.

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

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

Тази дисциплина може да ограничи щетите от следващото компрометиране на доверен инструмент.