Компрометация LiteLLM в PyPI угрожает облачным и Kubernetes-средам

24 марта 2023 года вредоносный злоумышленник TeamPCP опубликовал в репозитории PyPI две скомпрометированные версии Python-пакета LiteLLM — 1.82.7 и 1.82.8. По данным отчета, этот пакет используется для управления API-ключами нескольких крупных cloud providers и ежемесячно загружался примерно 97 million раз, что сделало инцидент особенно масштабным.

Исследование показывает, что уязвимость цепочки поставки могла затронуть десятки тысяч доступных из Internet развертываний. В ходе сканирования было обнаружено 33 688 подключенных к Internet инсталляций LiteLLM, причем наибольшему риску подвергались deployments, размещенные в cloud.

Как была организована атака

Вредоносный код был встроен в установочный процесс пакета и запускался через запутанную строку кода с использованием payload в base64. Активация происходила в subprocess через команду Popen в Python, что позволяло выполнять вредоносную операцию без заметного прерывания обычной команды pip.

После установки malware проводило широкую reconnaissance-активность и собирало критически важные сведения о системе, в том числе:

• host information;
• user privileges;
• network configuration.

Какие данные пытались похитить

По данным отчета, вредоносное ПО было нацелено на сбор конфиденциальных credentials более чем по 15 категориям. Среди них:

• SSH keys;
• cloud configurations;
• Kubernetes tokens;
• database connection strings.

В средах AWS malware также использовало Instance Metadata Service (IMDS) для получения credentials IAM role, что создавало дополнительные риски компрометации облачных ресурсов.

Риск эскалации до полного контроля над Kubernetes

Отдельно в отчете подчеркивается, что атака могла развиваться от компрометации одного Kubernetes module до фактического захвата всего cluster. Для этого злоумышленники извлекали secrets из всех namespaces и развертывали privileged pods на каждом node, что позволяло поставить под угрозу всю инфраструктуру.

Иначе говоря, изначально ограниченная компрометация одного компонента могла перерасти в полный контроль над кластером.

Командная инфраструктура и persistence

Операция поддерживалась через systemd service, которая опрашивала домен checkmarx.zone каждые 50 минут. Для управления использовались сразу две платформы command-and-control:

• AdaptixC2 — для управления скомпрометированными host через web interface;
• Havoc C2 — для более глубокого lateral movement внутри внутренних сетей.

По данным расследования, оба C2 server были размещены стратегически: один в Luxembourg по адресу 83.142.209.11, другой в Netherlands по адресу 45.148.10.212. Третий IP-адрес — 46.151.182.203 — был идентифицирован как exfiltration relay, связанный с доменными моделями litellm.cloud. Такая схема обеспечивала operational redundancy и усложняла противодействие атаке.

Что рекомендуют организациям

Авторы отчета советуют организациям немедленно проверить признаки заражения, включая конкретные файлы, связанные с persistence malware. Если установка LiteLLM выполнялась с использованием скомпрометированных версий, рекомендуется выполнить полную ротацию credentials, включая:

• all available cloud service tokens;
• private keys;
• any potential API keys.

Дополнительно организациям следует:

• усилить access control;
• включить IMDSv2 с ограничением в один hop для EC2 instances;
• регулярно проверять Kubernetes clusters на наличие unauthorized pods.

Вывод

Инцидент с LiteLLM наглядно демонстрирует, насколько опасными могут быть атаки на supply chain. По оценке отчета, действия TeamPCP указывают на сложную и устойчивую угрозу, способную затрагивать как отдельные applications, так и всю cloud and Kubernetes infrastructure. В таких условиях организациям необходима не реактивная, а proactive security posture.

Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.

Ознакомиться подробнее с отчетом можно по ссылке.