LIMB
Вход Регистрация

тема

[Перевод] Уязвимости MCP-серверов

lisa99 · · 1 ответов · 492 просмотров

Сейчас 2 часа ночи. Знаете ли вы, с какими ИИ общается ваш MCP-сервер?​


КогдаAnthropic выпустил протокол контекста модели (MCP)в конце 2024 года, это ощущалось как недостающий элемент головоломки дляинструментов ИИ: стандартный способ для больших языковых моделей (LLM)взаимодействовать с источниками данных,API и практически всем, что вы можете себе представить. 


Не удалось прогрузить медиа

Так ИИ выполнил указание нарисовать схему уязвимостей MCP "в Русалке" 
(сервис mermaid, поленилась переключить регистр+легкий троллинг)

​

Но, как и в случае с большинством блестящих новых стандартов, дьявол кроется в деталях. Особенно в тех строках документации, которые все склонны упускать из виду в спешке, чтобы просто заставить все работать (бывало, без осуждения!). И когда эти детали включают «необязательную авторизацию», все может быстро стать интересным. Эта маленькая оговорка может оставлять тысячи MCP-серверов полностью открытыми для любого, кто знает, где искать.

Это история о том, как мы охотились за открытыми MCP-серверами в интернете и обнаружили сотни, которые не только сообщают незнакомцу, к каким инструментам и данным они подключены, но и с готовностью отвечают на любой ваш вопрос. И когда у этих незнакомцев есть злонамеренные намерения и они точно знают, что делать, найдя эти серверы, последствия могут быть очень серьезными, как мы увидим через минуту.

Примечание: для простоты, когда мы говорим об «открытых MCP-серверах», мы имеем в виду серверы, которые не только доступны через интернет  но и  не имеют никакой формы авторизации.

Отказ от ответственности: Не поймите нас неправильно:  MCP — это потрясающе. Это мощный протокол, который уже меняет то, как ИИ-приложения подключаются к внешним источникам данных и инструментам. Наша цель здесь — просто повысить осведомленность сообщества о чем-то фундаментальном для обслуживания MCP-серверов. Настолько фундаментальном, что это идет задолго до более эффектных угроз эпохи ИИ, таких как инъекция промптов или что-либо из  OWASP Top 10 для LLM-приложений.

Внутри MCP: от обмена сообщениями до реальных чудес​


Представленный в конце 2024 года, MCP быстро стал значительным достижением в экосистеме ИИ. Его обещание стандартизированного метода подключения LLM к инструментам, API и базам данных вызвало значительные дискуссии.
официальное определение  описывает MCP следующим образом:
MCP (Model Context Protocol) — это стандарт с открытым исходным кодом для подключения ИИ-приложений к внешним системам.
Используя MCP, ИИ-приложения, такие как Claude или ChatGPT, могут подключаться к источникам данных (например, локальным файлам, базам данных), инструментам (например, поисковым системам, калькуляторам) и рабочим процессам (например, специализированным промптам), что позволяет им получать доступ к ключевой информации и выполнять задачи.

Думайте об MCP как о порте USB-C для ИИ-приложений. Точно так же, как USB-C предоставляет стандартизированный способ подключения электронных устройств, MCP предоставляет стандартизированный способ подключения ИИ-приложений к внешним системам.
Другими словами, MCP представляет собой стандартизированный интерфейс, который абстрагирует сложность отдельных источников данных. Вместо того чтобы каждое ИИ-приложение нуждалось в реализации пользовательской логики для каждой новой базы данных, API или репозитория знаний, им нужно только понять, как общаться через MCP.

Некоторые основополагающие концепции MCP​

Прежде чем двигаться дальше, давайте разберем несколько ключевых компонентов протокола MCP.

Основные участники: MCP Host, MCP Client и MCP Server​

MCP Хост — это ИИ-приложение или среда выполнения, где выполняются задачи, управляемые ИИ. Он также служит оператором MCP Клиент, который действует как посредник между хостом и одним или несколькими MCP Серверы.

Не удалось прогрузить медиа


Архитектура MCP (источник по состоянию на декабрь 2025 г.)

Эти серверы позволяют клиенту получать доступ к внешним службам и выполнять задачи, предоставляя три ключевых примитива: инструменты, ресурсы, и подсказки. Здесь мы сосредоточимся на инструментах, которые являются исполняемыми функциями, которые ИИ-приложение может вызывать для выполнения действий, например, выполнение файловой операции, вызов API или запрос к базе данных. Если вы хотите изучить ресурсы, подсказки или любую другую часть протокола MCP, мы настоятельно рекомендуем ознакомиться с официальной документацией MCP. Обещаем, это не будет скучно. Мы там были и получили настоящее удовольствие!

Рукопожатие протокола​

Ключевым первым шагом в установлении соединения клиента и сервера MCP является рукопожатие. В ходе этого процесса клиент и сервер согласовывают совместимую версию протокола для обеспечения бесперебойной связи. После инициализации соединения клиент может запросить у сервера список инструментов, ресурсов и подсказок, а затем многократно вызывать их по своему усмотрению. Следующая диаграмма иллюстрирует этот поток связи:

Не удалось прогрузить медиа


Рукопожатие MCP (источник по состоянию на декабрь 2025 г.)

Как клиенты и серверы MCP общаются друг с другом​

Спецификация MCP определяет уровень данных и описывает, как клиенты и серверы MCP общаются с использованием JSON-RPC 2.0 стандарта. Далее описывается уровень транспорта и механизмы обмена сообщениями между двумя сторонами:

Stdio​

Этот метод использует стандартные потоки ввода (stdin) и вывода (stdout) для прямого обмена данными между локальными процессами на одной машине. Весь обмен данными между клиентами и серверами MCP происходит локально.

Потоковый HTTP​

Этот тип транспорта обеспечивает удаленное взаимодействие между клиентами и серверами MCP с использованием метода HTTP POST для сообщений от клиента к серверу, с необязательным конечным узлом События, отправляемые сервером (SSE) для потоковой передачи данных. В этой конфигурации клиент MCP отправляет запросы через HTTP POST, а сервер может ответить либо одним JSON-сообщением, либо непрерывным потоком сообщений, доставляемых со временем через SSE.

Вы можете попробовать это сами, чтобы увидеть, как это работает. Для простоты мы будем использовать фиктивный сервер MCP для демонстрационных целей: Сервер MCP «Everything»1.

Его можно легко запустить с помощью одной команды npx :

Не удалось прогрузить медиа


Запуск сервера MCP «Everything» для быстрой демонстрации с использованием потокового HTTP в качестве типа транспорта

Теперь у вас будет конечный узел /mcp готов к приему POST-запросов. Вы можете использовать curl для отправки сообщения инициализация , которое является первым сообщением в рукопожатии MCP, которое мы видели ранее:

Не удалось прогрузить медиа


Отправка сообщения инициализация нашему демонстрационному серверу MCP с использованием StreamableHTTP в качестве типа транспорта

(Устаревший) HTTP с SSE​

Первоначальная спецификация MCP представила HTTP с SSE в качестве типа транспорта. Он полагался на два отдельных HTTP-соединения: одно для Server-Sent Events (сообщения от сервера к клиенту) и другой стандартный конечный узел POST для связи от клиента к серверу. Этот подход теперь устарел, а потоковый HTTP является предпочтительным вариантом для новых реализаций, когда сервер MCP доступен удаленно и stdio не может использоваться.

Мы можем использовать тот же фиктивный сервер MCP, что и раньше, чтобы увидеть, как работают эти два отдельных HTTP-соединения. Мы начнем с запуска сервера MCP «Everything» в режиме SSE:

Не удалось прогрузить медиа


Снова запускаем сервер MCP «Everything», на этот раз используя SSE в качестве типа транспорта

Здесь, в отличие от того, что мы видели ранее, нам сначала нужно отправить GET-запрос на /sse конечная точка для получения URL сессии:

Не удалось прогрузить медиа


Получение URL сессии для последующих взаимодействий по протоколу

Вы заметите, что ваша curl команда зависает. Это потому, что это не обычная HTTP конечная точка, а SSE конечная точка, которая остается открытой, ожидая поступления новых событий. Теперь то же самое инициализировать сообщение, которое мы видели ранее, должно быть отправлено на конечную точку, которую вы только что получили. Когда вы это сделаете, вы увидите, что ответ — это просто HTTP 202 Принято без возвращаемого полезного груза:

Не удалось прогрузить медиа


Отправка инициализировать сообщения через текущий URL сессии

Фактические данные с сервера доставляются через ранее открытое SSE соединение:

Не удалось прогрузить медиа


Получение ответа на наше инициализировать сообщение в ранее открытом потоке событий SSE


Как это работает в реальной жизни?​



Мы знаем, мы знаем. Вы совершенно правы. Это было довольно низкоуровнево, и большинству пользователей эти детали неинтересны. Но мы подумали, что было бы здорово заглянуть под капот и посмотреть, что на самом деле происходит, когда вы используете MCP.

Конечно, существует несколько SDK , которые вы можете использовать сразу для обработки всего этого взаимодействия. И если вы предпочитаете, или если вы не занимаетесь разработкой, вы можете использовать любое существующее приложение на основе LLM, которое уже поддерживает MCP.

Здесь, в этой демонстрации, мы будем использовать Gemini CLI в качестве нашего MCP хоста/клиента и DBHub в качестве нашего MCP сервера. DBHub называет себя «универсальный MCP сервер баз данных, подключающийся к MySQL, PostgreSQL, SQL Server, MariaDB», так что это отличный способ показать, как MCP позволяет приложению ИИ напрямую взаимодействовать с базой данных.

Мы начнем с запуска MCP сервера DBHub с флагом --demo (“Режим демонстрации включает в себя пакетную SQLite базу данных "employee" с таблицами для сотрудников, отделов, зарплат и т. д.». Мы также будем использовать флаг --transport для его предоставления через Streamable HTTP:

Не удалось прогрузить медиа


Запуск нашего демонстрационного MCP сервера DBHub

Теперь все, что нужно, — это настроить Gemini CLI для указания на наш MCP сервер, и все!

Не удалось прогрузить медиа


Наш файл настроек Gemini CLI

Если вы теперь выполните команду /mcp в вашем Gemini CLI, вы увидите, что один MCP сервер подключен, предоставляя как инструменты, так и промпты. Как упоминалось ранее, это означает, что MCP хост (в данном случае Gemini CLI) выполнил всю тяжелую работу, выполнив полный рукопожатие MCP и обмен сообщениями между клиентом и сервером, чтобы вам не пришлось этого делать. Теперь вы готовы начать задавать вопросы своей базе данных на обычном естественном языке!

Не удалось прогрузить медиа


Подтверждение подключения к нашему демонстрационному MCP серверу

Давайте посмотрим, к каким таблицам у нас есть доступ, а затем выведем одну из них для более детального изучения.

Не удалось прогрузить медиа


Запрос списка таблиц, к которым у нас может быть доступ
(и обратите внимание, что в промпте нет упоминания нашего MCP сервера, потому что в этом нет необходимости)

Не удалось прогрузить медиа


MCP сервер успешно выводит таблицу сотрудники для нас


И это всё? Правда?​


Да, это все! Наше приложение ИИ теперь подключено к MCP серверу по адресу http://localhost:8080/message, готовое использовать инструменты, которые оно анонсировало во время рукопожатия, которое мы исследовали ранее. Почему вы спрашиваете? Думаете, чего-то не хватает?
Не удалось прогрузить медиа



Вы, читая это и понимая, что чего-то не хватает: Авторизация!

Ах, да… рад, что вы спросили! (А если нет, просто сделайте вид, что спросили). Итак, мы открыли наш демонстрационный MCP-сервер через HTTP-эндпоинт, к которому могли удаленно подключаться несколько клиентов (даже несмотря на то, что наша демонстрация работала локально). В чем подвох? Мы не добавили никакого механизма авторизации. Это звучит… ну, мягко говоря, немного опасно.

К этому моменту мы надеемся, что привлекли ваше внимание к остальной части этой статьи в блоге.

Согласно спецификации MCP…​


Давайте посмотрим, что говорит последняя спецификация MCP об авторизации:

Авторизация является НЕОБЯЗАТЕЛЬНОЙ для реализаций MCP. (...) Реализации, использующие транспорт на основе HTTP, ДОЛЖНЫ соответствовать этой спецификации

Хорошо, так вот в чем суть: спецификация MCP не требует использования механизмов авторизации для доступа к MCP-серверам. Она просто рекомендует разработчикам следовать руководству спецификации (которое, кстати, является OAuth 2.1), но в конечном итоге, владелец каждого MCP-сервера сам решает, будет ли (и как) реализовывать авторизацию. И многие просто не делают этого.

Этот необязательный механизм авторизации, оставленный на усмотрение владельца MCP-сервера, — именно то, на чем мы хотели сделать акцент. MCP — это все еще очень новая технология, и все спешат протестировать ее, поиграть с ней и внедрить в своих организациях. Но эта спешка с запуском чего-либо в продакшене может иметь катастрофические последствия. Особенно если разработчик (как тот, кем мы притворялись в нашей предыдущей демонстрации) упустит эту важную деталь, или если «кодер-энтузиаст», создающий свой следующий стартап за миллиард долларов, увидит, что его приложение на базе ИИ «просто работает» с MCP-сервером, который открыт для всего мира, совершенно не подозревая, что его помощник по кодированию только что выставил его в интернет.

Самое важное сообщение этого поста​


Хотя Anthropic является автором спецификации MCP, их задача не в том, чтобы контролировать, как каждый сервер обрабатывает авторизацию. Спецификация предлагает руководство, а не гарантии. Поэтому, если вы планируете внедрить MCP-сервер в своей организации, независимо от того, создаете ли вы его с нуля или используете существующий (а их существует множество ), имейте в виду, что:

Поскольку авторизация необязательна, ее легко пропустить при переходе от демонстрации к реальному развертыванию, что может привести к раскрытию конфиденциальных инструментов или данных.​
​
Многие MCP-серверы разработаны для локального использования, но как только сервер будет открыт через HTTP, поверхность атаки резко возрастет. Именно тогда «необязательная» авторизация становится реальной проблемой. Доверенный периметр, на который вы рассчитывали, больше не действует.​
​
Надеемся, теперь ясно, что открытие MCP-сервера в интернете без какого-либо механизма авторизации перед ним — это, по сути, открытое приглашение для злоумышленников использовать его в качестве прокси для доступа к любым данным или службам, которые предоставляют его инструменты.

Представьте, что вы тщательно настроили свою базу данных, файловую систему, API-сервис или любой другой ресурс, который вы подключили как инструмент к своему MCP-серверу, следуя всем возможным лучшим практикам безопасности. Вы уверены, что только ваш MCP-сервер может получить доступ к этим источникам данных, и вы спокойно ложитесь спать. Но если этот MCP-сервер открыт в интернете, любой может использовать его для проникновения в те самые службы, которые вы считали защищенными.Злонамеренные возможности безграничны:

  • Если вы открываете базы данных или файловые системы, эта информация может быть легко извлечена (как мы сделали в нашей предыдущей демонстрации) или даже изменена, если разрешен доступ на запись.
  • Если ваши инструменты используют сторонние API для доступа к другим службам, любой, кто эксплуатирует ваш открытый MCP-сервер, может получить такой же доступ и привилегии.

  • Если это платный API-сервис, злоумышленник может бесплатно использовать ваш открытый MCP-сервер (и ваш ценный API-ключ), а платить придется вам.
  • Если кто-то просто хочет посеять хаос, он может инициировать атаку типа «отказ в обслуживании», отправляя миллионы запросов через ваш MCP-сервер, исчерпывая ресурсы до тех пор, пока поставщик полностью не заблокирует ваш API-ключ.
​
Существует так много вещей, которые могут пойти не так, что мы могли бы потратить весь день на перечисление сценариев, но вы, вероятно, уже поняли суть. А суть такова: если вы экспериментируете с MCP-серверами или думаете о размещении собственного, легко увлечься шумихой вокруг новых векторов атак ИИ, таких как инъекции подсказок (prompt injection) и других модных эксплойтов, и в процессе попыток защититься от всех них вы просто забываете об основах. Итак, не выставляйте свой MCP-сервер в интернет без очень веской причины. А если вы это сделаете, убедитесь, что он защищен надлежащим механизмом авторизации..

Но если вы из тех, кто должен увидеть, чтобы поверить, оставайтесь с нами, потому что мы отправились на поиски открытых MCP-серверов без установленной авторизации, и то, что мы нашли, было весьма тревожным. Обещаем, примеры ниже привлекут ваше внимание.

​

Наши поиски незащищенных серверов MCP​


Полезная нагрузка для обнаружения​

Теоретически это должно быть просто и ничем не отличаться от обнаружения любой другой службы в дикой природе. Нам просто нужно отправить полезную нагрузку на заданную цель и проанализировать ответ. Если он соответствует ожидаемому шаблону, это попадание в яблочко.

Мы уже разобрали протокол MCP, поэтому не должно быть сюрпризом, какой будет наша полезная нагрузка для обнаружения. Конечно, это сообщение инициализировать . И поскольку мы также точно знаем, как выглядит допустимый ответ, если мы получим его обратно, мы можем быть на 100% уверены, что нашли открытый MCP-сервер, который успешно инициализировал соединение от клиента, даже не проверяя авторизацию.

Code:
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
   "protocolVersion": "2024-11-05",
   "capabilities": {
     "roots": {
       "listChanged": : True
     },
     "sampling": {},
     "elicitation": {}
   },
   "clientInfo": {
     "name": "ExampleClient",
     "title": "Example Client Display Name",
     "version": "1.0.0"
   }
}
}
Code:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
   "protocolVersion": "2024-11-05",
   "capabilities": {
     "logging": {},
     "prompts": {
       "listChanged": True
     },
     "resources": {
       "subscribe": True,
       "listChanged": True
     },
     "tools": {
       "listChanged": True
     }
   },
   "serverInfo": {
     "name": "ExampleServer",
     "title": "Example Server Display Name",
     "version": "1.0.0"
   },
   "instructions": "Optional instructions for the client"
}
}
Наше сообщение инициализировать выглядит так:Ожидаемый ответ имеет структуру, подобную этой.


Где искать открытые MCP-серверы?​

Теперь пришло время определить область нашего поиска. Вот что мы знаем, и это поможет сузить наш сканирование:

  • Мы не можем обнаруживать MCP-серверы, использующие транспортный тип Stdio, поскольку они недоступны удаленно.
  • MCP-серверы, доступные через Streamable HTTP или HTTP с SSE, по своей сути являются HTTP-конечными точками.
Итак, пока все идет хорошо. Мы уже описали данные, которые необходимо отправить в качестве полезной нагрузки для обнаружения, и мы знаем, что их нужно отправлять на HTTP-основанные конечные точки. Однако на практике существует несколько проблем, которые следует учитывать при нацеливании на масштабируемое обнаружение.

Тестирование всех HTTP-основанных конечных точек непрактично.​

Bitsight Groma, наш движок интернет-сканирования, идентифицирует миллионы уникальных HTTP-основанных конечных точек в интернете. Общее текущее количество составляет сотни миллионов, поэтому, хотя мы могли бы протестировать их все, это заняло бы значительное количество времени.

Чтобы сделать этот поиск эффективным, нам нужно составить сфокусированный список потенциальных конечных точек, которые с большей вероятностью будут размещать сервер MCP. Таким образом, мы протестируем лишь небольшую часть всех конечных точек на основе HTTP, превратив это в гораздо более целенаправленное сканирование.

Мы потратили немало времени на изучение наиболее распространенных характеристик серверов MCP, как с механизмами авторизации, так и без них. В общих чертах, вот некоторые из наиболее перспективных сигналов, которые могут помочь нам сосредоточиться на определенных конечных точках на основе HTTP при поиске открытых серверов MCP, безопасно игнорируя другие:

“Хостнеймы, «похожие на MCP»​

Этот пункт довольно очевиден. Если посмотреть на текущую ситуацию, вы заметите, что многие компании предлагают своим клиентам удаленно доступные серверы MCP, чтобы им не приходилось обслуживать их на стороне клиента. Вот несколько случайных примеров:

  • “Stripe размещает потоковый HTTP-сервер MCP, доступный по адресу https://mcp.stripe.com« (источник)
  • “Другие программы (...) могут подключаться вручную, используя Notion общедоступный URL MCP (https://mcp.notion.com/mcp) в качестве пользовательского подключения» (источник)
  • “Подключается напрямую к Figma размещенной конечной точке по адресу https://mcp.figma.com/mcp» (источник)
  • “PayPal создал сервер MCP, который позволяет продавцам использовать естественный язык с их любимыми клиентами MCP (...) В производственной среде для действующего сайта замените URL-адрес песочницы на следующий URL: https://mcp.paypal.com/sse» (источник)
Есть закономерность, не так ли? Похоже, что поддомен mcp в полном доменном имени (FQDN) является сильным индикатором того, что он, вероятно, размещает сервер MCP. К счастью для нас в Bitsight, довольно легко собрать большое количество хостнеймов с mcp в качестве поддомена, поскольку мы активно собираем миллионы общедоступных разрешимых доменов для различных целей, одной из которых является масштабное сканирование на основе хостнеймов.

Подсказки в HTTP-заголовках​

Те, кто живет в тени и редко виден конечным пользователям, HTTP-заголовки иногда раскрывают важную информацию. В этом случае мы можем взглянуть на некоторые из них, включая (но не ограничиваясь):

  • Тип содержимого заголовок: довольно очевидное место для поиска. Как мы узнали, MCP работает либо с необработанным JSON, либо встроенным в HTTP-поток, поэтому application/json и text/event-stream являются хорошими подсказками для поиска в этом заголовке.
  • Заголовок Server: Хотя его можно легко скрыть или изменить, этот заголовок по-прежнему является полезным местом для поиска подсказок, когда раскрывается исходное значение. Предполагая (и мы считаем, что это безопасное предположение), что большинство серверов MCP полагаются на официальные SDK и руководства по реализации Anthropic, мы можем начать выводить, какие веб-серверы наиболее вероятно используются при создании сервера MCP с использованием Python, TypeScript, Go или любого другого существующего SDK.
  • Заголовки Cross-Origin Resource Sharing (CORS): Мы также заметили, что некоторые заголовки Access-Control-* иногда могут раскрывать информацию, обычно связанную с серверами MCP.

Легкодоступные варианты обнаружения конечных точек MCP​

Как мы уже видели, конечные точки MCP обычно находятся по адресу /mcp или /sse, следуя соглашениям, определенным в спецификации. Однако, как и в случае с любым другим соглашением, ничто не мешает кому-либо разместить свой сервер MCP /in/a/deeply/nested/URL/path: классический ход «безопасность через неясность». Поэтому нам также нужно сузить URL-адреса для тестирования.

Для этого исследования мы ограничили себя стандартными (/mcp и /sse), а также протестировали корневой каталог (/), поскольку есть большая вероятность, что они будут самыми «сочными» и дадут наибольшее количество результатов.

Перемотаем вперед к результатам сканирования​



Итак, мы составили список потенциальных URL-адресов, которые могли бы раскрывать MCP-сервер. В итоге мы получили набор целей, демонстрирующих один или несколько сигналов, которые мы определили как индикаторы MCP-сервера, и протестировали их все по трем стандартным путям: /mcp, /sse, и /.

Конечно, по пути мы столкнулись с несколькими ложными срабатываниями, но в итоге отфильтровали их. Для оставшихся целей мы создали простой инструмент для выполнения полного рукопожатия MCP и сбора всех нужных нам данных с каждого раскрытого MCP-сервера: самое главное — список инструментов, но мы также собрали список ресурсов, запросов и некоторые дополнительные метаданные из инициализировать ответа.

Лично для меня это было увлекательное путешествие, но мы избавим вас от скучных подробностей и сразу перейдем к результатам.

И количество обнаруженных нами раскрытых MCP-серверов составляет…​

Примерно 1000 раскрытых MCP-серверов без какой-либо авторизации, с которых мы смогли получить все доступные инструменты.

На первый взгляд, это может показаться не впечатляющим числом, верно? Но подумайте: мы говорим о технологии, которая была анонсирована публике чуть меньше года назад, а мы уже видим сотни экземпляров без какой-либо формы авторизации. Это говорит о том, что со временем ситуация может ухудшиться, поэтому мы надеемся, что этот пост поможет повысить осведомленность до того, как это произойдет.

Важно также рассмотреть другой аспект. Найденные нами MCP-серверы — это те, которые доступны в общедоступном Интернете, но может быть гораздо больше серверов, работающих во внутренних сетях или серверных частях приложений в тех же условиях, и их владельцы могут даже не осознавать этого. То, что они доступны только внутри сети, не означает, что они безвредны. Раскрытый MCP-сервер в корпоративной среде все еще может быть использован злонамеренным инсайдером или путем бокового перемещения во время взлома.

Некоторые тревожные примеры, показывающие, почему это действительно плохо​

Конечно, вам любопытно, какие типы раскрытых MCP-серверов мы обнаружили и что они могли бы позволить злоумышленнику сделать. Нам тоже было любопытно. Именно поэтому мы проанализировали многие из них, изучив инструменты, которые нам разрешили перечислить, и предположив, что можно было бы сделать, если бы мы были настоящими злоумышленниками.

Хотя некоторые MCP-серверы открыты и бесплатны для использования по законным причинам (например, мы нашли несколько, которые просто позволяют приложениям ИИ получать доступ к общедоступной документации для определенного сервиса или продукта), многие другие вызывали гораздо больше опасений. Вот лишь несколько примеров инструментов, реализованных этими раскрытыми MCP-серверами (действительно, всего несколько; мы нашли слишком много!):


Code:
{
   "name": "pods_delete",
   "description": "Delete a Kubernetes Pod in the current or provided namespace with the provided name"
}, {
   "name": "pods_exec",
   "description": "Execute a command in a Kubernetes Pod in the current or provided namespace with the provided name and command"
}, {
   "name": "pods_get",
   "description": "Get a Kubernetes Pod in the current or provided namespace with the provided name"
}, {
   "name": "pods_list",
   "description": "List all the Kubernetes pods in the current cluster from all namespaces"
}, {
   "name": "pods_list_in_namespace",
   "description": "List all the Kubernetes pods in the specified namespace in the current cluster"
}, {
   "name": "pods_log",
   "description": "Get the logs of a Kubernetes Pod in the current or provided namespace with the provided name"
}, {
   "name": "pods_run",
   "description": "Run a Kubernetes Pod in the current or provided namespace with the provided container image and optional name"
}

Раскрытый MCP-сервер, который позволил бы управлять кластером Kubernetes и его подами.
Другой позволил бы получить доступ к инструменту управления взаимоотношениями с клиентами (CRM):

Code:
{
   "name": "list_accounts",
   "description": "Retrieve all available accounts from EspoCRM"
}, {
   "name": "list_users",
   "description": "Retrieve all available users from EspoCRM"
}, {
   "name": "list_teams",
   "description": "Retrieve all available teams from EspoCRM"
},

Еще один, который можно использовать для отправки сообщений WhatsApp, идеально подходит для спама!

Code:
{
   "name": "send_whatsapp",
   "description": "Send a WhatsApp message to a single number"
}, {
   "name": "bulk_send_whatsapp",
   "description": "Send WhatsApp messages to multiple numbers"
}, {
   "name": "get_session_status",
   "description": "Check the status of a WhatsApp session"
}, {
   "name": "validate_number",
   "description": "Check if a number is valid on WhatsApp"
}

Святой Грааль: удаленное выполнение кода как доступный инструмент через сервер MCP!

Code:
{
   "name": "execute_shell_command",
   "description": "Execute shell commands through the proxy server"
},
{
   "name": "broadcast_websocket",
   "description": "Broadcast message to all WebSocket clients"
},
{
   "name": "get_server_status",
   "description": "Get current server status and statistics"
}

(Бонус) Ловушки MCP?​

Просто к сведению, это показалось нам довольно любопытным. Хотя мы не углублялись слишком сильно, наш сканер обнаружил сотни ловушек, имитирующих серверы MCP, которые используют HTTP с SSE в качестве типа транспорта. Мы обнаружили более 1100 случаев, когда запрос GET /sse возвращал следующее:

Не удалось прогрузить медиа


Мы взяли несколько из них для выборки и подтвердили следующее:

  • Параметр session_id был одинаковым для всех них
  • Когда мы попытались получить доступ к URL-адресу конечной точки для инициализации соединения MCP, действительные данные не были возвращены
  • У всех них были сотни открытых портов, вероятно, для имитации различных сетевых протоколов
  • Они иногда возвращали случайные HTML-страницы при доступе к /sse или другим путям
Так что нет никаких сомнений, что это ловушки, готовые поймать кого-то (вроде нас), кто сканирует интернет на предмет серверов MCP.

Мы просто хотим привлечь внимание к проблеме (наш призыв к действию)​


Мы не можем достаточно подчеркнуть: рассматривайте этот пост в блоге как призыв к действию для повышения осведомленности о новой проблеме. MCP был анонсирован примерно год назад, и мы уже видим удивительное количество серверов MCP в дикой природе без механизмов авторизации, что фактически приглашает любого злоумышленника использовать их как угодно. Это может быть первым симптомом чего-то гораздо более распространенного в ближайшем будущем. По мере роста принятия мы можем ожидать появления в сети еще большего количества открытых серверов MCP.

Если вы планируете использовать MCP в своей организации, это отлично! MCP остается с нами, и, как мы видели, это отличный способ связать приложения ИИ с внешними инструментами и наборами данных. Но, пожалуйста, делайте это безопасно:

  • Не выставляйте свои серверы MCP в интернет, если это абсолютно не необходимо. Например, если вы используете их для поддержки внутренних приложений ИИ, держите серверы MCP в пределах внутренних сетей. Еще лучше, рассмотрите возможность использования типа транспорта Stdio: запуск локально означает на один вектор удаленной атаки меньше
  • Даже если вы используете удаленные типы транспорта, такие как Streamable HTTP, для ваших внутренних серверов MCP, и особенно если вам нужно сделать их общедоступными, чтобы ваши клиенты могли использовать их в своих приложениях и службах, следуйте лучшим практикам спецификации. Официальная рекомендация — использовать OAuth 2.1, хотя другие безопасные альтернативы могут подойти для вашего варианта использования..
Оригинал статьи: https://www.bitsight.com/blog/exposed-mcp-servers-reveal-new-ai-vulnerabilities
👍26 🔥6 😁9 😮4
Ответlisa99

Как мы уже видели, конечные точки MCP обычно находятся по адресу /mcp или /sse, следуя соглашениям, определенным в спецификации. Однако, как и в случае с любым другим соглашением, ничто не мешает кому-либо разместить…

здесь они слукавили.
Рассказали, чтобы не рассказать. На самом деле запросы, поиск эндпойтов MCP делается иначе
Удалось насобирать интересных случаев. 

Пишу статью по уязвимостям MCP.
👍4

Гостевой просмотр. Чтобы отвечать и ставить реакции, войдите или зарегистрируйтесь.