Bedrohungsmodell für MCP und Agenten

Bedrohungsmodell für MCP und Agenten

0:00 Es gibt einen Satz, der die Sicherheitslage agentischer Systeme in einer Zeile zusammenfasst: Jeder Inhalt, den der Agent liest, ist eine mögliche Anweisung. Auch das Ergebnis eines Werkzeugs. Auch die Beschreibung eines Werkzeugs. Ein Sprachmodell unterscheidet nicht zwischen Daten und Befehl — es liest Text und handelt danach.

0:20 Dieses Modul zeigt, was daraus folgt. Und es zeigt, dass die bekannten Sicherheitsprobleme hier in neuer Kleidung wiederkehren.

Bedrohungsmodell für MCP und Agenten

0:28 Der dritte Tag gehört der Sicherheit, dem Betrieb und dem Capstone. Wir beginnen mit dem Bedrohungsmodell, und ich möchte Sie um eine Haltung bitten: Nehmen Sie die Beispiele nicht als exotische Angriffe, sondern als Beschreibung dessen, was in Ihrem System heute möglich wäre. Die meisten davon brauchen keinen fähigen Angreifer — sie brauchen nur jemanden, der einen Freitext ausfüllen darf.

Angriffsfläche über alle Beteiligten

0:51 Fangen wir mit der Landkarte an. Vier Stationen, und ein Angriff braucht nur eine davon. Das Bedrohungsmodell betrachtet alle vier Stationen: den Host mit seiner Zustimmungslogik, den Client mit seiner Isolation, den Server mit seiner Autorisierung und das Zielsystem mit seinen Daten. Das ist dieselbe Kette wie in Modul 3, nur von der anderen Seite gelesen. Und der wichtige Satz lautet: Ein Angriff braucht nur eine dieser Stationen.

1:17 Sie können drei davon vorbildlich absichern, und die vierte entscheidet. Vier Zeilen, vier Angriffspunkte, vier Folgen. Zustimmung im Stapel führt zu Wirkung ohne Prüfung. Fehlende Isolation dazu, dass ein Server fremden Kontext sieht. Ungeprüfte Eingabe zur Injektion ins Zielsystem. Und zu weite Rechte zum Zugriff über den Auftrag hinaus.

1:39 Die Fußzeile macht die Verbindung sichtbar: Das sind die Verantwortungsgrenzen aus Modul 2 — jede Grenze, die nicht gezogen wurde, ist hier ein Eintrittspunkt. Hier wird es unangenehm konkret. Ein lokaler Server läuft mit den Rechten des Clients — und damit mit Ihren. Ein Startbefehl in einer Konfigurationsdatei führt beliebigen Code aus, und diese Dateien werden geteilt und kopiert. Andere Prozesse auf derselben Maschine können ihn erreichen.

2:07 Und der vierte Punkt ist der, der viele überrascht: Über DNS-Rebinding erreicht ihn im schlechten Fall eine Webseite. Genau deshalb verlangt die Spezifikation die Prüfung des Origin-Headers. Der erste Punkt beschreibt den häufigsten Zuschnittsfehler: Das Bedrohungsmodell endet am eigenen Server. Dabei liegt das größte Risiko oft bei dem, was man eingebunden hat.

2:29 Der zweite und dritte gehören zusammen und sind der verbreitetste Leichtsinn: Ein fremder Server wird eingebunden, weil er im Verzeichnis stand, und der Startbefehl in der Konfiguration wird nie gelesen. Die Spezifikation zeigt dafür sogar Beispiele — Befehle, die nebenbei den privaten Schlüssel verschicken.

Direkte und indirekte Prompt Injection

2:47 Kommen wir zum bekanntesten Angriff — und zu seiner deutlich gefährlicheren Variante. Direkte Injection steht in der Eingabe des Nutzers. Indirekte Injection steht in Inhalten, die der Agent im Laufe seiner Arbeit liest: in Tickets, in Dokumentation, in Code-Kommentaren, in Ergebnissen von Werkzeugen. Die zweite Form ist die gefährlichere, und der Grund ist bestechend einfach: Niemand gibt sie ein. Sie liegt schon da und wartet darauf, gelesen zu werden.

3:15 Alle Reflexe, die wir gegen Nutzereingaben entwickelt haben, greifen hier nicht. Vier Felder, und die Aufmerksamkeit verteilt sich in der Praxis genau falsch. Die Nutzereingabe ist sichtbar und wird am ehesten geprüft. Repository-Inhalte — Tickets, Kommentare, Dokumentation — prüft fast niemand, obwohl jeder mit Schreibrecht dort etwas hinterlegen kann.

3:37 Werkzeugergebnisse, also Antworten fremder Systeme, gelten als vertrauenswürdig, weil sie technisch aussehen. Und das vierte Feld ist das unheimlichste: die Werkzeugbeschreibung selbst, also Text, den der Server liefert. Das ist keine Theorie von Sicherheitsforschern, es steht in der Spezifikation. Beschreibungen von Werkzeugen gelten als nicht vertrauenswürdig.

4:00 Das gilt auch für Annotationen, solange der Server nicht vertrauenswürdig ist. Clients sollen Werkzeugergebnisse prüfen, bevor sie an das Modell gehen. Und externe Inhalte gelten grundsätzlich als nicht vertrauenswürdig. Vier Sätze, die man zitieren kann, wenn im eigenen Team jemand fragt, ob das alles nicht etwas übertrieben sei.

4:20 Der erste Punkt ist unser laufendes Beispiel: Der Freitext einer Serviceanfrage landet ungefiltert im Kontext. Jeder, der eine Anfrage stellen darf, schreibt damit in den Kontext Ihres Agenten. Der zweite ist ein Entwurfsfehler, der leicht zu beheben ist — Anweisungen und Daten sind im Prompt nicht getrennt. Und der dritte ist der, den wir gleich in der Übung angreifen: Eine Werkzeugbeschreibung ändert sich später unbemerkt. Beim ersten Einbinden geprüft, danach nie wieder.

Tool Misuse und übermäßige Handlungsfähigkeit

4:49 Jetzt zu einer Angriffsart, die ohne jeden Einbruch auskommt — sie benutzt nur das, was erlaubt ist. Tool Misuse heißt, dass der Agent vorhandene Werkzeuge anders einsetzt als vorgesehen: mit Argumenten außerhalb des erwarteten Bereichs, in einer unerwarteten Reihenfolge, oder als Kette, die die Prüfungen der einzelnen Werkzeuge umgeht.

5:09 Das Tückische daran ist, dass jeder einzelne Schritt legitim ist. Es gibt keinen Moment, in dem eine Prüfung anschlagen müsste — die Prüfungen sind alle bestanden. OWASP hat für agentische Anwendungen eine eigene Zehnerliste. Fünf davon treffen einen MCP-basierten Entwicklungsworkflow unmittelbar: Goal Hijack, also die Manipulation des Ziels.

5:31 Tool Misuse. Der Missbrauch von Identität und Berechtigungen. Die Vergiftung von Gedächtnis und Kontext. Und kaskadierende Fehler. Ich empfehle, die vollständige Liste einmal zu lesen — nicht, um sie auswendig zu können, sondern um ein Gefühl dafür zu bekommen, wie breit das Feld inzwischen ist. Der erste Satz ist der Kern: Jedes Werkzeug für sich ist harmlos und geprüft. Die Verkettung erzeugt eine Wirkung, die keines allein hat.

5:58 Ein Werkzeug darf Anforderungen suchen, ein zweites darf einen Bericht entwerfen, ein drittes darf ihn versenden — und zusammen ergibt das einen Weg für Daten nach draußen. Der dritte Punkt beschreibt die Verstärkung: Ein vergifteter Zwischenstand beeinflusst alle folgenden Schritte. Und der vierte ist die Systemsicht: Kleine Fehler pflanzen sich über verbundene Systeme fort.

6:21 Der erste Punkt ist die Lücke im üblichen Vorgehen: Geprüft wird je Werkzeug, nie die Abfolge. Der zweite ist der konkrete Mechanismus dahinter — ein Zwischenergebnis wird ungeprüft als Eingabe des nächsten Aufrufs genutzt. Der dritte ist der, den wir in Modul 7 schon behandelt haben und der hier seine Sicherheitsbedeutung bekommt: Der Werkzeugsatz enthält alles, was jemals gebraucht wurde.

6:44 Und der vierte ist eine Begrenzung, die fast überall fehlt: Rücksprünge und Wiederholungen ohne Obergrenze.

Identität, Rechte und Datenabfluss

6:51 Bleibt der Bereich, in dem die klassischen Sicherheitsprobleme wiederkehren — mit neuen Namen und alter Wirkung. Das Confused-Deputy-Problem ist alt: Ein Dienst setzt seine eigenen Rechte im Auftrag eines anderen ein, ohne dessen Berechtigung zu prüfen. In der MCP-Welt trifft es Proxy-Server, die mit einer festen Client-Kennung gegenüber einem fremden Autorisierungsserver auftreten.

7:13 Die Spezifikation beschreibt den Ablauf im Detail — inklusive des Zustimmungs-Cookies, das der Angreifer mitbenutzt. Das Ergebnis: Der Angreifer bekommt Zugriff im Namen des Nutzers, ohne dass der je zugestimmt hätte. Vier Glieder, und die Kette ist kürzer, als man denkt. Ein Token wird ausgestellt. Es wird weitergereicht, weil es praktisch ist.

7:35 Damit entsteht ein Fremdzugriff, den das Zielsystem nicht als solchen erkennt. Und am Ende steht der Datenabfluss. Das entscheidende Glied ist das zweite — dort kann man die Kette unterbrechen, und genau dort setzt das Verbot des Token-Passthrough an, das wir in Modul 16 behandeln. Vier Wege, und nur der letzte ist offensichtlich. Rückgaben, die mehr enthalten als die Frage verlangte — das ist der häufigste und der unscheinbarste.

8:02 Protokolle, die Anfragetexte und Zugangsdaten mitschreiben; darüber haben wir in Modul 13 gesprochen. Fehlermeldungen, die interne Strukturen preisgeben — Modul 6. Und weitergereichte Token, die in fremden Systemen als gültig gelten. Drei von vier Wegen entstehen also nicht durch einen Angriff, sondern durch Großzügigkeit.

8:23 Der erste Punkt ist der, den die Spezifikation als State Handle Hijacking führt: Ein Zustandsbezeichner gilt als Nachweis der Identität. Die Regel dagegen ist eindeutig — der Besitz eines Handles ist keine Authentifizierung. Der zweite ist der Generalschlüssel, über den wir im nächsten Modul sprechen. Und der vierte ist ein Erkennungsproblem: Der Datenabfluss fällt nicht auf, weil niemand die Rückgaben misst.

8:48 Ein Werkzeug, das plötzlich das Zehnfache zurückgibt, würde auffallen — wenn jemand hinsähe.

Übung

8:54 Jetzt greifen wir unseren eigenen Server an. Und ich verspreche Ihnen: Der erste Angriff wird funktionieren. Zwei Teile. Erst das Bedrohungsmodell über alle vier Stationen — das ist die systematische Arbeit. Dann zwei konkrete Angriffe, einer über Inhalte und einer über die Beschreibung eines Werkzeugs. Der zweite wird oft ausgelassen, weil er unwahrscheinlich wirkt.

9:17 Er ist der, der in freier Wildbahn unter dem Namen Tool Poisoning läuft, und er ist alles andere als theoretisch. Angriff eins ist eine Serviceanfrage, deren Freitext den Agenten zum Abruf fremder Kostenstellen auffordert. Angriff zwei ist eine nachträglich geänderte Werkzeugbeschreibung. Führen Sie beide aus und dokumentieren Sie das Ergebnis. Zu jedem Fund gehören Wirkung, Eintrittswahrscheinlichkeit und die Gegenmaßnahme, die zuerst umgesetzt werden sollte.

9:45 Die Maßnahmen setzen wir dann im nächsten Modul tatsächlich um — und wiederholen den Angriff. Der erste Punkt ist der häufigste Fehler beim Threat Modeling: Bedrohungen werden gelistet ohne Bezug zu einer Station. Dann hat man eine Liste und keine Landkarte. Der zweite ist der, auf den es in diesem Seminar besonders ankommt: Die Gegenmaßnahme ist eine Anweisung im Prompt statt eine Prüfung im Server.

10:09 Wenn Sie das bei sich feststellen, haben Sie den Kernsatz aus Modul 1 noch vor sich. Im nächsten Modul setzen wir das um.