MCP Command Injection

Was ist MCP Command Injection?

Ein MCP-Tool läuft auf einem Server; jedes Argument, das es erhält, ist daher nicht vertrauenswürdig. Wird die Eingabe in eine Shell-Befehlszeichenfolge eingefügt, wird ein Semikolon oder Backtick vom Datenzeichen zur Befehlssyntax und der Server führt den Befehl aus. Sie finden das eingeschleuste Argument im Agent-Trace und sehen, wie das Tool ein gewöhnliches leeres Ergebnis zurückgibt, während über eine als root laufende Reverse-Shell Datenbankzugangsdaten ausgelesen werden. Anschließend rufen Sie git direkt auf, ohne eine Shell dazwischenzuschalten. Eine Codekorrektur macht bereits ausgeführten Code nicht rückgängig.

Was Sie lernen in MCP Command Injection

• Erkennen Sie, dass ein MCP-Tool auf einem Server läuft und daher jedes Argument, aus dem es einen Befehl erstellt, nicht vertrauenswürdig ist und Code enthalten kann.
• Erklären Sie, wie durch das Einfügen von Eingaben in eine Shell-Befehlszeichenfolge Metazeichen wie ; und | als Befehlssyntax interpretiert werden und so Remotecodeausführung ermöglichen.
• Verstehen Sie, dass ein eingeschleuster Befehl unabhängig von der Tool-Antwort ausgeführt wird und eine unauffällige Antwort daher nicht beweist, dass nichts passiert ist.
• Wenden Sie die dauerhafte Lösung an: Rufen Sie das Programm direkt auf und übergeben Sie jeden Wert als separates Argument, ohne dass eine Shell ihn interpretiert.
• Unterscheiden Sie Parametrisierung von Escaping und Blocklisten. Erklären Sie, warum das Entfernen der Shell die gesamte Fehlerkategorie und nicht nur einen einzelnen Fall beseitigt.
• Belegen Sie die Codekorrektur, indem Sie den ursprünglichen Exploit erneut ausführen. Erkennen Sie außerdem, dass bei einem Host, auf dem bereits Angreifercode lief, die Zugangsdaten rotiert und der Host neu aufgesetzt werden muss.

MCP Command Injection — Trainingsschritte

1. Ein Tool, das Git ausführt

   Sarnholt betreibt einen öffentlichen Repository-Assistenten. Eines seiner Tools, commit_search, sucht in der Commit-Historie nach dem Autor. Bob weiß nicht, wie es implementiert ist, aber ein Tool, das Git anhand eines von ihm angegebenen Namens durchsucht, ist einen Versuch wert. Er öffnet denselben Agenten, den jeder verwenden kann.

2. Sehen Sie, wie es funktioniert

   Zuerst eine normale Anfrage, um zu erfahren, was das Tool mit dem ihm gegebenen Namen macht. Der eingegebene Autor kommt als Git-Abfrage zurück. Git ist ein Kommandozeilen-Tool, daher wird dieser Name mit ziemlicher Sicherheit irgendwo auf dem Server in einen Git-Befehl eingesetzt. Geschieht das als Text, kann Bob den Befehl erweitern.

3. Der Name landet irgendwo

4. Argument beenden, Befehl anhängen

   Bob fragt nach Commits eines Autors, dessen „Name“ kein echter Name ist. Er beendet den Git-Befehl mit einem Semikolon und hängt einen eigenen Befehl an: Er ruft ein Skript von seinem Server ab und führt es aus.

5. Die unauffällige Antwort verbarg den Schaden

   Die Antwort des Assistenten ist unauffällig: Es wurden keine Commits gefunden. Das ist der Punkt. Der eingefügte Befehl meldet sich nicht über das Tool zurück, sondern läuft unbemerkt auf dem Server.

6. Eine Shell auf dem Server

   Das Skript von Bobs Server stellte eine direkte Verbindung zu seinem Listener her. Bob wechselt dorthin, um zu sehen, was ihm ein commit_search-Aufruf eingebracht hat. Das Tool hat genau das getan, was sein Code vorgibt. Die Frage ist, was in diesem Code ein Argument in einen Befehl verwandelt hat.

7. Warum es funktioniert hat

8. Eine unerwartete Shell

   Alice wird vom Sicherheitsteam alarmiert. Bei der Warnung geht es nicht um eine Anmeldung oder eine Datei, sondern um einen Prozess.

9. Was der Alarm anzeigt

   Der Alarm grenzt die Ursache auf ein Tool und eine bestimmte Eingabeform ein.

10. Der Aufruf im Trace

    Der Agent protokolliert jeden Tool-Aufruf. Darunter ist auch der manipulierte Aufruf.