Отравленный релиз LiteLLM превратил обычную установку Python в крипто-осведомленный похититель секретов, который искал кошельки, материалы валидатора Solana и облачные учетные данные при каждом запуске Python.
24 марта, в промежутке между 10:39 UTC и 16:00 UTC, злоумышленник, получивший доступ к учетной записи сопровождающего, опубликовал две вредоносные версии LiteLLM на PyPI: 1.82.7 и 1.82.8.
LiteLLM позиционирует себя как унифицированный интерфейс для более чем 100 поставщиков больших языковых моделей, что по замыслу помещает его внутрь сред разработчиков, богатых учетными данными. По данным PyPI Stats, только за последний месяц было зафиксировано 96 083 740 загрузок.
Две сборки несли разный уровень риска. Версия 1.82.7 требовала прямого импорта `litellm.proxy` для активации полезной нагрузки, в то время как версия 1.82.8 внедряла файл .pth (`litellm_init.pth`) в установку Python.
Собственная документация Python подтверждает, что исполняемые строки в файлах .pth запускаются при каждом старте Python, поэтому 1.82.8 выполнялся без какого-либо импорта. Любая машина, на которой он был установлен, запускала скомпрометированный код в момент следующего запуска Python.
FutureSearch оценивает количество прямых загрузок в 46 996 за 46 минут, причем на долю 1.82.8 пришлось 32 464 из них.
Кроме того, было подсчитано 2 337 пакетов PyPI, которые зависели от LiteLLM, причем 88% из них допускали скомпрометированный диапазон версий на момент атаки.
На собственной странице инцидента LiteLLM предупреждали, что любому, чье дерево зависимостей подтянуло LiteLLM через незакрепленное транзитивное ограничение в указанное окно, следует считать свою среду потенциально скомпрометированной.
Команда DSPy подтвердила, что у них было ограничение LiteLLM «больше или равно 1.64.0» и предупредила, что свежие установки в этот период могли привести к загрузке отравленных сборок.
Создан для охоты на криптоактивы
Обратный инжиниринг полезной нагрузки, проведенный SafeDep, явно указывает на нацеленность на криптоактивы.
Вредоносное ПО искало файлы конфигурации кошельков Bitcoin и файлы wallet*.dat, каталоги хранилища ключей Ethereum и конфигурационные файлы Solana в каталоге ~/.config/solana.
SafeDep сообщает, что сборщик уделил особое внимание Solana, демонстрируя целенаправленный поиск пар ключей валидатора, ключей учетной записи голосования и каталогов развертывания Anchor.
Документация разработчика Solana устанавливает путь по умолчанию для пары ключей CLI в ~/.config/solana/id.json. Документация валидатора Anza описывает три файла полномочий, центральные для работы валидатора, и заявляет, что кража авторизованного ключа для снятия средств дает злоумышленнику полный контроль над операциями и вознаграждениями валидатора.
Anza также предупреждает, что ключ для снятия средств никогда не должен находиться на самой машине валидатора.
SafeDep сообщает, что полезная нагрузка собирала SSH-ключи, переменные среды, облачные учетные данные и секреты Kubernetes во всех пространствах имен. Обнаружив действительные учетные данные AWS, она запрашивала AWS Secrets Manager и SSM Parameter Store для получения дополнительной информации.
Она также создавала привилегированные поды `node-setup-*` в kube-system и устанавливала постоянство через sysmon.py и юнит systemd.
Для криптокоманд совокупный риск направлен в определенную сторону. Инфостилер, собирающий файл кошелька вместе с паролем, секретом развертывания, токеном CI или учетными данными кластера с того же хоста, может превратить инцидент с учетными данными в слив кошелька, вредоносное развертывание контракта или компрометацию подписи.
Вредоносное ПО собрало именно такую комбинацию артефактов.
| Целевой артефакт | Пример пути / файла | Почему это важно | Потенциальное последствие |
|---|---|---|---|
| Файлы кошелька Bitcoin | wallet*.dat, файлы конфигурации кошелька |
Может раскрыть материалы кошелька | Риск кражи кошелька |
| Хранилища ключей Ethereum | ~/.ethereum/keystore |
Может раскрыть материалы подписи при сопоставлении с другими секретами | Компрометация подписи / злоупотребление развертыванием |
| Пара ключей CLI Solana | ~/.config/solana/id.json |
Путь по умолчанию для ключей разработчика | Раскрытие полномочий кошелька или развертывания |
| Файлы полномочий валидатора Solana | Пара ключей валидатора, ключи учетной записи голосования, авторизованный вывод средств | Центральное значение для операций и вознаграждений валидатора | Компрометация полномочий валидатора |
| Каталоги развертывания Anchor | Файлы развертывания, связанные с Anchor | Может раскрыть секреты рабочего процесса развертывания | Вредоносное развертывание контракта |
| SSH-ключи | ~/.ssh/* |
Открывает доступ к репозиториям, серверам, бастионам | Боковое перемещение |
| Облачные учетные данные | Среда или конфигурация AWS/GCP/Azure | Расширяет доступ за пределы локального хоста | Доступ к хранилищу секретов / захват инфраструктуры |
| Секреты Kubernetes | Сбор секретов в масштабе кластера | Открывает плоскость управления и рабочие нагрузки | Компрометация пространства имен / боковое распространение |
Эта атака является частью более широкой кампании, поскольку в примечании об инциденте LiteLLM связывают компрометацию с более ранним инцидентом Trivy, а Datadog и Snyk описывают LiteLLM как более поздний этап в многодневной цепочке TeamPCP, которая прошла через несколько сред разработчиков, прежде чем достичь PyPI.
Логика нацеливания последовательна на протяжении всей кампании: инфраструктурный инструмент, богатый секретами, обеспечивает более быстрый доступ к материалам, связанным с кошельками.
Потенциальные исходы этого эпизода
Оптимистичный сценарий основан на скорости обнаружения и отсутствии, на данный момент, публично подтвержденных краж криптоактивов.
PyPI заблокировал обе версии примерно в 11:25 UTC 24 марта. LiteLLM удалила вредоносные сборки, сменила учетные данные сопровождающих и привлекла Mandiant. В настоящее время PyPI показывает 1.82.6 как последний доступный релиз.
Если защитники сменили секреты, проверили наличие litellm_init.pth и отнеслись к скомпрометированным хостам как к «сгоревшим» до того, как противники смогли преобразовать эксфильтрованные артефакты в активную эксплуатацию, то ущерб ограничится раскрытием учетных данных.
Инцидент также ускоряет внедрение практик, которые уже набирают обороты. Доверенная публикация PyPI заменяет долгосрочные ручные API-токены на краткосрочную идентификацию на основе OIDC; около 45 000 проектов приняли ее к ноябрю 2025 года.
Инцидент с LiteLLM включал злоупотребление учетными данными для выпуска, что делает случай перехода на новые методы гораздо более убедительным.
Для криптокоманд инцидент создает срочную необходимость в более строгом разделении ролей: полностью офлайн-хранение средств для вывода средств с холодных валидаторов, изолированные подписи для развертывания, краткосрочные облачные учетные данные и заблокированные графы зависимостей.
Быстрое закрепление зависимостей командой DSPy и собственное руководство LiteLLM после инцидента указывают на герметичные сборки как на стандартное средство устранения последствий.
Пессимистичный сценарий зависит от задержки. SafeDep задокументировал полезную нагрузку, которая эксфильтровала секреты, распространялась внутри кластеров Kubernetes и устанавливала постоянство до обнаружения.
Оператор, установивший отравленную зависимость внутри среды сборки или подключенной к кластеру среды 24 марта, может обнаружить полный масштаб этого раскрытия только через несколько недель. Эксфильтрованные ключи API, учетные данные для развертывания и файлы кошельков не истекают при обнаружении. Злоумышленники могут хранить их и действовать позже.
Sonatype оценивает вредоносную доступность как «не менее двух часов»; собственное руководство LiteLLM охватывает установки до 16:00 UTC; а временная метка карантина FutureSearch — 11:25 UTC.
Команды не могут полагаться исключительно на фильтрацию по временным меткам для определения степени своего риска, поскольку эти цифры не дают четкого сигнала о полной безопасности.
Наиболее опасный сценарий в этой категории связан с общими операторскими средами. Криптобиржа, оператор валидатора, команда моста или RPC-провайдер, установившие отравленную транзитивную зависимость внутри среды сборки, подвергли бы риску всю плоскость управления.
Дампы секретов Kubernetes во всех пространствах имен и создание привилегированных подов в пространстве имен kube-system — это инструменты доступа к плоскости управления, предназначенные для бокового перемещения.
Если это боковое перемещение достигло среды, где на доступных машинах присутствовали горячие или полугорячие материалы валидатора, последствия могли варьироваться от кражи отдельных учетных данных до компрометации полномочий валидатора.
Карантин PyPI и реагирование LiteLLM на инцидент закрыли активное окно распространения.
Командам, которые установили или обновили LiteLLM 24 марта, или которые запускали сборки с незакрепленными транзитивными зависимостями, разрешающими 1.82.7 или 1.82.8, следует считать свои среды полностью скомпрометированными.
Некоторые действия включают смену всех секретов, доступных с скомпрометированных машин, аудит на наличие litellm_init.pth, отзыв и перевыпуск облачных учетных данных, а также проверку того, что материалы полномочий валидатора не были доступны с этих хостов.
Инцидент с LiteLLM документирует путь злоумышленника, который точно знал, какие офчейн-файлы искать, имел механизм доставки с десятками миллионов ежемесячных загрузок и создал постоянство до того, как кто-либо извлек сборки из дистрибутива.
Офчейн-механизмы, которые перемещают и защищают криптоактивы, находились прямо в пути поиска полезной нагрузки.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Gino Matos
