Autore: Evan Harris
Rischio: Basso
Componente interessato: Amazon MQ Broker MCP Server di AWS Labs

TL;DR

Una vulnerabilità nell’Amazon MQ Broker MCP Server di AWS Labs poteva consentire ad attaccanti non autenticati sulla stessa rete di eliminare e creare broker Amazon MQ quando l’MCP Server viene eseguito in modalità SSE. Abbiamo segnalato la vulnerabilità ad AWS, che ha risolto il problema rimuovendo completamente SSE. Non sono state esposte credenziali, ma la falla violava il principio del privilegio minimo e poteva causare interruzioni operative. Gli utenti dovrebbero aggiornare immediatamente all’ultima versione.

Contesto

L’Amazon MQ Broker MCP Server di AWS Labs consente agli assistenti IA di gestire i broker Amazon MQ tramite semplici comandi per creare, eliminare e configurare l’infrastruttura di messaggistica che alimenta le applicazioni distribuite.

Abbiamo scoperto una vulnerabilità di esposizione in rete nella modalità SSE dell’Amazon MQ MCP Server che consente agli attaccanti sulla stessa rete di dirottare le operazioni di gestione dei broker.

Un attaccante poteva eliminare broker di messaggi critici, creare risorse non autorizzate e interrompere l’infrastruttura di messaggistica, il tutto senza bisogno di alcuna credenziale AWS.

In questo articolo del blog analizziamo il funzionamento della vulnerabilità e dimostriamo uno scenario di attacco realistico che mostra con quanta facilità una compromissione della rete interna possa degenerare in un’interruzione dell’infrastruttura AWS.

Panoramica

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

Scenario di attacco

  1. Uno sviluppatore o un operatore avvia il MQ MCP Server con:

    uv run server.py --sse

    Per impostazione predefinita, il MQ MCP Server si lega a 0.0.0.0, esponendo il server ad attacchi provenienti dalla rete.

  2. Un attaccante ottiene l’accesso alla rete in cui è in esecuzione questo server (ad esempio, tramite una regola di firewall aperta, una porta esposta o una compromissione locale).

  3. L’attaccante si connette alla porta SSE predefinita (in genere la 8888) utilizzando un client come MCP Inspector.

  4. Una volta connesso, l’attaccante è in grado di:

    4.1 Enumerare i broker MQ tramite lo strumento list_brokers

    4.2 Identificare i broker contrassegnati con il tag mcp_server_version, che li segnala come gestiti da un MCP Server

    4.3 Eseguire operazioni mutative come delete_broker

  5. Se il MCP Server è stato avviato con il flag aggiuntivo --allow-resource-creation, l’attaccante poteva anche creare nuovi broker MQ, con il rischio di proliferazione delle risorse o esaurimento delle quote.

Proof of Concept

È stato dimostrato un attacco di base utilizzando:

  • Un MCP Server vittima con --sse abilitato
  • Un attaccante simulato all’interno della stessa rete
  • Il client MCP Inspector per connettersi e impartire comandi

L’attaccante è stato in grado di:

  • Elencare i broker
  • Eliminare qualsiasi broker con il tag di gestione appropriato
  • (Se configurato) Creare nuovi broker nell’account AWS della vittima

In nessun momento dell’attacco sono state esposte o richieste credenziali AWS.

Impatto

  • Denial of service tramite la rimozione dei broker
  • Eliminazione non autorizzata di broker Amazon MQ
  • Creazione non autorizzata di risorse se --allow-resource-creation è abilitato
  • Violazione del privilegio minimo, nonostante gli utenti operino entro i limiti previsti

Risposta di AWS Labs

Dopo aver comunicato il problema il 22 maggio 2025, AWS Labs ha confermato rapidamente la vulnerabilità e ha agito con decisione. Anziché implementare l’autenticazione per la modalità SSE, AWS Labs ha scelto di rimuovere completamente la funzionalità SSE dall’MCP Server.

La correzione, rilasciata nella pull request #417, elimina completamente la modalità di trasporto SSE che creava l’esposizione in rete senza autenticazione. A partire dal rilascio del 27 maggio 2025, l’exploit qui dimostrato non è più possibile.

Apprezziamo la rapida risposta di AWS Labs e il suo approccio orientato alla sicurezza, ossia rimuovere le funzionalità rischiose anziché tentare di correggerle con una patch.

Raccomandazioni

Per gli utenti finali

  • Aggiornate all’ultima versione dell’AWS MQ MCP Server
  • Non esponete i server MCP a reti pubbliche o non affidabili
  • Verificate i servizi della rete interna per individuare esposizioni accidentali di strumenti con privilegi
  • Evitate di passare --allow-resource-creation a meno che non sia esplicitamente richiesto dal vostro caso d’uso

Cronologia

Data Evento
21 maggio 2025 Vulnerabilità scoperta
22 maggio 2025 Vulnerabilità segnalata ad AWS Labs
27 maggio 2025 AWS Labs rilascia la correzione (PR #417) che rimuove il supporto SSE
8 gennaio 2026 Amazon CNA classifica il problema come fuori ambito a causa della configurazione non predefinita
9 gennaio 2026 Data di pubblicazione concordata
15 gennaio 2026 Divulgazione pubblica