Autor: Evan Harris
Ryzyko: Niskie
Komponent, którego dotyczy problem: Amazon MQ Broker MCP Server od AWS Labs

TL;DR

Podatność w Amazon MQ Broker MCP Server od AWS Labs mogła pozwolić nieuwierzytelnionym atakującym w tej samej sieci na usuwanie i tworzenie brokerów Amazon MQ, gdy MCP Server działa w trybie SSE. Zgłosiliśmy podatność do AWS. Firma naprawiła problem, całkowicie usuwając SSE. Nie ujawniono żadnych poświadczeń, ale luka naruszała zasadę najmniejszych uprawnień i mogła spowodować zakłócenia operacyjne. Użytkownicy powinni niezwłocznie zaktualizować do najnowszej wersji.

Kontekst

Amazon MQ Broker MCP Server od AWS Labs umożliwia asystentom AI zarządzanie brokerami Amazon MQ za pomocą prostych poleceń do tworzenia, usuwania i konfigurowania infrastruktury komunikacyjnej, która napędza aplikacje rozproszone.

Odkryliśmy podatność związaną z ekspozycją sieciową w trybie SSE Amazon MQ MCP Server, która pozwala atakującym w tej samej sieci przejąć operacje zarządzania brokerami.

Atakujący mógł usunąć krytyczne brokery komunikatów, utworzyć nieautoryzowane zasoby i zakłócić infrastrukturę komunikacyjną, a wszystko to bez potrzeby posiadania jakichkolwiek poświadczeń AWS.

W tym wpisie na blogu wyjaśniamy, jak działa ta podatność, i przedstawiamy realistyczny scenariusz ataku, który pokazuje, jak łatwo kompromitacja sieci wewnętrznej może eskalować do zakłócenia infrastruktury AWS.

Przegląd

%%{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

Scenariusz ataku

  1. Programista lub operator uruchamia MQ MCP Server za pomocą:

    uv run server.py --sse

    Domyślnie MQ MCP Server nasłuchuje na 0.0.0.0, co otwiera serwer na ataki sieciowe.

  2. Atakujący uzyskuje dostęp do sieci, w której działa ten serwer (np. przez otwartą regułę zapory, wystawiony port lub lokalną kompromitację).

  3. Atakujący łączy się z domyślnym portem SSE (zazwyczaj 8888) przy użyciu klienta takiego jak MCP Inspector.

  4. Po nawiązaniu połączenia atakujący jest w stanie:

    4.1 Wyliczyć brokery MQ za pomocą narzędzia list_brokers

    4.2 Zidentyfikować brokery oznaczone tagiem mcp_server_version, który oznacza je jako zarządzane przez MCP Server

    4.3 Wykonywać operacje modyfikujące, takie jak delete_broker

  5. Jeśli MCP Server został uruchomiony z dodatkową flagą --allow-resource-creation, atakujący mógł również tworzyć nowe brokery MQ, co potencjalnie prowadzi do rozrostu zasobów lub wyczerpania limitów.

Proof of Concept

Podstawowy atak zademonstrowano przy użyciu:

  • Serwera MCP ofiary z włączonym --sse
  • Symulowanego atakującego w tej samej sieci
  • Klienta MCP Inspector do łączenia się i wydawania poleceń

Atakujący był w stanie:

  • Wyświetlić listę brokerów
  • Usunąć dowolnego brokera z odpowiednim tagiem zarządzania
  • (Jeśli skonfigurowano) Utworzyć nowe brokery na koncie AWS ofiary

W żadnym momencie ataku nie ujawniono ani nie wymagano poświadczeń AWS.

Wpływ

  • Odmowa usługi poprzez usunięcie brokerów
  • Nieautoryzowane usunięcie brokerów Amazon MQ
  • Nieautoryzowane tworzenie zasobów, jeśli włączono --allow-resource-creation
  • Naruszenie zasady najmniejszych uprawnień, mimo że użytkownicy działają w oczekiwanych granicach

Reakcja AWS Labs

Po ujawnieniu przez nas problemu 22 maja 2025 r. AWS Labs szybko potwierdziło podatność i podjęło zdecydowane działania. Zamiast wdrażać uwierzytelnianie dla trybu SSE, AWS Labs zdecydowało się całkowicie usunąć funkcjonalność SSE z MCP Server.

Poprawka wydana w pull requeście #417 całkowicie eliminuje tryb transportu SSE, który powodował nieuwierzytelnioną ekspozycję sieciową. Od wydania z 27 maja 2025 r. przedstawiony tutaj exploit nie jest już możliwy.

Doceniamy szybką reakcję AWS Labs oraz ich podejście stawiające bezpieczeństwo na pierwszym miejscu, polegające na usunięciu ryzykownej funkcjonalności zamiast prób jej łatania.

Zalecenia

Dla użytkowników końcowych

  • Zaktualizuj do najnowszej wersji AWS MQ MCP Server
  • Nie udostępniaj serwerów MCP w sieciach publicznych lub niezaufanych
  • Audytuj usługi sieci wewnętrznej pod kątem przypadkowej ekspozycji uprzywilejowanych narzędzi
  • Unikaj przekazywania --allow-resource-creation, chyba że jest to wyraźnie wymagane w Twoim przypadku użycia

Oś czasu

Data Wydarzenie
21 maja 2025 Odkryto podatność
22 maja 2025 Zgłoszono podatność do AWS Labs
27 maja 2025 AWS Labs wydaje poprawkę (PR #417) usuwającą obsługę SSE
8 stycznia 2026 Amazon CNA uznaje problem za wykraczający poza zakres z powodu niedomyślnej konfiguracji
9 stycznia 2026 Uzgodniono datę publikacji
15 stycznia 2026 Publiczne ujawnienie