Sicherheitstest für MCP-Server: Wie ich mit Siege versteckte Schwachstellen aufdeckte

Vor einigen Wochen veröffentlichte ich Warden, eine Steuerungsebene für MCP-Server, die den Zugriff auf Daten rollenbasiert und feldspezifisch regelt. Die Demo zeigte, wie ein Support-Role zwar Kundendaten abrufen konnte, aber die Rechnungsstufe (tier) aus den Ergebnissen entfernt wurde. Doch was passiert, wenn man gezielt nach dieser Information fragt?

Ich testete eine Abfrage mit dem Parameter {"tier": "Enterprise"} – und erhielt sechs Treffer, darunter Unternehmen wie Acme Corp und Initech. Obwohl die Support-Role die Rechnungsstufe nicht einsehen durfte, akzeptierte das System die Filterung als valide. Die Datenbank lieferte zwar keine direkten Werte, doch die bloße Existenz der Treffer verriet die versteckte Information. Ein vermeintlich sicheres System hatte ein Leck – und niemand bemerkte es.

Warum statische Scanner hier versagen

Moderne Sicherheitstools für MCP-Server analysieren typischerweise die Tool-Manifeste, prüfen Tool-Beschreibungen auf verdächtige Instruktionen oder scannen Metadaten nach Anomalien. Sie sind effektiv gegen offensichtliche Angriffe wie manipulierte Beschreibungen oder schädliche Metadaten. Doch was passiert, wenn der Fehler erst im laufenden Betrieb auftritt?

Genau das war bei Warden der Fall: Das Tool-Manifest war sauber, die Beschreibung von query_resource korrekt formuliert. Der Fehler existierte nur, wenn ein Nutzer mit einer echten Rolle eine Abfrage stellte. Statische Analysen können solche Laufzeitprobleme nicht erkennen – sie überprüfen den Code, nicht das Verhalten. Also entwickelte ich eine Lösung, die genau das tut.

Siehe MCP-Server unter realen Bedingungen

Das Ergebnis meiner Arbeit ist Siege, ein dynamischer Sicherheitsscanner, der MCP-Server nicht nur liest, sondern aktiv angreift. Statt Manifest-Dateien zu scannen, verbindet sich Siege als verschiedene Rollen mit dem Server und analysiert die zurückgegebenen Daten auf Unstimmigkeiten.

Die Kernidee: Runtime-Autorisierung prüfen. Statische Tools wie Grep-Scanner haben ihre Stärken bei der Erkennung von Textmustern, doch sie erkennen keine Fehler, die erst durch echte Abfragen entstehen. Siege simuliert Angriffe, indem es sich als unterschiedliche Rollen authentifiziert und die Ergebnisse mit denen einer voll berechtigten Rolle vergleicht.

Ein zentrales Prinzip bei der Entwicklung war: Keine harten Annahmen. Keine festen Feldnamen, keine vordefinierten Rollen. Stattdessen lernt Siege das System dynamisch: Zunächst wird der Zugriff einer voll berechtigten Rolle (z. B. ein Admin) erfasst, um das vollständige Schema und alle Daten zu dokumentieren. Anschließend testet Siege jede eingeschränkte Rolle und vergleicht die Ergebnisse mit der Baseline. So entstehen vier Hauptkategorien von Schwachstellen:

• Versteckte Filterlecks: Wenn ein Feld in der Ausgabe entfernt wird, aber als Filter akzeptiert wird, kann ein Angreifer anhand der Anzahl der Treffer Rückschlüsse auf die gefilterten Werte ziehen. Beispiel: Eine Support-Role sieht keine Rechnungsstufen, aber eine Abfrage nach tier: Enterprise liefert weniger Treffer als erwartet – ein klares Indiz für eine undichte Stelle.

• Scope-Überschreitungen: Eine Rolle, die nur Daten aus einer bestimmten Region (z. B. West) einsehen darf, versucht, eine Abfrage mit region: East zu stellen. Erhält sie trotzdem Ergebnisse, wurde der Scope ignoriert.

• ID-Enumeration: Listenoperationen wie query_resource unterliegen der Zugriffskontrolle, doch einzelne Datensätze (get_record) werden oft nicht geprüft. Ein Angreifer kann so gezielt IDs raten und auf Daten zugreifen, die er nicht sehen darf.

• Verbotene Ressourcen: Eine Rolle darf bestimmte Ressourcen nicht einmal auflisten, doch der Zugriff auf konkrete IDs (get_record) wird nicht blockiert. Ein klassisches Beispiel für IDOR (Insecure Direct Object Reference) im MCP-Kontext.

Die letzten drei Schwachstellen wurden erst durch die dynamische Analyse entdeckt – sie wären manuell kaum zu finden gewesen. Doch sie sind keine Einzelfälle: Wer eine Schwachstelle systematisch sucht, findet oft gleich mehrere.

Reproduzierbare Beweise statt leerer Meldungen

Siege generiert für jede gefundene Schwachstelle einen vollständig reproduzierbaren Testfall, der alle notwendigen Details enthält: das verwendete Tool, die Argumente, die erwartete und die tatsächliche Antwort. So lässt sich der Fehler nicht nur nachvollziehen, sondern auch gezielt beheben.

In der Praxis testete ich zwei Versionen von Warden: eine mit dem ursprünglichen Fehler und eine mit der Korrektur. Die Ergebnisse waren eindeutig:

Vor der Korrektur (Commit 4938bdf):

• Hohe Schweregrad-Warnung: Verstecktes Feld tier durch Filterprädikat auf accounts geleakt
• Rolle: Support
• Reproduktion: query_resource({"resource_type":"accounts","filters":{"tier":"Enterprise"}})
• Baseline: 8 Treffer | Gefiltert: 6 Treffer | Leck: Acme Corp, Initech, Umbrella Co, Hooli, Stark Industries, Wayne Enterprises

Nach der Korrektur (Commit 7188eed):

• Keine Befunde. Die Schwachstelle war behoben.

Um sicherzustellen, dass Siege nicht nur „grün“ anzeigt, sondern tatsächlich funktioniert, enthält das Projekt zudem einen absichtlich fehlerhaften Testserver. Dieser Server ist mit bekannten Schwachstellen wie verbotenen Ressourcen-Zugriffen präpariert. Siege erkennt sie zuverlässig – ein Beweis für die Wirksamkeit der Methode.

Agenten-Hijacking: Wenn die KI selbst zum Angriffsziel wird

Neben klassischen Zugriffskontrollen prüft Siege auch, ob Sprachmodelle (LLMs) in MCP-Servern manipuliert werden können. Ein häufiger Angriffsvektor ist die Tool-Poisoning, bei der schädliche Anweisungen in Tool-Beschreibungen oder -Ausgaben versteckt werden. Statische Scanner erkennen solche Muster, indem sie nach verdächtigen Texten suchen. Doch was, wenn der Angreifer sich direkt an das Sprachmodell wendet?

Siege testet dies mit einem realen Agenten-Loop: Ein harmloses Lesetool wird mit einem export_record-Sink kombiniert, der Daten an eine externe URL sendet. Der Nutzer erhält die einfache Aufgabe, Datensatz 1 zusammenzufassen. Gleichzeitig injiziert Siege verschiedene Payloads – sowohl über Tool-Beschreibungen als auch über Ausgaben – und beobachtet, ob das Modell den schädlichen Export auslöst.

Die Ergebnisse werden in einer Matrix dargestellt, die zeigt, welche Payloads erfolgreich waren und welche abgewiesen wurden. Fünf Testfälle decken verschiedene Angriffsvektoren ab:

• System-Block-Spoofing (über Beschreibung und Ausgabe)
• Klare Policy-Texte
• Rollenkonfusion
• Aufgabenzerlegung

Ein sauberes Ergebnis (0 von 5 erfolgreiche Hijacks) bedeutet, dass das System robust ist. Gleichzeitig dient es als Regressionstest: Wird eine neue Modellversion eingeführt, kann geprüft werden, ob eine Payload, die bisher abgewiesen wurde, plötzlich erfolgreich ist.

Grenzen und zukünftige Erweiterungen

Siege ist noch nicht perfekt. Aktuell unterstützt er ausschließlich MCP-Server über die Standard-IO-Schnittstelle, während HTTP-basierte Server noch nicht abgedeckt sind. Auch OpenAI-Function-Calling ist noch nicht integriert – hier sind Erweiterungen geplant.

Ein wichtiger Hinweis: Siege gibt transparent an, welche Tests durchgeführt und welche übersprungen wurden. So bleibt die Analyse nachvollziehbar, und Nutzer wissen genau, welche Schwachstellen geprüft wurden – und welche nicht.

Laufzeitfehler wie der ursprüngliche Warden-Bug zeigen, dass statische Analysen allein nicht ausreichen. Dynamische Sicherheitstests, die das tatsächliche Verhalten prüfen, sind unverzichtbar – besonders in Umgebungen, in denen Sprachmodelle und Tools nahtlos zusammenarbeiten. Siege ist ein erster Schritt in diese Richtung. Die nächste Version wird nicht nur mehr Server-Typen unterstützen, sondern auch detailliertere Berichte liefern. Denn Sicherheit ist kein statischer Zustand, sondern ein kontinuierlicher Prozess – und wer ihn ignoriert, riskiert mehr als nur Datenlecks.