Der verify-mcp-Server von Kluster AI vertraut jeder Browser-Sitzung, die seinen /stream-Endpunkt erreichen kann.

Wenn der Dienst über HTTP bereitgestellt und an 0.0.0.0 gebunden ist, kann ein DNS-Rebinding-Angriff den Browser eines Opfers in einen Proxy verwandeln, der die API aus dem offenen Internet ansteuert.

Während unserer Tests konnten wir mit dieser Technik das Verify-Tool aus der Ferne aufrufen und Kluster-Credits ohne Zustimmung des Nutzers verbrauchen.

Zusammenfassung

  • Angriffsvektor: DNS-Rebinding missbraucht das Vertrauensmodell des Browsers, um einen Domainnamen von einem Angreifer-Host auf 127.0.0.1 umzuleiten und so die Schutzmechanismen der Same-Origin-Policy zu umgehen.
  • Exponierte Komponente: Der verify-mcp-Server von Kluster stellt /stream über einfaches HTTP bereit und akzeptiert Anfragen allein auf Basis der vom Client gelieferten Host-Header.
  • Beobachtetes Ergebnis: Nach dem Rebinding konnte vom Angreifer kontrolliertes JavaScript das Verify-Tool so ansteuern, als wäre es der lokale Nutzer, und dabei kostenpflichtige Credits verbrauchen.

Andere auf dieser Website behandelte Werkzeuge scheitern auf dieselbe Weise: DNS-Rebinding-Schwachstelle im SSE-Transport des Vet MCP Servers und Neo4j MCP Cypher Server durch DNS-Rebinding anfällig für Datenbankübernahme.

Technische Analyse

Der Angriff verläuft in zwei DNS-Phasen, gekoppelt mit einer leichtgewichtigen HTML/JavaScript-Payload:

  1. Erste Bindung an die Angreifer-Infrastruktur. Das Opfer besucht eine vom Angreifer kontrollierte Website. Die erste DNS-Abfrage löst zur öffentlichen IP des Angreifers auf, was es uns erlaubt, ein Skript auszuliefern, das den Kluster-Endpunkt abfragt.
  2. Rebinding auf localhost. Nachdem die Seite geladen ist, beantwortet der DNS-Server des Angreifers nachfolgende Abfragen für denselben Host mit 127.0.0.1. Browser verwenden den zwischengespeicherten Namen weiter, sodass anschließende fetch-Aufrufe stillschweigend auf die Loopback-Schnittstelle des Opfers umschwenken, während die ursprüngliche Origin-Zeichenkette erhalten bleibt.
  3. Ansteuerung der Verify-API. Da verify-mcp HTTP-Anfragen von jeder Herkunft erlaubt und die Host- oder Origin-Header nicht validiert, konnte unser Skript erfolgreich Jobs an /stream senden (POST) und damit credit-verbrauchende Verifizierungsläufe auslösen.

Dieses Muster ist nicht auf Kluster beschränkt, aber die Kombination aus HTTP-Transport und fehlender Header-Validierung machte die Ausnutzung trivial.

Auswirkungen

  • Missbrauch des Dienstes: Entfernte Akteure können Kluster-Verifizierungs-Credits verbrauchen oder die API mit Anfragen überfluten, was für legitime Nutzer finanziellen Schaden oder Rate-Limiting verursacht.

Empfehlungen

Für Kluster AI

  • Validieren Sie Host- und Origin-Header streng und weisen Sie Anfragen ab, die nicht mit einer expliziten Positivliste (localhost, 127.0.0.1) übereinstimmen.
  • Führen Sie eine Authentifizierung oder API-Token auch für lokale Sitzungen ein, um sicherzustellen, dass nur vertrauenswürdige Aufrufer credit-verbrauchende Aktionen auslösen können.

Für MCP-Betreiber und -Nutzer

  • Gehen Sie davon aus, dass localhost-Dienste bei Vorliegen von DNS-Rebinding über den Browser erreichbar sind; überwachen Sie die Logs auf unerwartete Origin-Namen.
  • Bevorzugen Sie HTTPS (mit ordnungsgemäßen Zertifikaten) und eine explizite Header-Validierung für jedes Tool, das über die Loopback-Schnittstelle hinaus bereitgestellt wird.
  • Schulen Sie Entwickler darin, lokale Agents zu schließen, wenn sie nicht vertrauenswürdige Seiten aufrufen, oder nutzen Sie Netzwerksegmentierung, um Agent-Dienste vom Standard-Browserprofil zu isolieren.

Abschließende Gedanken

DNS-Rebinding verwischt weiterhin die Grenze zwischen “lokal” und “remote” für MCP-Werkzeuge.

Durch die Härtung von Transportwegen, die Validierung von Anfrage-Metadaten und die Anforderung einer Authentifizierung können Plattformanbieter dazu beitragen, dass Entwickler sicherer arbeiten.

Zeitleiste

  • 2025-07-17: Erstmeldung an die Sicherheitsabteilung von Kluster AI übermittelt.
  • 2025-07-17: Kluster bestätigte den Eingang noch am selben Tag.
  • 2025-08-29: Nachfrage an Kluster AI zum Stand der Behebung gesendet.
  • 2025-10-16: Technischer Sicherheitshinweis auf mcpsec.dev veröffentlicht.