Give Them an Inch and They Will Take a Mile:Understanding and Measuring Caller Identity Confusion in MCP-Based AI Systems

Die Studie zeigt, dass MCP-basierte KI-Systeme durch das Fehlen einer expliziten Anrufer-Authentifizierung und eine zu weit gefasste Server-Vertrauensstellung fundamental unsicher sind, da einmalige Autorisierung und fehlende granulare Zugriffskontrollen den Angriffsvektor für Identitätsverwechslungen erheblich vergrößern.

Das Wesentliche

🍎 Das Problem: "Gib ihnen einen Zentimeter, und sie nehmen eine Meile"

Stell dir vor, du hast einen sehr intelligenten persönlichen Assistenten (eine KI), der dir helfen soll, Dinge auf deinem Computer zu erledigen. Damit dieser Assistent wirklich arbeiten kann, braucht er eine Art Übersetzer oder Kellner, der die Befehle der KI an deine Programme (wie den Browser, den Dateimanager oder E-Mail-Client) weiterleitet.

In der Welt der KI nennt man diesen Kellner MCP (Model Context Protocol).

Das Problem, das die Forscher von der Shandong University entdeckt haben, ist wie folgt:

🏨 Der Vergleich: Das Hotel mit dem falschen Schlüssel

Stell dir den MCP-Server als ein Hotel vor.

1. Der Gast (Die KI): Ein Gast kommt an, zeigt seinen Ausweis und sagt: "Ich darf jetzt in das VIP-Schlosszimmer gehen." Der Hotelmanager (der Server) prüft den Ausweis, öffnet die Tür und gibt dem Gast einen Master-Schlüssel für die gesamte Etage.
2. Das Missverständnis: Der Hotelmanager denkt sich: "Ah, dieser Gast ist jetzt autorisiert. Ich lasse die Tür offen und gebe den Master-Schlüssel einfach so weiter, falls jemand anderes kommt."
3. Der Dieb (Der Angreifer): Jetzt kommt ein völlig anderer Gast (ein Hacker oder eine andere KI), der gar nicht im Hotel angemeldet ist. Er läuft einfach zur Tür, nimmt den Master-Schlüssel, den der Manager für den ersten Gast hingelegt hat, und betritt das VIP-Schlosszimmer.

Der Manager denkt: "Aber ich habe doch jemandem erlaubt, hier reinzukommen!"
Das Problem ist: Der Manager hat vergessen zu fragen: "Wer hält den Schlüssel gerade in der Hand?"

In der IT-Sicherheit nennen die Forscher dieses Phänomen "Caller Identity Confusion" (Verwirrung bezüglich der Identität des Aufrufers).

🔍 Was haben die Forscher gemacht?

Sie haben sich nicht nur theoretisch Gedanken gemacht, sondern einen Schnüffel-Detektor namens MCPAuthChecker gebaut.

• Die Aufgabe: Dieser Detektor schaut sich Tausende von diesen "Hotels" (MCP-Servern) an. Er prüft: "Wenn jemand eine Tür öffnet, wird wirklich geprüft, ob diese spezifische Person die Erlaubnis hat, oder wird einfach nur geglaubt, dass 'jemand' schon mal da war?"
• Die Methode: Der Detektor simuliert verschiedene Szenarien. Er fragt: "Wenn ich jetzt eine andere KI bin, kann ich trotzdem auf deine Daten zugreifen, weil du dich vorhin schon mal angemeldet hast?"

📊 Was haben sie herausgefunden? (Die erschreckende Statistik)

Die Forscher haben 6.137 dieser Server untersucht. Das Ergebnis ist alarmierend:

• Fast die Hälfte (46,4 %) sind unsicher.
• Das bedeutet: Bei fast jedem zweiten Server reicht es aus, dass jemand einmal richtig angemeldet war, damit jeder andere danach alles tun darf, ohne sich erneut auszuweisen.
• Es spielt keine Rolle, ob der Server von einem großen Tech-Unternehmen oder einem einzelnen Entwickler gemacht wurde. Das Problem ist überall.
• Besonders gefährlich sind Server, die für Entwickler gedacht sind, da diese oft Zugriff auf sehr mächtige Funktionen haben (wie das Löschen von Dateien oder das Ausführen von Code).

💣 Was können Angreifer damit anstellen?

Wenn diese Lücke ausgenutzt wird, passiert Folgendes (die Forscher haben echte Beispiele gefunden):

1. Ferngesteuerte Zerstörung: Ein Hacker kann Befehle auf deinem Computer ausführen, als wäre er du. Er kann Programme starten, Dateien löschen oder sich in deinem Netzwerk bewegen.
2. Geheime Kontrolle über deinen Bildschirm: Es gibt Server, die den Bildschirm steuern können. Ein Angreifer könnte deinen Browser fernsteuern, Passwörter eingeben oder Screenshots machen, ohne dass du etwas davon merkst.
3. Missbrauch von Konten: Stell dir vor, du hast dich bei Slack oder Amazon AWS angemeldet. Ein Angreifer könnte nun über diese Lücke Nachrichten in deinem Namen senden oder teure Cloud-Dienste nutzen, weil der Server denkt: "Hey, die KI war doch schon angemeldet!"

🛡️ Was ist die Lösung?

Die Forscher sagen: Hört auf, dem Server blind zu vertrauen!

Jedes Mal, wenn eine KI einen Befehl ausführen will, muss der Server nicht nur prüfen, ob eine Erlaubnis existiert, sondern wer genau diese Erlaubnis gerade nutzt.

• Falsch: "Ich habe gestern eine Erlaubnis bekommen, also darf ich heute alles."
• Richtig: "Wer ist gerade hier? Zeig mir deinen Ausweis für diesen spezifischen Befehl."

🎯 Fazit in einem Satz

Die KI-Welt baut gerade riesige, mächtige Systeme, vergisst aber oft, die Türschlösser zu wechseln, wenn ein neuer Gast hereinkommt. Die Forscher haben gezeigt, dass fast die Hälfte dieser Systeme so unsicher ist, dass ein Angreifer einfach die Tür aufstoßen und alles mitnehmen kann, ohne dass es jemand merkt.

Die Lehre: Vertrauen ist gut, aber Kontrolle (und zwar bei jedem einzelnen Befehl) ist besser!

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Give Them an Inch and They Will Take a Mile: Understanding and Measuring Caller Identity Confusion in MCP-Based AI Systems" auf Deutsch.

1. Problemstellung: Caller Identity Confusion (Verwechslung der Anruferidentität)

Das Paper untersucht Sicherheitslücken im Model Context Protocol (MCP), einem offenen Standard, der es Large Language Models (LLMs) ermöglicht, mit externen Tools und Diensten zu interagieren. MCP fungiert als Middleware, bei der ein MCP-Server (ein unabhängiger Prozess) als Ausführungsstelle für Agenten fungiert und über die notwendigen Zugangsdaten (Credentials) für Backend-Ressourcen verfügt.

Das zentrale Sicherheitsproblem, das die Autoren identifizieren, nennen sie „Caller Identity Confusion" (Verwechslung der Anruferidentität).

• Der Kern des Problems: MCP-Server behandeln oft Autorisierungsentscheidungen als persistente, serverseitige Zustände. Sobald ein legitimer Benutzer eine Autorisierung erteilt hat (z. B. für den Zugriff auf Facebook oder AWS), speichert der Server diesen Zustand.
• Die Schwachstelle: Der Server unterscheidet nicht zwischen dem ursprünglichen, autorisierten Anrufer und nachfolgenden Anfragen von anderen Agenten oder Skripten. Da LLM-Agenten oft zustandslos sind oder keine expliziten Identitätsinformationen weitergeben, verlässt sich der Server auf den einmal etablierten „vertrauenswürdigen" Zustand.
• Die Konsequenz: Ein Angreifer kann einen MCP-Server kontaktieren, der bereits von einem legitimen Benutzer autorisiert wurde. Da der Server die Identität des neuen Anrufers nicht prüft, führt er die Befehle des Angreifers mit den Rechten des ursprünglichen Benutzers aus. Dies geschieht ohne Diebstahl von Zugangsdaten oder Umgehung von Sicherheitsmechanismen, sondern durch Missbrauch des Autorisierungs-Designs.

2. Methodik: MCPAuthChecker

Um dieses Problem in der Praxis zu messen, entwickelten die Autoren MCPAuthChecker, ein Analyse-Framework, das Autorisierung auf der Granularität einzelner Tool-Aufrufe untersucht. Da statische Analysen bei MCP oft an dynamischen Dispatch-Mechanismen scheitern, kombiniert das Tool statische und dynamische Techniken:

1. Auflösung von Ausführungspunkten (Execution-Triggered Tool Entry Resolution):

   • MCP-Tools werden nicht über feste Hauptfunktionen, sondern über Protokoll-basierte tools/call-Anfragen ausgelöst.
   • Das Tool rekonstruiert die Abhängigkeiten im Code (mittels CodeQL), um zu identifizieren, wo eine externe Anfrage tatsächlich in die interne Ausführungslogik übergeht, unabhängig von Registrierungsmechanismen (Decorators, APIs, Laufzeit-Enumeration).

2. Pfad-sensitive Autorisierungsanalyse (Path-Sensitive Authorization Analysis):

   • Das System verfolgt den Kontrollfluss von jedem Tool-Eintrittspunkt bis zu sensiblen Operationen (z. B. Dateizugriff, Systembefehle).
   • Es prüft, ob Autorisierung entlang dieses Pfades explizit für den aktuellen Anrufer geprüft wird oder ob auf einen zwischengespeicherten (cached) Zustand zurückgegriffen wird.

3. Selektive dynamische Validierung (Selective Dynamic Validation):

   • Da statische Analyse oft nicht erkennen kann, ob ein Autorisierungsstatus zu Laufzeit wiederverwendet wird, führt das Tool kontrollierte dynamische Tests durch.
   • Es aktiviert den MCP-Server über einen Proxy, führt autorisierte Aufrufe durch und prüft dann, ob nachfolgende Aufrufe von einem anderen Kontext (ohne erneute Authentifizierung) erfolgreich ausgeführt werden können. Ein Erfolg ohne erneute Prüfung bestätigt die Verwundbarkeit.

3. Wichtige Beiträge

• Formalisierung einer neuen Schwachstelle: Die Autoren definieren und formalisieren „Caller Identity Confusion" als fundamentale Lücke in MCP-Implementierungen, die durch das Fehlen einer expliziten Bindung von Autorisierung an die Anruferidentität entsteht.
• Entwicklung von MCPAuthChecker: Ein praktisches Framework, das die Lücke zwischen statischer Code-Analyse und dynamischer Laufzeitverifikation schließt, um Autorisierungsmissbrauch in MCP-Servern zu erkennen.
• Großangelegte empirische Studie: Die erste umfassende Messung von 6.137 realen MCP-Servern, die das Ausmaß des Problems in der aktuellen Ökosystem-Landschaft aufzeigt.
• Demonstration realer Angriffe: Das Paper zeigt konkrete Angriffsszenarien (Remote Code Execution, GUI-Übernahme, Missbrauch von Drittanbieter-APIs), die durch diese Schwachstelle ermöglicht werden.

4. Ergebnisse der Studie

Die Analyse von 6.137 MCP-Servern (in Python und JavaScript) ergab alarmierende Ergebnisse:

• Verbreitung: 46,4 % (2.846 Server) weisen unsichere Autorisierungsverhalten auf.
• Verteilung:
  • Unsichere Muster sind nicht auf unreife Projekte beschränkt, sondern finden sich auch in hoch bewerteten Repositories (>1000 Stars).
  • Developer Tools sind besonders betroffen (52 % unsicher), da sie dichte Ausführungsschnittstellen bieten.
  • Auch in Bereichen wie „API & Integration", „Databases & Storage" und „Productivity" ist das Problem weit verbreitet.
• Art der Schwachstellen:
  • AuthNone: Keine Autorisierung (ca. 25 % der unsicheren Server).
  • AuthCache: Autorisierung wird einmalig durchgeführt und dann für alle folgenden Aufrufe wiederverwendet (ca. 30–40 %).
  • AuthRuntime: Laufzeitprüfungen existieren, sind aber inkonsistent oder nicht an den Anrufer gebunden.
• Autor-Cluster: Eine kleine Gruppe von Entwicklern ist für einen überproportional großen Anteil der unsicheren Server verantwortlich, was auf systemische Designfehler in bestimmten Bibliotheken oder Frameworks hindeutet.

5. Signifikanz und Implikationen

Die Studie zeigt, dass die Sicherheit von MCP-basierten Systemen nicht durch das Fehlen von Credentials, sondern durch das Design der Autorisierungslogik gefährdet ist.

• Angriffsvektoren: Die Schwachstelle ermöglicht Angriffe wie:
  • Remote Command Execution (RCE): Ausführung beliebiger Shell-Befehle auf dem Host-System.
  • GUI-Hijacking: Fernsteuerung von Browsern und Benutzeroberflächen (z. B. Umgehen von CAPTCHAs).
  • Privilegienmissbrauch: Nutzung von Token für Drittanbieter-Dienste (Slack, AWS) durch unbefugte Agenten.
• Fehlende Abwehr: Herkömmliche Sicherheitsmaßnahmen wie Credential-Management oder Sandboxing greifen hier nicht, da der Angriff über legitime, autorisierte Pfade erfolgt.
• Empfehlung: Die Autoren fordern, dass Invocation-level, caller-bound authorization (aufrufspezifische, an den Anrufer gebundene Autorisierung) zu einem ersten Designprinzip für Agenten-Frameworks werden muss. Autorisierung darf nicht als serverseitiger Zustand, sondern muss als kontextgebundene Entscheidung pro Anfrage behandelt werden.

Das Paper unterstreicht, dass die schnelle Adoption von MCP als „USB-C für KI-Anwendungen" ohne entsprechende Sicherheitsanpassungen ein massives Risiko für die Integrität und Vertraulichkeit der verbundenen Systeme darstellt.