MCP-Befehlsinjektion

Was ist MCP-Befehlsinjektion?

Ein MCP-Tool läuft auf einem Server, sodass jedes empfangene Argument eine nicht vertrauenswürdige Eingabe ist. Erstellen Sie einen Shell-Befehl, indem Sie diese Eingabe in eine Zeichenfolge einfügen und ein Semikolon oder Backtick keine Daten mehr sind: Es wird zu einem Befehl, den Ihr Server ausführt. Sie finden das eingefügte Argument in einem Agenten-Trace, beobachten, wie das Tool ein gewöhnliches leeres Ergebnis zurückgibt, während eine Root-Reverse-Shell Datenbankanmeldeinformationen ausführt, und rufen dann git direkt ohne Shell im Pfad auf. Eine Codekorrektur macht Code, der bereits ausgeführt wurde, nicht rückgängig.

Was Sie lernen in MCP-Befehlsinjektion

• Beachten Sie, dass ein MCP-Tool auf einem Server ausgeführt wird. Daher handelt es sich bei allen Argumenten, die es zum Erstellen eines Befehls verwendet, um nicht vertrauenswürdige Eingaben, die Code übertragen können
• Erklären Sie, wie durch die Verkettung von Eingaben in eine Shell-Befehlszeichenfolge Metazeichen wie „;“ umgewandelt werden. und | into command syntax, producing remote code execution
• Beachten Sie, dass ein injizierter Befehl außerhalb des Bandes ausgeführt wird, sodass eine normal aussehende Tool-Antwort kein Beweis dafür ist, 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 interpretieren muss
• Unterscheiden Sie Parametrisierung von Escape oder Blocklisting und erklären Sie, warum durch das Entfernen der Shell die Kategorie des Fehlers und nicht nur eine Instanz beseitigt wird
• Beweisen Sie eine Code-Korrektur, indem Sie den ursprünglichen Exploit erneut abspielen, und erkennen Sie, dass die Geheimnisse eines Hosts, auf dem bereits Angreifercode ausgeführt wurde, rotiert und neu erstellt werden müssen

MCP-Befehlsinjektion — Trainingsschritte

1. Ein Tool, das Git ausführt

   Sarnholt leitet einen öffentlichen Repo-Assistenten. Eines seiner Tools, commit_search, sucht nach Commits nach Autor. Bob weiß nicht, wie es geschrieben ist, aber ein Tool, das Git anhand eines von ihm angegebenen Namens durchsucht, ist eine Prüfung wert. Er öffnet den gleichen 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.

3. Der Name landet irgendwo

   Der von ihm eingegebene Autor kommt als Git-Abfrage zurück. Git ist ein Befehlszeilentool, daher wird dieser Name mit ziemlicher Sicherheit irgendwo auf dem Server in einen Git-Befehl eingefügt. Wenn es dort als Text abgelegt wird, kann Bob den Befehl ergänzen.

4. Schließen Sie das Argument und fügen Sie einen Befehl hinzu

   Bob bittet um Zusagen eines Autors, dessen Name kein Name ist. Er beendet den Git-Befehl mit einem Semikolon und hängt sein eigenes an: Holt ein Skript von seinem Host und führt es aus.

5. Die langweilige 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 von Bobs Server zurückgegebene Skript öffnete eine direkte Verbindung zu seinem Zuhörer. Er wechselt dorthin, um zu sehen, was ihm ein commit_search-Aufruf gebracht hat.

7. Warum es funktioniert hat

   Das Tool hat genau das getan, was sein Code vorgab. Die Frage ist, was in diesem Code ein Argument in einen Befehl verwandelt hat.

8. Eine Hülle, wo keine sein sollte

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

9. Was der Alarm anzeigt

   Die Warnung hat es auf ein Tool und eine Eingabeform eingegrenzt.

10. Der Ruf in der Spur

    Der Agent zeichnet jeden Werkzeugaufruf auf. Der Vergiftete ist darin.