Компрометирането на LiteLLM породи безпокойство относно това как доверен софтуерен компонент с изкуствен интелект може да се превърне в точка за проникване в мрежата. Този инцидент с веригата на доставки изложи на риск системи за генериране на софтуер (build системи), облачни профили и изходен код, въпреки че злонамерените версии бяха налични само за около 40 минути.

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

Анализаторите от CloudSEK идентифицираха активността като част от кампания, приписвана на TeamPCP. Техният възстановен набор от данни свързва повече от 2500 организации и 434 000 стартирания на CI/CD конвейери със засегнатия път, но излагането на риск не доказва, че всяка организация е била пробита.

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

В доклад, споделен с Cyber Security News (CSN), CloudSEK посочва, че копираните идентификационни данни могат да останат полезни дълго след премахването на пакета. Инцидентът показва защо дори краткотрайно компрометиране на пакет може да наложи сериозни усилия за реагиране.

Злонамерените версии на LiteLLM бяха публикувани, след като компрометираният компонент на Trivy достигна до средата за изграждане на проекта. Инцидентът носи риска от атаки по веригата на доставки на доверени пакети: една променена зависимост може да достигне до работните среди, преди поддържащите проекта да успеят да реагират.

В рамките на CI/CD среда за изпълнение (runner), злонамереният код за кражба на идентификационни данни е търсил повишени нива на достъп и е проверявал за SSH ключове, облачни идентификационни данни, Kubernetes токени, конфигурационни файлове на средата и тайни в системната памет на процесите.

Той също така се е насочвал към API ключове за големи езикови модели (LLM) и настройки на шлюзове (gateways), създавайки път към свързаните AI системи и ценни чувствителни данни в тези среди.

Изследователите споделят, че данните са били шифровани, преди да бъдат изпратени към дестинация с правописна грешка в името (typosquatted домейн). При неуспешен трансфер, зловредният софтуер е можел да създаде публично хранилище в GitHub профила на жертвата и да качи материалите като ресурс към версия (release asset).

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

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

Екипите трябва да идентифицират инсталациите на засегнатите версии и да изолират свързаните среди за изпълнение, хостове, контейнерни изображения и кешове. Те трябва да подменят (ротират) всички идентификационни данни, достъпни за засегнатия процес, а не само ключовете за LiteLLM или доставчика на модела.

Скорошни инциденти с компрометирани пакети в PyPI показват как токените за облачни услуги, регистри и системи за управление на версиите могат да превърнат инцидент с единичен пакет в по-широк пробив.

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

Търсенето трябва да обхване и периода след премахването, тъй като откраднатият достъп може да бъде използван повторно на по-късен етап. За превенция CloudSEK препоръчва фиксиране на зависимостите и GitHub Actions към проверени хешове, намаляване на жизнения цикъл и обхвата на идентификационните данни, както и използване на идентичност на натоварването (workload identity) вместо статични ключове, където е възможно.

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

Поддържането на опис на AI активите и техните собственици, проследяването на зависимост от трети страни и наблюдението на поведението по време на изграждане на софтуера могат да намалят слепите петна. Урокът отразява скорошната кампания със скрити вратички (backdoors) в CI средите: доверената автоматизация е ценна за защитниците, но също така и за атакуващите.

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