Autor: Evan Harris
Risc: Scăzut
Componentă afectată: Serverul MCP Amazon MQ Broker de la AWS Labs

TL;DR

O vulnerabilitate în serverul MCP Amazon MQ Broker de la AWS Labs ar fi putut permite atacatorilor neautentificați din aceeași rețea să șteargă și să creeze brokere Amazon MQ atunci când serverul MCP rulează în modul SSE. Am raportat vulnerabilitatea către AWS. Compania a remediat problema eliminând complet SSE. Nu au fost expuse date de autentificare, dar defectul încălca principiul privilegiului minim și putea provoca perturbări operaționale. Utilizatorii ar trebui să se actualizeze imediat la cea mai recentă versiune.

Context

Serverul MCP Amazon MQ Broker de la AWS Labs permite asistenților AI să gestioneze brokerele Amazon MQ prin comenzi simple pentru crearea, ștergerea și configurarea infrastructurii de mesagerie care alimentează aplicațiile distribuite.

Am descoperit o vulnerabilitate de expunere în rețea în modul SSE al serverului Amazon MQ MCP care permite atacatorilor din aceeași rețea să deturneze operațiunile de gestionare a brokerelor.

Un atacator ar putea șterge brokere critice de mesaje, crea resurse neautorizate și perturba infrastructura de mesagerie, totul fără a avea nevoie de date de autentificare AWS.

În această postare de blog, detaliem modul în care funcționează vulnerabilitatea și demonstrăm un scenariu real de atac care arată cât de ușor o compromitere a rețelei interne poate escalada către perturbarea infrastructurii AWS.

Prezentare generală

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

Scenariu de atac

  1. Un dezvoltator sau operator rulează serverul MQ MCP cu:

    uv run server.py --sse

    În mod implicit, serverul MQ MCP se leagă la 0.0.0.0, deschizând serverul către atacuri bazate pe rețea.

  2. Un atacator obține acces la rețeaua în care rulează acest server (de exemplu, printr-o regulă deschisă a firewallului, un port expus sau o compromitere locală).

  3. Atacatorul se conectează la portul SSE implicit (de obicei 8888) folosind un client precum MCP Inspector.

  4. Odată conectat, atacatorul poate:

    4.1 Enumeră brokerele MQ folosind instrumentul list_brokers

    4.2 Identifică brokerele marcate cu tag-ul mcp_server_version, care le indică drept gestionate de un server MCP

    4.3 Efectuează operațiuni mutative precum delete_broker

  5. Dacă serverul MCP a fost lansat cu flagul suplimentar --allow-resource-creation, atunci atacatorul ar putea, de asemenea, să creeze noi brokere MQ, ceea ce ar putea duce la o proliferare a resurselor sau la epuizarea cotelor.

Proof of Concept

Un atac de bază a fost demonstrat folosind:

  • Un server MCP victimă cu --sse activat
  • Un atacator simulat în aceeași rețea
  • Clientul MCP Inspector pentru a se conecta și a emite comenzi

Atacatorul a reușit să:

  • Enumere brokerele
  • Șteargă orice broker cu tag-ul de gestionare corespunzător
  • (Dacă este configurat) Creeze noi brokere în contul AWS al victimei

În niciun moment al atacului nu au fost expuse sau necesare date de autentificare AWS.

Impact

  • Refuzul serviciului prin eliminarea brokerelor
  • Ștergerea neautorizată a brokerelor Amazon MQ
  • Crearea neautorizată de resurse dacă --allow-resource-creation este activat
  • Încălcarea privilegiului minim, în ciuda faptului că utilizatorii operează în limitele așteptate

Reacția AWS Labs

După ce am divulgat problema pe 22 mai 2025, AWS Labs a confirmat rapid vulnerabilitatea și a luat măsuri decisive. În loc să implementeze autentificare pentru modul SSE, AWS Labs a ales să elimine complet funcționalitatea SSE din serverul MCP.

Remedierea, lansată în pull request #417, elimină complet modul de transport SSE care crea expunerea neautentificată în rețea. Începând cu versiunea din 27 mai 2025, exploatarea demonstrată aici nu mai este posibilă.

Apreciem reacția rapidă a AWS Labs și abordarea lor orientată către securitate, prin care au eliminat funcționalitatea riscantă în loc să încerce să o corecteze.

Recomandări

Pentru utilizatorii finali

  • Actualizați la cea mai recentă versiune a serverului AWS MQ MCP
  • Nu expuneți serverele MCP către rețele publice sau nedemne de încredere
  • Auditați serviciile de rețea interne pentru expunerea accidentală a instrumentelor privilegiate
  • Evitați transmiterea flagului --allow-resource-creation cu excepția cazului în care este explicit necesar pentru scenariul dumneavoastră de utilizare

Cronologie

Dată Eveniment
21 mai 2025 Vulnerabilitate descoperită
22 mai 2025 Vulnerabilitate raportată către AWS Labs
27 mai 2025 AWS Labs lansează remedierea (PR #417) care elimină suportul SSE
8 ianuarie 2026 Amazon CNA a marcat problema ca fiind în afara domeniului din cauza configurației non-implicite
9 ianuarie 2026 Data de publicare convenită
15 ianuarie 2026 Divulgare publică