Перейти к содержимому
Новость

LiteLLM 1.107.0 заразили вредоносным кодом: под угрозой ключи от ИИ-сервисов

В популярной библиотеке LiteLLM обнаружили вредоносный код, способный похищать пароли, облачные ключи и данные доступа к ИИ-сервисам. Зараженная версия 1.107.0 распространялась 21 октября через официальный каталог PyPI и образы Docker. Ее уже удалили, но простое обновление не устраняет последствия возможного заражения.

Анатолий В.
LiteLLM 1.107.0 заразили вредоносным кодом: под угрозой ключи от ИИ-сервисов

Автор: Hacker News: Front Page

LiteLLM используют разработчики, которым нужно работать с разными нейросетями через единый интерфейс. Библиотека позволяет подключаться к моделям OpenAI, Anthropic и других поставщиков, а также управлять ключами доступа. Именно поэтому ее компрометация оказалась особенно неприятной: в таких системах часто хранятся данные, которые открывают доступ сразу к нескольким платным сервисам.

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

В результате в каталог PyPI попала версия 1.107.0 с дополнительными вредоносными файлами. Они присутствовали во всех семи готовых пакетах для установки, хотя исходный код официального релиза на GitHub не содержал этих компонентов.

Здесь и скрывалась главная опасность. Разработчик мог проверить исходники, не обнаружить ничего подозрительного, а затем установить уже скомпрометированную сборку.

Вредоносная программа использовала особенности запуска Python. Файлы cook.pth и sitecustomize.py позволяли выполнять посторонний код при запуске интерпретатора, даже если сама библиотека LiteLLM не использовалась в конкретной программе.

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

Второй компонент создавал скрытый фоновый процесс, который периодически проверял внешний источник команд. Такая схема давала возможность загружать и запускать дополнительный код уже после первоначального заражения.

Под угрозой оказались не только установки через pip. Вредоносные компоненты также попали в официальные Docker-образы LiteLLM, включая версии, распространявшиеся под тегами latest, main-latest и main-stable.

По данным разработчиков, зараженные пакеты находились в PyPI с 11:39 до 13:23 UTC 21 октября. Опасные образы в Docker Hub распространялись примерно с 11:46 до 14:20 UTC. После обнаружения атаки их удалили или заменили безопасными сборками.

Однако удаление файлов из каталогов не очищает компьютеры, на которых вредоносный код уже запускался. Если в зараженной среде находились действующие API-ключи, пароли базы данных или облачные учетные данные, они могли попасть к посторонним.

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

Отдельно предупреждается, что начинать очистку обычной командой pip install опасно. Запуск Python в зараженном окружении способен повторно активировать вредоносный код. Для восстановления разработчики рекомендуют использовать заведомо чистую среду и зафиксировать LiteLLM на версии 1.106.2.

Проверить установленную версию можно командой pip show litellm. Среди признаков компрометации также называются файлы cook.pth, cook.py и sitecustomize.py. Но отсутствие этих файлов не гарантирует, что система не подвергалась атаке.

Частные корпоративные сборки LiteLLM, распространявшиеся через отдельный реестр разработчика, согласно официальному сообщению, не пострадали. Для общедоступной версии расследование продолжается. Точное количество зараженных систем пока не установлено.

История с LiteLLM показывает, почему проверка исходного кода не всегда гарантирует безопасность установленной программы. В данном случае опасность скрывалась в готовых пакетах и механизме их выпуска. Если зараженная версия успела запуститься, одного отката программы недостаточно: менять придется и доступные ей секреты.

Источник: Safedep
6 показов