Sichern Sie Ihr MCP-System: 11 häufige Risiken und wie Sie sich davor schützen

MCP-Risiken lassen sich grob in drei Kategorien einteilen: LLM-Manipulation, Daten- und Zugriffssicherheit sowie Schwachstellen in der Infrastruktur.

Da MCP-Server häufig Zugriff auf eine Vielzahl interner Systeme bieten, ist das potenzielle Sicherheitsrisiko hoch. Wie wahrscheinlich ein Vorfall ist, hängt jedoch stark von der Einrichtung ab.

Einzelpersonen und Unternehmen können viele Maßnahmen ergreifen, um ihre Systeme zu schützen, und die Schutzprotokolle sollten stets in einem angemessenen Verhältnis zu den Funktionen und Daten stehen, die verbundene MCP-Server offenlegen könnten.

Was sind MCP und MCP-Sicherheit?

Das Model Context Protocol (MCP) ist ein offener Standard von Anthropic, mit dem sich LLM-basierte Apps (oder Hosts) mit externen Systemen verbinden lassen.

Ein MCP-System besteht aus drei Kernkomponenten: dem Host, dem Client und dem Server. Der Host, häufig ein KI-Assistent, verbindet sich über einen Client mit einem externen MCP-Server. Anschließend kann er Anfragen senden, um externe Funktionen (Tools) auszuführen oder Daten (Ressourcen) bzw. Prompts abzurufen, die dem Kontextfenster des LLM hinzugefügt werden.

Vergrößern

MCP-Sicherheit bezeichnet die Protokolle, die die Verbindungen und Komponenten in einem MCP-System schützen. Es gibt mehrere zentrale Herausforderungen, die spezifisch für MCP sind – etwa die Tatsache, dass KI-Apps oft agentische Fähigkeiten haben und schädliche Anweisungen in Nachrichten eingebettet sein können.

Auch bekannte Probleme, die nicht MCP-spezifisch sind, etwa Prompt-Injection, schwache Authentifizierung und unsichere Drittanbieter-Integrationen, stellen eine Gefahr dar. Wie jedes Computersystem setzt MCP zum Schutz auf eine Kombination aus organisatorischen Protokollen, etwa der ausschließlichen Nutzung vertrauenswürdiger Server, und technischen Kontrollen wie API-Gateways.

Wie ernst sind MCP-Bedrohungen?

MCP hat sich schnell zu einer beliebten LLM-Technologie entwickelt und wird von vielen Organisationen und Verbraucher-Apps genutzt. Da MCP-Server in Code geschriebene Programme sind, weisen sie wie jede andere Anwendung Schwachstellen auf.

Wenn Organisationen MCP jedoch in kontrollierten Umgebungen einsetzen, ist es im Allgemeinen sicher. Es ist ein erheblicher Unterschied, ob man ein System mit vertrauenswürdigen Servern und geprüften Berechtigungen aufbaut oder einen autonomen Agenten an ein Dutzend ungeprüfter Server anschließt.

Bedrohung Nr. 1: Indirekte Prompt-Injection

Ein Angreifer kann Anweisungen, die auf das LLM abzielen, in einem Dokument, einer Webseite oder einer Tool-Ausgabe platzieren, die ein MCP-Server zurückgibt. Fügt der Host dieses Material dem Kontextfenster hinzu, besteht die Möglichkeit, dass das LLM es für echte Anweisungen hält.

Hinzu kommt, dass diese Anweisungen auf den ersten Blick durchaus angemessen wirken können. So könnte ein abgerufenes Support-Ticket das LLM etwa anweisen, vertrauliche Kundendaten zu exportieren, bevor es eine Antwort generiert.

So schützen Sie sich vor indirekter Prompt-Injection

Prompt-Injections sollten in der Regel auf Host-Ebene abgewehrt werden. Externe Inhalte sollten als nicht vertrauenswürdig gekennzeichnet werden, und Anfragen nach vertraulichen Informationen sollten die informierte Zustimmung eines Menschen im Prozess (Human in the Loop) erfordern. Hilfreich können auch Sicherheitstests sein, bei denen schädliche Dokumente oder Daten aufgerufen werden, um zu sehen, wie Host und LLM reagieren.

Bedrohung Nr. 2: Tool Poisoning und Rug Pulls

Bei einem Tool-Poisoning-Angriff wird schädlicher Code in die Beschreibung oder das Schema eines MCP-Tools eingefügt. Dadurch kann das LLM in der Erkennungsphase beeinflusst werden, wenn MCP erstmals die verfügbaren Tools bereitstellt.

Vergrößern

Ein Rug Pull ist eine besondere Form des Tool Poisoning, bei der genehmigte Metadaten geändert werden. Diese Form kann die Art und Weise verändern, wie ein Modell vertrauenswürdige Tools nutzt, statt direkt ein schädliches Tool aufzurufen.

So schützen Sie sich vor Tool Poisoning und Rug Pulls

Der Host sollte vor der Nutzung jedes Tools dessen vollständige Definition prüfen und mit einer Liste genehmigter, vertrauenswürdiger Tools abgleichen, um so Änderungen zu erkennen. Parameterprüfungen können helfen, potenziell gefährliche Fähigkeiten zu identifizieren und zu kennzeichnen.

Bedrohung Nr. 3: Übermäßige Berechtigungen

Häufig erteilen Nutzer MCP-Servern und verbundenen LLMs (über den Host) mehr Berechtigungen, als für eine Aufgabe nötig sind – etwa Schreibrechte, wo Lesezugriff ausreichen würde, oder vollständigen Zugriff auf ein internes Dateisystem (wie Google Drive).

Diese ausufernde Ausweitung von Berechtigungen kann den Schadensradius anderer Schwachstellen wie schädlicher Tool-Aufrufe vergrößern. Häufig „summieren“ sich Berechtigungen, wenn Nutzer im Rahmen ihrer täglichen Arbeit mit KI-Tools in einem Unternehmen Rechte vergeben (Rechteanhäufung).

So schützen Sie sich vor übermäßigen Berechtigungen

Am direktesten schützen Sie sich vor diesem Problem, indem Sie Berechtigungen und OAuth-Scopes (Lesen, Schreiben, Vollzugriff usw.) einschränken. Freigaben durch Nutzer, insbesondere für sensible Vorgänge, sind dabei ein wichtiger Bestandteil, doch Berechtigungen sollten auch auf Systemebene (Betriebssystem, MCP-Host und Server) kontrolliert werden.

Bedrohung Nr. 4: Schwache Authentifizierung und Autorisierung

Authentifizierung überprüft die Identität von Nutzern oder Anwendungen, die sich mit einem MCP-Server verbinden. Autorisierung legt fest, auf welche Tools und Ressourcen sie zugreifen können.

Schlecht konfigurierte MCP-Server akzeptieren möglicherweise Anfragen oder Tokens, ohne Nutzer korrekt zu authentifizieren oder Zugriffsbeschränkungen durchzusetzen. Zudem können gestohlene Anmeldedaten Angreifern Zugriff verschaffen, wenn die Validierung schwach ist.

So schützen Sie sich vor schwacher Authentifizierung und Autorisierung

OAuth-basierte Authentifizierung für Remote-MCP-Server, kurzlebige Tokens und rollenbasierte Zugriffskontrolle (RBAC) sind Maßnahmen, die dazu beitragen, schwache Autorisierung abzumildern. Rollenbasierter Zugriff ist nützlich, weil er verhindert, dass Nutzer über ihre Berechtigungen hinaus auf Daten und Tools zugreifen, selbst wenn der Server selbst Zugriff hat.

Bedrohung Nr. 5: Offengelegte und missbrauchte Anmeldedaten

MCP-Server nutzen routinemäßig Anmeldedaten wie API-Schlüssel und OAuth-Zugriffstokens, um sich mit externen Diensten zu verbinden. Werden diese offengelegt oder missbraucht, können Angreifer Zugriff auf vertrauliche Daten und Funktionen erlangen.

Ein Beispiel ist Token-Passthrough: Dabei leitet ein MCP-Server ein Zugriffstoken an einen anderen Dienst weiter, ohne zu prüfen, ob es tatsächlich für den empfangenden Dienst bestimmt ist. Das kann wiederum zu Datenlecks führen, wenn der empfangende Dienst unzureichend geschützt ist.

So schützen Sie sich vor offengelegten und missbrauchten Anmeldedaten

Kurzlebige Tokens mit eng begrenztem Geltungsbereich und die Rotation von Anmeldedaten schränken wirksam ein, in welchem Umfang Angreifer offengelegte Daten nutzen können. API-Schlüssel und Anmeldedaten sollten stets sicher in einem Secret Manager gespeichert werden.

Bedrohung Nr. 6: Confused-Deputy-Angriffe

Ein Confused-Deputy-Angriff liegt vor, wenn ein Angreifer eine vertrauenswürdige Anwendung dazu bringt, ihre Berechtigungen für eine Aktion zu nutzen, die nicht von einem legitimen Nutzer autorisiert wurde. In diesem Fall ist der MCP-Server der „Deputy“, also der Stellvertreter.

Vergrößern

Der Angreifer nutzt eine Schwachstelle des MCP-Servers (etwa eine unzureichende OAuth-Verifizierung) aus, um einen schädlichen Vorgang auszuführen, beispielsweise einen Tool-Aufruf oder einen Datenabruf.

So schützen Sie sich vor Confused-Deputy-Angriffen

Eine Autorisierungsprüfung, bei der jeder Tool-Aufruf daraufhin verifiziert wird, dass er zu einem bestimmten Nutzer gehört, hilft, Confused-Deputy-Angriffe einzudämmen. Zudem sollten sensible Aktionen wie Datenexporte eine ausdrückliche Autorisierung erfordern.

Bedrohung Nr. 7: Schädliche Server und kompromittierte Abhängigkeiten

MCP-Server können schädlichen Code enthalten (sie sind im Grunde externe Programme) oder auf kompromittierten Abhängigkeiten wie Drittanbieter-Bibliotheken beruhen. Dabei handelt es sich um ein Problem der Software-Lieferkette und nicht um ein MCP-spezifisches Problem.

Das kann zum Beispiel ganz einfach passieren, wenn ein Angreifer eine scheinbar legitime Integration verbreitet. Nach der Einrichtung kann sie Anmeldedaten stehlen und wiederverwenden, auf vertrauliche Daten zugreifen und nicht autorisierte Vorgänge ausführen.

So schützen Sie sich vor schädlichen Servern und kompromittierten Abhängigkeiten

Installieren Sie MCP-Server nur aus vertrauenswürdigen und geprüften Quellen. Prüfen Sie nach Möglichkeit deren Code und kontrollieren Sie stets alle externen Abhängigkeiten. Sorgen Sie dafür, dass Server regelmäßig aktualisiert und gepatcht werden.

Bedrohung Nr. 8: Server-Side Request Forgery (SSRF)

Bei Server-Side Request Forgery (SSRF) bringt ein Angreifer einen MCP-Server dazu, Netzwerkanfragen an interne Adressen zu senden, auf die der Nutzer nicht zugreifen wollte.

Das kann passieren, wenn ein MCP-Server ein Tool bereitstellt, das Informationen von einer URL abruft. Kann ein Angreifer den URL-Parameter beeinflussen, kann er ihn auf eine gewünschte Netzwerkadresse ändern, etwa eine interne API oder einen Cloud-Dienst. Dadurch können vertrauliche Daten abgerufen und möglicherweise zugänglich gemacht werden

So schützen Sie sich vor Server-Side Request Forgery (SSRF)

MCP-Server sollten URLs stets validieren, den Zugriff auf gesperrte interne Netzwerkadressen blockieren und ausgehenden Netzwerkzugriff unterbinden. Auch für Weiterleitungen sollte dieses Protokoll gelten.

Bedrohung Nr. 9: Session-Hijacking

Beim Session-Hijacking übernimmt ein Angreifer die Kontrolle über eine aktive Verbindung zwischen einem MCP-Client und einem Server.

So könnte ein Angreifer beispielsweise eine Sitzungs-ID aus einer unzureichend gesicherten MCP-Anwendung (z. B. einem Host oder Server) stehlen. Akzeptiert der MCP-Server diese ID, kann der Angreifer möglicherweise Tools mit den legitimen Berechtigungen des Nutzers aufrufen.

So schützen Sie sich vor

Das Risiko von Session-Hijacking lässt sich durch eine strikte Identitätsprüfung über alle Anwendungen in einem MCP-System hinweg verringern. Zudem ist eine Verschlüsselung zwischen MCP-Clients und Remote-Servern unerlässlich, damit Sitzungs-IDs nicht ausgespäht werden können.

Bedrohung Nr. 10: Mix-up-Angriffe

Bei einem Mix-up-Angriff bringt der Angreifer einen MCP-Client dazu, einen Autorisierungscode an einen schädlichen Autorisierungsserver zu senden, der sich zwischen Client und MCP-Server befindet. Ein Autorisierungsserver ist eine Anwendung, die OAuth-Zugriffstokens ausstellt, nachdem sie geprüft hat, ob der angeforderte Zugriff autorisiert ist.

Vergrößern

Verbindet sich ein MCP-Host mit mehreren Diensten, die jeweils einen anderen Autorisierungsserver nutzen, kann ein Angreifer möglicherweise einen davon kontrollieren (etwa durch Registrierung eines schädlichen Dienstes) und den Client dazu bringen, einen von einem legitimen Server ausgestellten Autorisierungscode an den schädlichen Server zu senden. Durch diese Verwechslung kann sich der Angreifer womöglich als die autorisierte Anwendung ausgeben und Zugriff auf geschützte Dienste erlangen.

So schützen Sie sich vor Mix-up-Angriffen

MCP-Clients sollten die Identität des Autorisierungsservers während des gesamten OAuth-Prozesses überprüfen. Konkret sollten sie die Aussteller-ID (iss) des Servers mit der erwarteten Identität abgleichen und Abweichungen zurückweisen.

Bedrohung Nr. 11: Kompromittierung lokaler MCP-Server

Viele MCP-Server laufen auf dem lokalen Rechner eines Nutzers. Nutzer installieren den Server möglicherweise von einem Drittanbieter oder entwickeln ihn selbst. Gelingt es einem Angreifer, diesen lokalen MCP-Server zu kompromittieren, kann er möglicherweise Zugriff auf große Teile des lokalen Systems erlangen.

Ein Angreifer kann sich auf verschiedene Weise Zugriff verschaffen. Er kann einen schädlichen Server verbreiten, der als legitime Integration getarnt ist, die Konfiguration eines MCP-Hosts so verändern, dass dieser einen schädlichen Befehl ausführt, oder auf einen MCP-Server zugreifen, der in einer Umgebung mit unzureichenden Sicherheitskontrollen läuft – etwa per DNS-Rebinding, bei dem ein Browser dazu gebracht wird, Anfragen an einen localhost-Dienst zu senden.

So schützen Sie sich vor der Kompromittierung lokaler MCP-Server

Beim Einsatz lokaler MCP-Server sind Sandboxing und strenge Zustimmungsprotokolle wichtig. MCP-Server sollten ausschließlich von vertrauenswürdigen Anbietern installiert werden, und Betriebssystemberechtigungen sollten einschränken, auf welche Verzeichnisse sie zugreifen können.

MCP-Schwachstellen sind oft alte Bedrohungen in neuem Gewand

MCP-Schwachstellen entstehen oft dadurch, dass bekannte Risiken und Angriffsmethoden auf neue Weise angewendet werden. MCP eröffnet Angreifern durch das Zusammenspiel von LLMs, MCP-Servern und externen Diensten neue Wege, diese Schwachstellen auszunutzen.

Natürlich gibt es MCP-spezifische Bedrohungen. Man sollte jedoch bedenken, dass Standard-Sicherheitsprotokolle wie eine strikte Autorisierung, die Nutzung vertrauenswürdiger Anbieter und der Schutz vor Prompt-Injections viel zum Schutz jeder MCP-Implementierung beitragen.