«Последствия могут стать межотраслевыми»: LiteLLM взломали через цепочку поставок — что это значит для российских компаний

Хакеры взломали популярную Python-библиотеку LiteLLM через цепочку поставок ПО, внедрив вредоносный код в версию 1.107.0. Зараженная версия распространялась через репозиторий Python-пакетов и образы Docker. Об этом пишет The Hacker News.

В 2025 году с атаками на цепочки поставок ПО столкнулись 35% российских компаний. Россельхозбанк предложил организациям раскрывать подрядчиков государству, чтобы НКЦКИ мог предупреждать «группу риска», однако эксперты объяснили, что подобный механизм половинчатый из-за необязательности решения, сообщал SecPost.

ИБ-компания CrowdStrike, в свою очередь, раскрыла, что технологические компании сталкиваются с атаками на цепочки поставок. Среди других векторов — атаки через учетные записи и открытые компоненты. SecPost выпускал материал об этом.

Исследователи заявили, что злоумышленники действовали через учетные записи трех инженеров на GitHub, предположительно используя украденные токены GitHub CLI OAuth. Одна учетная запись использовалась для запуска релиза проекта, другая же — для его подтверждения. По заверениям специалистов, все токены, участвовавшие в атаке, были аннулированы.

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

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

• litellm-1.107.0-cp310-abi3-macosx_10_12_x86_64.whl
• litellm-1.107.0-cp310-abi3-macosx_11_0_arm64.whl
• litellm-1.107.0-cp310-abi3-manylinux_2_28_aarch64.whl
• litellm-1.107.0-cp310-abi3-manylinux_2_28_x86_64.whl
• litellm-1.107.0-cp310-abi3-musllinux_1_2_aarch64.whl
• litellm-1.107.0-cp310-abi3-musllinux_1_2_x86_64.whl
• litellm-1.107.0-cp310-abi3-win_amd64.whl
• litellm-1.107.0.tar.gz (в компоненте отсутствуют файлы полезной нагрузки, однако присутствует измененный файл pyproject.toml).

Исследователи отметили, что вредоносный релиз содержал два основных компонента: стилер, воровавший данные, и фоновый демон, который каждый час проверял хранилище GitHub и запускал Python-код, который предоставили хакеры.

Демон (daemon) — фоновая программа, которая работает незаметно для пользователя, не имеет графического интерфейса и сама выполняет нужные задачи.

При этом вредонос запускал Python еще до импорта LiteLLM через .pth-файл, который предназначен для автоматического выполнения кода при запуске интерпретатора.

Исследователи объяснили работу вредоноса: файл «cook.pth», содержащий всего одну строчку «import cook», запускал сборщик учетных данных. Такая операция включает в себя сбор облачных токенов, учетных записей разработчиков и закрытых ключей, JSON-файлов с учетными данными для инструментов ИИ, а также данных браузеров, связанных с Chromium и Firefox.

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

Зависимость России от зарубежных open-source пакетов

Руководитель архитектурной практики департамента «Заказная разработка» «Рексофт» Александр Хантеев указал, что российский бизнес широко использует международные открытые компоненты, в том числе и в отечественных продуктах. По мнению эксперта, общая зависимость компаний разных отраслей от зарубежных open-source-пакетов в самом деле существует.

«Масштаб зависимости показал Log4j в 2021 году, когда организациям по всему миру пришлось срочно искать уязвимую библиотеку в своих системах и устанавливать исправления», — объяснил эксперт, ссылаясь на инцидент с уязвимостью в библиотеке Apache Log4j. Хантеев выделил, что уже тогда опасность присутствовала во множестве давно работающих систем.

У вредоносного же обновления, объяснил собеседник, динамика другая: затронуты лишь те, кто получил конкретную зараженную версию. «Последствия тоже могут стать межотраслевыми, особенно при распространении через общего поставщика, но популярность библиотеки сама по себе еще не означает заражения всей ее аудитории», — указал Хантеев.

Аналитик «Инфосистемы Джет» Анастасия Серикова сходится с экспертом во мнении, что российские компании находятся в зависимости от зарубежных пакетов: «Зависимость российских компаний от зарубежных решений с открытым исходным кодом остается высокой. Они используются при разработке программного обеспечения, в облачных сервисах, CI/CD, работе сайтов в интернете и т. д.».

Собеседница SecPost отметила, что многие популярные open-source-решения не имеют конкретного отраслевого разделения, поэтому при компрометации один продукт может создать риск сразу для финтеха, ритейла, промышленности, телекома и IT-сектора. «При этом масштаб ущерба неодинаков: он зависит от внутренних политик и скорости реагирования», — объяснила Серикова.

Другой эксперт, руководитель исследований AppSec Positive Technologies Владимир Кочетков, отметил, что у open source нет границ, поскольку над всеми крупными и популярными компонентами, используемыми повсеместно, трудятся разработчики из многих стран.

«Практически в каждой отрасли есть свои открытые SOTA-решения, многие open-source-проекты используются в операционных системах, их библиотеках и окружении», — объяснил собеседник. Подобные атаки могут затрагивать не просто целые отрасли, а куда более крупные сегменты пользователей.

В пример эксперт привел историю с утилитой XZ Utils, в которую намеренно внедрен бэкдор. По мнению Кочеткова, лишь по счастливой случайности бэкдор не поставил под удар миллионы серверов и десктопов на базе ОС Linux, поскольку утилита использовалась практически во всех ее дистрибутивах.

Эффективность атак на цепочки поставок ПО

Хантеев считает, что подобные атаки давно эффективны, поскольку взлом одного поставщика или популярного компонента открывает дорогу сразу к множеству компаний. «Достаточно вспомнить SolarWinds в 2020 году, когда вредоносный код распространялся через официальные обновления ПО», — указал эксперт.

Сегодня же, по мнению собеседника, ИИ существенно ускоряет поиск уязвимостей и подготовку способов эксплуатации, тем самым снижая трудоемкость атак. «Принцип остается прежним, но возможности злоумышленников растут, а времени на реакцию становится меньше», — подчеркнул Хантеев.

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

Код же, выделила эксперт, может исполняться на этапе установки, сборки или импорта и похищать секреты, ключи, токены и данные доступа. Именно поэтому, объяснила Серикова, защита от подобных атак сегодня строится на принципах DevSecOps.

DevSecOps (Development, Security, Operations) — это подход к созданию программного обеспечения, при котором безопасность проверяется на каждом этапе разработки, а не в самом конце перед выпуском.