Ausnutzung von Schwachstellen
Mit Containern gesicherte MCP-Infrastruktur, Teil 1
Eine angemessene Absicherung von Model Context Protocol (MCP)-Servern in Containern kann Security-Risiken mindern und Vorteile bieten, die für den Schutz von Cloud-Workloads unerlässlich sind. Doch auch hier lauern Lücken, etwa bei Repositorys.
Save to Folio
Das Model Context Protocol (MCP) ist ein Open-Source-Standard, der es KI-Anwendungen ermöglicht, mit Systemen wie Datenbanken, APIs und Diensten unter Verwendung natürlicher Sprache zu interagieren, wodurch die Erstellung komplexer Workflows auf Basis von LLMs vereinfacht und skalierbarer wird. Das Protokoll bietet zwar viele Vorteile für Unternehmen, erweitert aber auch bei der Implementierung die Angriffsfläche und erfordert daher zusätzliche Sicherheitsmaßnahmen. Über die Risiken und Schwachstellen haben wir bereits berichtet.
Nun geht es darum, wie Container dazu beitragen können, MCP-Servern eine zusätzliche Schutzebene zu bieten. Doch vorweg gesagt, Container können keinen absoluten Schutz garantieren und eine unsachgemäße Verwendung erzeugt ein falsches Gefühl der Sicherheit.
Bedarf es eines MCP-Layers?
Als erstes sollten Anwender prüfen, ob ein MCP-Layer wirklich notwendig ist. Das heißt, es wird untersucht, ob ein Problem von Tool-Orchestrierung und LLM-gesteuertem Reasoning profitiert oder ob ein direkter CLI/SDK-Aufruf die Aufgabe mit weniger Komplexität und einer geringeren Angriffsfläche auch erfüllen würde.
MCP sollte genutzt werden, wenn die Aufgabe das Reasoning über unübersichtliche Eingaben, die Koordination mehrerer Tools oder Entscheidungen mit menschlicher Beteiligung erfordert. Ein einfacherer Ansatz ist vorzuziehen, wenn die Aktion deterministisch und klar begrenzt ist (z. B. das Ausführen eines SSH-Befehls, das Lesen einer Registrierungs-Tag-Liste oder das Rotieren eines Schlüssels). Nicht jeder Workflow oder jede Automatisierung benötigt eine LLM-Anwendung.
Ist die Verwendung eines MCP wirklich vorteilhaft, sollte stdio-Modus bevorzugt werden. In diesem Fall läuft der MCP-Server als lokaler Prozess und kommuniziert mit dem Client über Standard-Ein- und -Ausgaben. Es gilt zu bedenken, dass nichts im Netzwerk offengelegt wird, wenn kein TCP-Port geöffnet ist.
Verbesserung der MCP-Sicherheit durch Container
Die Sicherheit des MCP-Servers lässt sich durch Containerisierung verbessern, doch muss gleichzeitig auf die Sicherheitslücken hingewiesen werden, die wir bei unserer Untersuchung von 22.000 MCP-Repositorys gefunden haben.
Sandboxing der MCP-Serverfunktionalität
Bestimmte MCP-Server stellen ein erhebliches Risiko dar, da sie lokale Systemressourcen für Remote-Netzwerkaufrufe exponieren. Obwohl dies eher eine Funktion als eine Schwachstelle ist, sollten zusätzliche Maßnahmen ergriffen werden, um das Risiko zu minimieren.
Zur Veranschaulichung haben wir einen Proof-of-Concept mit dem Playwright MCP-Projekt erstellt. Laut Dokumentation gewährt der eigenständige MCP-Server mit aktiviertem HTTP-Transport jedem Client Zugriff auf Systemressourcen. Hier läuft der Server isoliert in einem Container. Wenn der Prozess jedoch nicht in einer Sandbox ausgeführt würde, könnte jeder Angreifer mit Zugriff auf den MCP-Server sensible lokale Dateien anfordern. Je nach den Berechtigungen des Serverprozesses könnten Angreifer unter anderem Systemanmeldedateien, alle SSH-Schlüssel und Anmeldedaten für Cloud-Konten exfiltrieren.
Darüber hinaus lässt sich nicht sicher sagen, dass der MCP-Server nur auf localhost verfügbar ist. Sofern keine bestimmte Konfiguration übergeben wird, überwacht der MCP-Server alle Netzwerkschnittstellen. Und selbst wenn der MCP-Server nur auf der localhost-Schnittstelle verfügbar ist, könnten andere lokale Benutzer dennoch die MCP-Serverfunktionalität ausnutzen und eine Erweiterung von Privilegien erreichen. Natürlich steigt das Risiko, wenn der MCP-Server vollständig für das Netzwerk verfügbar ist. Leider konnten wir in unserer MCP-Exposure-Studie bereits neun Fälle von Playwright-MCP-Servern identifizieren, die im Internet verfügbar sind.
Die Ausführung von MCP über HTTP/SSE ist zwar bequem, vergrößert jedoch die Angriffsfläche im Vergleich zu stdio. Wenn ein MCP-Server gestartet wird, der im Netzwerk lauscht und sich an 0.0.0.0 (alle Schnittstellen) bindet, sind die Tools von jedem Host im selben Netzwerk erreichbar. Bei einem in einem Container ausgeführten MCP-Server ist es wichtig, den Netzwerkzugriff auf das erforderliche Minimum zu beschränken.
Read-Only-Schutz und Sicherheitsübertragung an Dritte
Unsere früheren Untersuchungen ergaben, dass es bei exponierten MCP-Servern an Authentifizierung mangelt, wodurch private Datenquellen anfällig für Datenverletzungen sind. Die ursprüngliche MCP-Protokollspezifikation behandelt weder Authentifizierung noch Autorisierung. Die aktuelle Spezifikation beschreibt die Autorisierung als optional.
Wir konnten folgende Arten von Schwachstellen identifizieren:
- Der Read-Only-Schutz überträgt die volle Verantwortung auf das LLM. Dadurch entsteht das Risiko, dass ein Modell die Tool-Beschreibung vollständig ignoriert und den Schutz absichtlich oder unabsichtlich umgeht. Der MCP-Server könnte sogar komplett ohne LLM verwendet und die Tools direkt ausgeführt werden.
- Schwachstellen bei der Implementierung von Funktionen. Dazu gehören fehlende Normalisierung vor der Filterung und die Möglichkeit der Umgehung durch Verwendung eines nicht gefilterten Argumentsatzes.
- Schwachstellen in Komponenten von Drittanbietern. Dazu gehören Abhängigkeiten von Open-Source- und von Closed-Source-Bibliotheken.
Die ZDI hat bereits mehrere Schwachstellen dieser Art veröffentlicht. Daher sollte man niemals davon ausgehen, dass der Standard-MCP-Server-Container von Natur aus sicher ist. Er stellt bloß die Basis dar, und die Sicherheit muss an die jeweiligen Bedürfnisse angepasst werden. Anwender sollten Zeit in die Feinabstimmung der Zugriffsberechtigungen für das Datenquellen-Token investieren, und ein spezielles schreibgeschütztes Token für MCP erstellen.
Darüber hinaus schränkt die Absicherung der MCP-Server innerhalb eines Containers mit eingeschränkten Funktionen und Berechtigungen die Möglichkeiten für laterale Bewegungen ein. Wenn Unternehmen beispielsweise den Netzwerkzugriff nur auf die verknüpften Datenquellen beschränken, werden andere private Datenquellen, die möglicherweise über das Netzwerk verfügbar sind, ausgeschlossen.
Ist der MCP-Server anfällig für die Ausführung von Remote-Code, stellen eingeschränkte Berechtigungen und Funktionen sicher, dass kein einfacher Zugriff auf den zugrunde liegenden Host möglich ist.
Die Containerisolierung könnte einen Angreifer daran hindern, sich vom kompromittierten MCP-Server aus lateral in das private Netzwerk zu bewegen oder mit anderen Host-Diensten zu interagieren. Um eine laterale Bewegung innerhalb des Diensteanbieters zu verhindern, sind eine ordnungsgemäße RBAC, geringstmögliche Berechtigungen und grundlegende Zero-Trust-Richtlinien erforderlich.
Offenlegung von Anmeldedaten
Für den Zugriff auf private Datenquellen (APIs, Datenbanken, Cloud-Konten und interne Tools) bedarf es der Anmeldedaten (Alias-Geheimnisse). Eine sichere Bereitstellung von MCP-Server-Containern verhindert den Zugriff auf aggregierte MCP-Server-Konfigurationsdateien mit nicht-essenziellen Geheimnissen, schützt jedoch nicht vollständig vor jeder Offenlegung von Anmeldedaten. Container können durch verantwortungsbewusstes Geheimnismanagement dazu beitragen, das Risiko der Offenlegung von Anmeldedaten zu verringern.
Im zweiten Teil wird der Ansatz für eine Implementierung von Mindestprivilegien im Zusammenhang mit Containern beschrieben.