Несанкціоноване керування MQ-брокером через режим SSE у MCP-сервері Amazon MQ Broker від AWS Labs

Автор: Evan Harris
Ризик: Низький
Уражений компонент: MCP-сервер Amazon MQ Broker від AWS Labs

Стисло

Вразливість у MCP-сервері Amazon MQ Broker від AWS Labs могла дозволити неавтентифікованим зловмисникам у тій самій мережі видаляти та створювати брокери Amazon MQ, коли MCP-сервер запущено в режимі SSE. Ми повідомили про вразливість до AWS. Компанія усунула проблему, повністю видаливши SSE. Облікові дані не були розкриті, проте вада порушувала принцип найменших привілеїв і могла призвести до збоїв у роботі. Користувачам слід негайно оновитися до останньої версії.

Передумови

MCP-сервер Amazon MQ Broker від AWS Labs дозволяє ШІ-асистентам керувати брокерами Amazon MQ за допомогою простих команд для створення, видалення та налаштування інфраструктури обміну повідомленнями, на якій працюють розподілені застосунки.

Ми виявили вразливість мережевої експозиції в режимі SSE сервера Amazon MQ MCP, яка дозволяє зловмисникам у тій самій мережі перехоплювати операції керування брокерами.

Зловмисник міг видаляти критично важливі брокери повідомлень, створювати несанкціоновані ресурси та порушувати роботу інфраструктури обміну повідомленнями, причому все це без жодних облікових даних AWS.

У цій публікації ми розбираємо, як працює вразливість, та демонструємо реальний сценарій атаки, що показує, наскільки легко компрометація внутрішньої мережі може перерости в порушення роботи інфраструктури AWS.

Огляд

%%{init: {'themeVariables': {'fontSize': '18px'}}}%%
flowchart TD
    A[Developer runs MCP Server
with --sse flag] --> B[Server binds to
0.0.0.0:8888
No authentication required]
    B --> C[Attacker gains network
access
• Open firewall rule
• Exposed port
• Local compromise]
    C --> D[Attacker discovers SSE
endpoint
Port scan or service
discovery]
    D --> E[Connect using MCP
Inspector
target-ip:8888/sse]
    E --> F[Enumerate available tools
list_brokers, delete_broker,
etc.]
    F --> G[List existing MQ brokers
Identify managed brokers
with mcp_server_version tag]
    G --> H{Server launched with
--allow-resource-creation?}
    H -->|Yes| I[Full Control:
• Delete brokers
• Create new brokers
• Resource sprawl
• Quota exhaustion]
    H -->|No| J[Limited Control:
• Delete existing brokers
• Denial of service
• Operational disruption]
    I --> K[Impact: Unauthorized
infrastructure management
without AWS credentials]
    J --> K

    style A fill:#e3f2fd
    style B fill:#fff3e0
    style C fill:#ffebee
    style D fill:#ffebee
    style E fill:#ffebee
    style F fill:#ffebee
    style G fill:#ffebee
    style H fill:#fff9c4
    style I fill:#ffcdd2
    style J fill:#ffcdd2
    style K fill:#c8e6c9

Сценарій атаки

Розробник або оператор запускає MQ MCP-сервер за допомогою:

uv run server.py --sse

За замовчуванням MQ MCP-сервер прив’язується до 0.0.0.0, відкриваючи сервер для мережевих атак.
Зловмисник отримує доступ до мережі, в якій працює цей сервер (наприклад, через відкрите правило міжмережевого екрана, доступний порт або локальну компрометацію).
Зловмисник підключається до стандартного порту SSE (зазвичай 8888) за допомогою клієнта, такого як MCP Inspector.
Після підключення зловмисник може:

4.1 Перелічити брокери MQ за допомогою інструмента list_brokers

4.2 Визначити брокери, позначені тегом mcp_server_version, що вказує на їх керування MCP-сервером

4.3 Виконувати змінювальні операції, такі як delete_broker
Якщо MCP-сервер було запущено з додатковим прапорцем --allow-resource-creation, зловмисник міг би також створювати нові брокери MQ, що потенційно призводить до розростання ресурсів або вичерпання квот.

Демонстрація концепції

Базову атаку було продемонстровано з використанням:

MCP-сервера-жертви з увімкненим --sse
змодельованого зловмисника в тій самій мережі
клієнта MCP Inspector для підключення та надсилання команд

Зловмисник зміг:

Перелічити брокери
Видалити будь-який брокер із відповідним керувальним тегом
(за відповідного налаштування) створити нові брокери в акаунті AWS жертви

На жодному етапі атаки облікові дані AWS не були розкриті та не вимагалися.

Наслідки

Відмова в обслуговуванні через видалення брокерів
Несанкціоноване видалення брокерів Amazon MQ
Несанкціоноване створення ресурсів за увімкненого --allow-resource-creation
Порушення принципу найменших привілеїв, попри те що користувачі діють у межах очікуваних кордонів

Реакція AWS Labs

Після того як ми розкрили проблему 22 травня 2025 року, AWS Labs швидко підтвердила вразливість та вжила рішучих заходів. Замість реалізації автентифікації для режиму SSE компанія AWS Labs вирішила повністю видалити функціональність SSE з MCP-сервера.

Виправлення, випущене в pull request #417, повністю усуває транспортний режим SSE, який створював неавтентифіковану мережеву експозицію. Починаючи з випуску від 27 травня 2025 року, продемонстрований тут експлойт більше неможливий.

Ми високо цінуємо швидку реакцію AWS Labs та їхній орієнтований на безпеку підхід, за якого ризикована функціональність була видалена, а не залатана.

Хронологія

Дата	Подія
21 травня 2025	Вразливість виявлено
22 травня 2025	Про вразливість повідомлено до AWS Labs
27 травня 2025	AWS Labs випускає виправлення (PR #417), що видаляє підтримку SSE
8 січня 2026	Amazon CNA позначила проблему як таку, що виходить за рамки, через нестандартну конфігурацію
9 січня 2026	Узгоджено дату публікації
15 січня 2026	Публічне розкриття