Секреты 434 000 CI/CD-пайплайнов утекли из-за взлома LiteLLM
Когда говорят «атака на цепочку поставок», обычно представляют что-то абстрактное. А тут всё очень конкретно: всего за 40 минут злоумышленники утащили секреты из 434 000 CI/CD-пайплайнов по всему миру. Пострадал LiteLLM — популярный прокси-сервер для работы с LLM-API, которым пользуются тысячи разработчиков. Новые данные от CloudSEK и Hudson Rock показали: реальный масштаб случившегося заметно больше, чем казалось в марте.
История началась не с LiteLLM. Ещё в начале марта группировка TeamPCP скомпрометировала расширение Aqua Trivy для VS Code и получила учётные данные с правами записи. Aqua Security взлом обнаружила и провела ротацию секретов, но, как выяснилось позже, неполную — доступ у хакеров сохранился.
19 марта атакующие подменили почти все теги GitHub Actions Trivy и выложили заражённый релиз сканера. Встроенный инфостилер вытаскивал секреты прямо из памяти CI-раннеров: токены GitHub и npm, SSH-ключи, облачные учётные данные. Дальше пошла цепная реакция — Docker Hub, GitHub Actions компании Checkmarx, npm-экосистема. LiteLLM стал одним из звеньев: в PyPI ушли вредоносные версии 1.82.7 и 1.82.8, а малварь внутри них собирала секреты из окружения заражённых систем.
Первые оценки говорили о тысяче скомпрометированных SaaS-сред и примерно 300 Гбайт украденных данных. Сейчас выяснилось, что утечка затронула облачные ключи, токены репозиториев, SSH-ключи, секреты Kubernetes и даже ключи ИИ-провайдеров. По оценке CloudSEK, добытое потенциально открывает доступ к инфраструктуре более чем 2500 организаций — в списке Nvidia, AWS, Samsung, Salesforce, Cisco, Siemens, Airbus, FedEx, Volkswagen и десятки других имён.
Hudson Rock вышли на след инцидента при анализе массива данных объёмом 195 Тбайт. Независимый исследователь Кевин Бомонт подтвердил подлинность части украденного на примере нескольких пострадавших компаний. И тут самое неприятное: часть секретов до сих пор работает. Одна крупная американская техкомпания уверяла Бомонта, что давно сменила все пароли и ключи, — проверка показала обратное.
Бомонт связывает случившееся со слабой защитой DevOps-инфраструктуры и спешкой, с которой компании встраивают ИИ в свои процессы разработки. Всем, кто пользовался LiteLLM 1.82.7 и 1.82.8, стоит считать скомпрометированными любые секреты, доступные из его окружения: отозвать облачные ключи, токены сервисных аккаунтов Kubernetes, GitHub и GitLab PAT, а также проверить логи на подозрительный исходящий трафик.
У нас тоже стоит LiteLLM как прокси для работы с LLM-API, так что новость зацепила. После истории с Trivy теперь хочется пересмотреть, какие секреты вообще лежат в переменных окружения у CI-раннеров.
@Мария, а обычному человеку, который просто хранит свои ключи в переменных окружения, как понять, что они тоже могли утечь? После таких новостей хочется перевыпустить вообще все токены, но непонятно, с чего начинать.
@Ольга, мы начали с перевыпуска токенов GitHub и npm у всех, кто вообще запускал сборки за последние пару месяцев, плюс проверили логи CI на подозрительные запросы во время атаки. Отдельно прошлись по SSH-ключам и облачным креденшелам в переменных окружения раннеров — именно их инфостилер вытаскивал в первую очередь, судя по разбору. На весь аудит ушёл вечер, но зато теперь хотя бы понятно, что именно могло утечь.
@Мария, после этой новости у нас тоже начался пересмотр: ключи из переменных окружения раннеров перенесли в секрет-хранилище, а зависимости в CI закрепили по хешам вместо свежих тегов. Пока полёт нормальный, но осадок остался.
Обратная сторона популярности открытого прокси: тысячи проектов ставят PyPI-версии, не проверяя хеши, и одна подмена тега в Actions перечёркивает месяцы работы над безопасностью. Хорошо, что у Trivy хотя бы подписанные релизы, вопрос только в том, кто их проверяет при установке.
@Игорь, подписанные релизы — это хорошо, но в этой истории теги в Actions подменили целиком, так что и проверка подписи не всегда спасает, если цепочка доверия уже сломана. Вопрос скорее в том, кто из нас реально фиксирует версии и проверяет хеши в CI, а не просто тянет свежий тег — судя по 434 тысячам пострадавших пайплайнов, таких единицы.
Вот и обратная сторона open source: код открыт, но если у проекта украли учётные данные, доверять свежим тегам на GitHub уже нельзя. Показательно, что Aqua провела ротацию секретов, а доступа у хакеров это не отняло — выводы из инцидентов делают далеко не все. После этой истории закрепил в своих проектах зависимости по хешам и проверку подписей релизов, а кто-нибудь уже проверял свои CI-раннеры на предмет утёкших токенов?
Цифра в 434 000 пайплайнов за 40 минут звучит эффектно, но хотелось бы увидеть методику подсчёта: это число затронутых репозиториев или именно утёкших секретов? Плюс непонятно, сколько токенов хакеры реально успели использовать до ротации, а не просто собрали. Без данных CloudSEK о выборке масштаб остаётся оценочным.