Масштабная атака на LiteLLM: как один pip install слил все ваши секреты

24 марта в репозиторий PyPI были загружены вредоносные версии популярной библиотеки LiteLLM (1.82.7 и 1.82.8). Всего один вызов pip install litellm мог привести к полной компрометации системы пользователя, включая утечку конфиденциальных данных: SSH-ключей, учетных данных AWS/GCP/Azure, файлов kubeconfig, токенов Git, всех переменных окружения (в том числе API-ключей), истории командной оболочки, данных крипто-кошельков, SSL-сертификатов, секретов CI/CD и паролей от баз данных. Об этом инциденте широко писали в СМИ, а пост Андрея Карпатого о нем получил более 62 миллионов просмотров благодаря ретвиту Илона Маска.

Что произошло?

Атака была осуществлена группировкой TeamPCP. Сначала злоумышленники скомпрометировали GitHub Action для Trivy, что позволило им похитить PyPI-токен мейнтейнера LiteLLM. Используя украденный токен, они опубликовали вредоносные версии библиотеки. Механизм заражения был реализован через .pth-файл, который автоматически исполняется при каждом запуске любого процесса Python, даже если сама библиотека LiteLLM не импортируется в коде приложения.

Библиотека LiteLLM имеет около 3,4 миллиона скачиваний в день, что подчеркивает масштаб потенциального заражения. Однако еще более серьезным является тот факт, что LiteLLM может быть транзитивной зависимостью. Это означает, что если ваш проект использует такие библиотеки, как dspy, плагины MCP или другие оркестраторы LLM, которые, в свою очередь, зависят от LiteLLM, то ваша система также находится под угрозой. Во многих случаях пользователи могли даже не подозревать о наличии LiteLLM в своих зависимостях.

Как была обнаружена атака?

Вредоносное ПО содержало ошибку: .pth-файл создавал дочерние процессы, которые при инициализации повторно запускали тот же .pth-файл, что приводило к экспоненциальному росту числа процессов (форк-бомба) и, как следствие, к падению системы из-за исчерпания оперативной памяти. Исследователь из FutureSearch заметил, что его система столкнулась с нехваткой RAM после обновления MCP-плагина в Cursor. Если бы атакующие не допустили эту ошибку, обнаружение вредоносного кода могло бы затянуться на значительно больший срок – дни или даже недели.

Отравленные версии библиотеки находились в PyPI всего около трех часов, но при таком объеме ежедневных скачиваний этого времени было более чем достаточно для распространения заражения.

Что необходимо предпринять?

Немедленно проверьте версию LiteLLM на ваших системах, используя команду:

pip show litellm | grep Version

Если вы обнаружите версии 1.82.7 или 1.82.8, считайте вашу машину полностью скомпрометированной. В этом случае крайне важно выполнить ротацию всех секретов: SSH-ключей, облачных токенов, файлов kubeconfig, API-ключей и паролей к базам данных. Для пользователей Kubernetes рекомендуется также проверить пространство имен kube-system на наличие подозрительных подов, например, с префиксом node-setup-*.

Выводы

Данный инцидент не является единичным случаем. Это третий удар в рамках скоординированной кампании группировки TeamPCP, которая ранее скомпрометировала Trivy, затем Checkmarx KICS, а теперь и LiteLLM.

Атаки на цепочки поставок (supply chain attacks) представляют собой один из самых опасных векторов угроз в современном программном обеспечении. Каждый pip install может потянуть за собой зараженный пакет из глубокого дерева зависимостей. Классическая инженерная мантра «не изобретай велосипед, используй библиотеку» нуждается в переосмыслении. Для повышения безопасности рекомендуется всегда фиксировать версии зависимостей, проверять их контрольные суммы и минимизировать общее количество используемых библиотек.