Повідомлення Slowmist: LiteLLM піддав атасі PyPI, витоку криптовалютних гаманців і API-ключів

Головний фахівець з інформаційної безпеки SlowMist 23pds 25 березня повідомив, що Python-API шлюз LiteLLM, який має понад 97 мільйонів завантажень на місяць, зазнав атаки через ланцюг постачання на платформі PyPI. Вразливі версії 1.82.7 та 1.82.8 були присутні на платформі щонайменше дві години. Зловмисники через впровадження багаторівневого шкідливого коду могли викрасти, зокрема, інформацію про криптовалютні гаманці.

Структурні причини високої цінності цілі у ланцюгу постачання LiteLLM

LiteLLM виконує роль єдиного інтерфейсу у стеку AI-технологій, підтримуючи виклики моделей від провайдерів таких як OpenAI, Anthropic, Google тощо. Його архітектура безпосередньо розміщується між додатками та кількома постачальниками AI-сервісів, що дозволяє отримувати доступ до великої кількості API-ключів, змінних оточення та конфіденційних налаштувань.

Зламати цей проміжний компонент означає, що зловмисники можуть перехоплювати конфіденційні дані, що проходять через нього, без необхідності безпосереднього проникнення до основних сервісів. Наразі фахівці оцінюють, чи пов’язана ця атака з організаціями-угрупованнями TeamPCP та LAPSUS$, розслідування триває. Спершу інцидент був оприлюднений користувачем GitHub, а подальший аналіз проводили зовнішні дослідники Futuresearch.

Механізм роботи трьох рівнів шкідливого навантаження

Вразливі версії містили шкідливий код, побудований за трирівневою архітектурою, реалізованою через обфусцований Python-код у Base64:

Перший рівень (злив даних): збирає конфіденційні дані з локальної системи, шифрує їх алгоритмом AES-256-CBC, потім за допомогою заздалегідь закодованого RSA-публічного ключа шифрує сесійну ключову інформацію, упаковує у файл tpcp.tar.gz і передає на віддалену точку під контролем зловмисників.

Другий рівень (розвідка та збір сертифікатів): перераховує системну інформацію, змінні оточення, систематично витягує SSH-ключі, Git-сертифікати, хмарні сертифікати AWS/GCP/Azure, конфігураційні файли Kubernetes, дані криптовалютних гаманців та налаштування CI/CD. У деяких випадках шкідливий код активує спроби використання викрадених сертифікатів для запитів до AWS API або керування Kubernetes.

Третій рівень (збереження та віддалене управління): записує файл sysmon.py на диск і налаштовує його як системну службу, що кожні 50 хвилин опитує командний центр зловмисників, дозволяючи їм постійно оновлювати шкідливі функції на інфікованих системах.

Зв’язок із цим шкідливим каналом здійснюється через домени models[.]litellm[.]cloud та checkmarx[.]zone.

Рекомендації щодо пом’якшення для постраждалих організацій

Організаціям, які встановлювали або запускали вразливі версії LiteLLM (1.82.7 або 1.82.8), слід вважати свої системи зламаними. Оскільки шкідливий код має здатність до збереження та, ймовірно, вже розгорнув додаткові компоненти, просте видалення пакету недостатньо.

Рекомендується негайно вжити таких заходів: змінити всі потенційно скомпрометовані сертифікати (ключі доступу AWS/GCP/Azure, SSH-ключі, API-ключі); перевірити журнали на наявність підозрілих вихідних з’єднань з доменами models[.]litellm[.]cloud або checkmarx[.]zone; видалити файли tpcp.tar.gz, /tmp/pglog, /tmp/.pg_state та пов’язані з sysmon.py служби; за можливості відновити систему з чистої резервної копії.

Поширені запитання

Які версії LiteLLM постраждали від цієї атаки ланцюга постачання?

Пошкоджені версії — LiteLLM 1.82.7 та 1.82.8. Шкідливий код був вставлений у proxy_server.py (обидві версії) та litellm_init.pth (версія 1.82.8). Рекомендується негайно перевірити використовувану версію та оновити до останньої безпечної.

Які типи конфіденційної інформації можуть бути викрадені цим злом?

Шкідливий код збирає SSH-ключі, сертифікати AWS/GCP/Azure, конфігураційні файли Kubernetes, токени облікових записів сервісів, Git-сертифікати, API-ключі з змінних оточення, історію команд Shell, дані криптовалютних гаманців та паролі до баз даних. Атака охоплює локальне середовище розробки, CI/CD-процеси та хмарну інфраструктуру.

Як визначити, чи система вже зламані?

Перевірте наявність файлів tpcp.tar.gz, /tmp/pglog або /tmp/.pg_state, а також служб, пов’язаних із sysmon.py, що зберігаються у системі. Також проаналізуйте вихідні записи мережевих з’єднань на предмет підозрілої активності з доменами, зазначеними вище.