Атака на открытый ИИ-шлюз LiteLLM привела к утечке данных тысяч компаний по всему миру

LiteLLM

В 2026 году зафиксирована одна из самых масштабных атак на цепочку поставок в области искусственного интеллекта. Злоумышленники из группировки TeamPCP скомпрометировали популярный открытый программный шлюз LiteLLM, который многие компании используют для организации доступа к большим языковым моделям. В результате атаки злоумышленники получили доступ к внутренним данным тысяч организаций по всему миру, включая крупнейшие корпорации.

Атака началась не с самого LiteLLM. Сначала злоумышленники взломали конвейер разработки, связанный с Trivy - широко распространённым инструментом для поиска уязвимостей в открытом коде. Разработчики LiteLLM использовали Trivy в собственном процессе сборки, поэтому скомпрометированный инструмент получил легитимный доступ к их среде. Это позволило атакующим похитить ключи публикации пакетов LiteLLM. Используя эти данные, TeamPCP выпустила вредоносные версии пакета под номерами 1.82.7 и 1.82.8.

Вредоносный код был устроен так, что активировался при запуске интерпретатора Python независимо от того, использовал ли разработчик библиотеку LiteLLM напрямую. Далее начиналась многоступенчатая атака: вредоносное ПО собирало переменные окружения, локальные конфигурационные файлы, включая учётные данные для облачных сервисов и Kubernetes, а также пыталось перемещаться внутри инфраструктуры и закрепляться в ней.

Компания Hudson Rock, которая специализируется на анализе утечек, получила и проанализировала архив похищенных данных объёмом 153 гигабайта. Как показало исследование Hudson Rock, в архиве содержится 433 909 файлов, среди которых удалось выделить 118 829 дампов сред выполнения, относящихся к 2 488 корпоративным доменам. Каждый дамп представляет собой снимок памяти и конфигурации системы в момент выполнения вредоносного кода. Среди пострадавших оказались такие компании, как Amazon Web Services, Samsung, Cisco, Salesforce, ServiceNow, Siemens, John Deere, Deloitte, Epic Games, Orange, TomTom и BT Group.

Характер утечки вызывает особую тревогу из-за чувствительности данных. В похищенных файлах содержатся действующие пароли баз данных, ключи доступа к облачным платформам AWS, Azure и Google Cloud, а также токены внутренних сервисов, включая Slack, Salesforce и другие корпоративные инструменты. Кроме того, утечка затронула ключи доступа к API для работы с большими языковыми моделями, что даёт злоумышленникам возможность напрямую использовать инфраструктуру жертв и расходовать их квоты на вычисления.

Значительная часть похищенных данных не позволяет однозначно определить принадлежность к конкретной организации. Многие конвейеры разработки настроены универсально, без привязки к корпоративному домену или имени сотрудника. В таких файлах содержатся только технические параметры - адреса серверов, учётные данные и ключи. Это означает, что десятки тысяч компаний могут даже не подозревать о том, что их секреты уже находятся в руках злоумышленников. Для атрибуции необходимо анализировать инфраструктурные признаки, такие как адреса внутренних систем, а не только адреса электронной почты. Например, один из дампов содержал адрес разработчика из домена SiriusXM, однако анализ инфраструктуры показал, что реальной целью стала дочерняя компания AdsWizz.

Масштаб атаки подтверждается и другими исследователями. Независимый анализ утечки, проведённый компанией CloudSEK, ранее также указывал на огромное количество затронутых организаций. Данные Hudson Rock подтверждают эти выводы и дополняют их детальной разбивкой по компаниям. Для оказания помощи пострадавшим Hudson Rock интегрировал полный набор похищенных данных в свою платформу киберразведки Cavalier. Организации могут проверить, затронула ли их утечка, с помощью специального инструмента. После подтверждения инцидента они получают доступ к своим конкретным данным для проведения расследования.

Для компаний, использующих LiteLLM или аналогичные открытые решения в области искусственного интеллекта, первоочередной задачей является проверка версий пакета. Если обнаружены версии 1.82.7 или 1.82.8, необходимо немедленно считать все ключи доступа скомпрометированными. Специалисты рекомендуют ротацию всех учётных записей облачных провайдеров, токенов сервисов и ключей доступа к Kubernetes. Также следует провести аудит журналов операций в облачных средах начиная с 24 марта 2026 года и проверить системы на наличие посторонних файлов автозапуска и подозрительных служб, которые могут быть установлены злоумышленниками для сохранения доступа.

Эта атака демонстрирует, как компрометация одного элемента цепочки поставок - даже такого, как инструмент для проверки безопасности, - может привести к каскадному распространению вредоносного кода и утечке критически важных данных из множества независимых организаций. Ответственность за безопасность ложится на все звенья: от разработчиков библиотек до конечных потребителей, которые должны внимательно относиться к происхождению используемого программного обеспечения и регулярно пересматривать свои механизмы доступа к облачным сервисам и системам разработки.

Комментарии: 0