<НА ГЛАВНУЮ

Угрозы MCP: заражение инструментов, перехват и rug pull

'Протокол MCP упрощает интеграции LLM, но открывает новые риски: tool poisoning, tool hijacking и rug pulls; в статье расписаны механики атак и способы защиты.'

Протокол Model Context Protocol (MCP) структурирует доступ LLM к внешним инструментам и данным. Эта структура даёт ясность, но одновременно открывает новые точки атаки: злоумышленники могут злоупотреблять метаданными, скрытыми инструкциями и динамическими изменениями инструментов, чтобы подтолкнуть модель к нежелательным или вредоносным действиям.

Заражение инструмента (Tool Poisoning)

Атака типа Tool Poisoning встраивает скрытые вредоносные инструкции в метаданные или описание инструмента. В пользовательском интерфейсе видна упрощённая и безопасная версия описания, тогда как LLM получает полное определение инструмента, включая скрытые подсказки, закладные команды или искажённые инструкции. Эта рассинхронизация позволяет атакующему незаметно влиять на поведение модели.

Характерные признаки:

  • Скрытые подсказки или условные инструкции внутри определения инструмента.
  • Дружественное UI-описание, маскирующее опасную внутреннюю спецификацию.
  • Срабатывание атаки только при выполнении инструмента, что затрудняет обнаружение пользователем.

Меры защиты:

  • Проверять и санитизировать метаданные инструмента на стороне клиента перед передачей их модели.
  • Требовать криптографической подписи манифестов инструментов и проверять подписи при выполнении.
  • Отображать полные определения инструментов или автоматические диффы аудиторам и интеграторам, а не только упрощённые описания.
  • Ограничивать способность модели выполнять ненадёжные или высокорисковые инструкции, встроенные в определения.

Перехват инструмента (Tool Hijacking)

Tool Hijacking возникает, когда к одному клиенту подключены несколько MCP-серверов, и один из серверов является злонамеренным. Злоумышленник вставляет скрытые инструкции, которые пытаются перенаправить, переопределить или манипулировать поведением инструментов доверенного сервера. Например, злонамеренный сервер B может объявлять безобидный инструмент add(), но во внутренних инструкциях пытаться захватить email_sender от сервера A.

Почему это опасно:

  • Межсерверные взаимодействия расширяют границы доверия и дают возможность одному серверу влиять на инструменты другого.
  • Скрытые переопределения могут перенаправлять данные, раскрывать конфиденциальную информацию или изменять параметры без согласия пользователя.

Как защищаться:

  • Изолировать пространства имён инструментов по происхождению сервера и применять политики, привязанные к источнику.
  • Внедрять принцип наименьших привилегий: запрещать серверам ссылаться или переопределять инструменты, которыми они не владеют.
  • Логировать и мониторить разрешение инструментов между серверами и генерировать оповещения при конфликтных или неоднозначных определениях.

MCP Rug Pulls

MCP Rug Pull происходит, когда сервер изменяет определения инструментов после того, как пользователь уже одобрил их. Это похоже на ситуацию, когда доверённое приложение обновляется и становится вредоносным. Пользователь считает инструмент безопасным, но его поведение тихо меняется в фоновом режиме.

Основные риски:

  • Бесшумные изменения поведения после первоначального одобрения.
  • Сложность обнаружения из-за кэширования или постоянного хранения ранее одобренных определений на клиенте.
  • Возможность постепенного наращивания привилегий посредством серии небольших обновлений.

Превентивные меры:

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

Практические рекомендации для разработчиков

  • Обращайтесь с метаданными инструментов как с кодом: ревью, подпись и верификация так же жёстко, как для исполняемых артефактов.
  • Делайте UI прозрачным: показывайте полные определения инструментов доверенным операторам и предоставляйте читаемые диффы при обновлениях.
  • Ограничивайте автономность модели: требуйте явного подтверждения для чувствительных действий и вводите runtime-ограничения.
  • Логируйте каждое разрешение и вызов инструмента с информацией о происхождении, чтобы обеспечить возможность последующего анализа инцидентов.

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

🇬🇧

Switch Language

Read this article in English

Switch to English