Autor: Evan Harris
Risiko: Niedrig
Betroffene Komponente: Amazon MQ Broker MCP Server von AWS Labs

TL;DR

Eine Schwachstelle im Amazon MQ Broker MCP Server von AWS Labs konnte es unauthentifizierten Angreifern im selben Netzwerk ermöglichen, Amazon MQ Broker zu löschen und zu erstellen, wenn der MCP Server im SSE-Modus betrieben wird. Wir haben die Schwachstelle an AWS gemeldet. AWS behob das Problem, indem SSE vollständig entfernt wurde. Es wurden keine Zugangsdaten offengelegt, aber der Fehler verletzte das Prinzip der geringsten Rechte und konnte Betriebsstörungen verursachen. Nutzer sollten umgehend auf die neueste Version aktualisieren.

Hintergrund

Der Amazon MQ Broker MCP Server von AWS Labs ermöglicht es KI-Assistenten, Amazon MQ Broker über einfache Befehle zu verwalten: zum Erstellen, Löschen und Konfigurieren der Messaging-Infrastruktur, die verteilte Anwendungen antreibt.

Wir haben im SSE-Modus des Amazon MQ MCP Servers eine Schwachstelle durch Netzwerkexponierung entdeckt, die es Angreifern im selben Netzwerk erlaubt, Broker-Verwaltungsoperationen zu kapern.

Ein Angreifer konnte kritische Message Broker löschen, unautorisierte Ressourcen erstellen und die Messaging-Infrastruktur stören, und das alles ohne jegliche AWS-Zugangsdaten.

In diesem Blogbeitrag erläutern wir, wie die Schwachstelle funktioniert, und demonstrieren ein realistisches Angriffsszenario, das zeigt, wie leicht eine Kompromittierung des internen Netzwerks zu einer Störung der AWS-Infrastruktur eskalieren kann.

Überblick

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

Angriffsszenario

  1. Ein Entwickler oder Betreiber startet den MQ MCP Server mit:

    uv run server.py --sse

    Standardmäßig bindet sich der MQ MCP Server an 0.0.0.0 und öffnet den Server damit für netzwerkbasierte Angriffe.

  2. Ein Angreifer erhält Zugang zu dem Netzwerk, in dem dieser Server läuft (z. B. über eine offene Firewall-Regel, einen exponierten Port oder eine lokale Kompromittierung).

  3. Der Angreifer verbindet sich über einen Client wie MCP Inspector mit dem Standard-SSE-Port (üblicherweise 8888).

  4. Nach dem Verbindungsaufbau kann der Angreifer:

    4.1 MQ Broker mit dem Tool list_brokers auflisten

    4.2 Broker identifizieren, die mit mcp_server_version getaggt sind, was sie als von einem MCP Server verwaltet kennzeichnet

    4.3 Verändernde Operationen wie delete_broker ausführen

  5. Wenn der MCP Server mit dem zusätzlichen Flag --allow-resource-creation gestartet wurde, konnte der Angreifer außerdem neue MQ Broker erstellen, was potenziell zu Ressourcenwildwuchs oder zur Erschöpfung von Kontingenten führen kann.

Proof of Concept

Ein einfacher Angriff wurde demonstriert mit:

  • einem Opfer-MCP-Server mit aktiviertem --sse
  • einem simulierten Angreifer im selben Netzwerk
  • dem MCP-Inspector-Client zum Verbinden und Absetzen von Befehlen

Der Angreifer konnte:

  • Broker auflisten
  • jeden Broker mit dem entsprechenden Verwaltungs-Tag löschen
  • (falls entsprechend konfiguriert) neue Broker im AWS-Konto des Opfers erstellen

Zu keinem Zeitpunkt des Angriffs wurden AWS-Zugangsdaten offengelegt oder benötigt.

Auswirkungen

  • Denial of Service durch Entfernen von Brokern
  • Unautorisiertes Löschen von Amazon MQ Brokern
  • Unautorisierte Ressourcenerstellung, wenn --allow-resource-creation aktiviert ist
  • Verletzung des Prinzips der geringsten Rechte, obwohl Nutzer innerhalb der erwarteten Grenzen agieren

Reaktion von AWS Labs

Nachdem wir das Problem am 22. Mai 2025 gemeldet hatten, bestätigte AWS Labs die Schwachstelle schnell und handelte entschlossen. Anstatt eine Authentifizierung für den SSE-Modus zu implementieren, entschied sich AWS Labs, die SSE-Funktionalität vollständig aus dem MCP Server zu entfernen.

Der Fix, veröffentlicht in Pull Request #417, beseitigt den SSE-Transportmodus, der die unauthentifizierte Netzwerkexponierung verursachte, vollständig. Seit dem Release vom 27. Mai 2025 ist der hier demonstrierte Exploit nicht mehr möglich.

Wir danken AWS Labs für die schnelle Reaktion und den sicherheitsorientierten Ansatz, riskante Funktionalität zu entfernen, statt zu versuchen, sie zu patchen.

Empfehlungen

Für Endnutzer

  • Aktualisieren Sie auf die neueste Version des AWS MQ MCP Servers
  • Exponieren Sie MCP Server nicht in öffentlichen oder nicht vertrauenswürdigen Netzwerken
  • Prüfen Sie interne Netzwerkdienste auf versehentliche Exponierung privilegierter Werkzeuge
  • Vermeiden Sie das Flag --allow-resource-creation, sofern es für Ihren Anwendungsfall nicht ausdrücklich erforderlich ist

Zeitleiste

Datum Ereignis
21. Mai 2025 Schwachstelle entdeckt
22. Mai 2025 Schwachstelle an AWS Labs gemeldet
27. Mai 2025 AWS Labs veröffentlicht Fix (PR #417), der die SSE-Unterstützung entfernt
8. Januar 2026 Amazon CNA stuft das Problem wegen nicht standardmäßiger Konfiguration als außerhalb des Geltungsbereichs ein
9. Januar 2026 Veröffentlichungsdatum vereinbart
15. Januar 2026 Öffentliche Bekanntgabe