Injection de commandes MCP

Qu'est-ce que Injection de commandes MCP?

Un outil MCP s'exécute sur un serveur, donc chaque argument qu'il reçoit est une entrée non fiable. Créez une commande shell en collant cette entrée dans une chaîne et un point-virgule ou un backtick cesse d'être des données : cela devient une commande exécutée par votre serveur. Vous trouverez l'argument injecté dans une trace d'agent, regarderez l'outil renvoyer un résultat vide ordinaire pendant qu'un shell inverse racine effectue les informations d'identification de la base de données, puis appelez git directement sans shell dans le chemin. Un correctif de code n’annule pas le code déjà exécuté.

Ce que vous apprendrez dans Injection de commandes MCP

• Reconnaître qu'un outil MCP s'exécute sur un serveur, donc tout argument qu'il utilise pour créer une commande est une entrée non fiable pouvant contenir du code
• Expliquez comment la concaténation d'une entrée dans une chaîne de commande shell transforme les métacaractères comme ; et | dans la syntaxe de commande, produisant l'exécution de code à distance
• Comprenez qu'une commande injectée s'exécute hors bande, donc une réponse d'outil d'apparence normale ne prouve pas que rien ne s'est passé
• Appliquez le correctif durable : appelez le programme directement et transmettez chaque valeur en tant qu'argument distinct, sans aucun shell pour l'interpréter.
• Distinguer le paramétrage de l'échappement ou de la liste de blocage, et expliquer pourquoi la suppression du shell élimine la catégorie de bogue plutôt qu'une instance
• Prouvez un correctif de code en relisant l'exploit d'origine et reconnaissez qu'un hôte qui a déjà exécuté le code de l'attaquant doit voir ses secrets alternés et être reconstruit.

Injection de commandes MCP — Étapes de la formation

1. Un outil qui exécute Git

   Sarnholt dirige un assistant de pension publique. L'un de ses outils, commit_search, recherche les commits par auteur. Bob ne sait pas comment c'est écrit, mais un outil qui recherche git par un nom qu'il fournit vaut la peine d'être étudié. Il ouvre le même agent que tout le monde peut utiliser.

2. Voyez-le fonctionner

   D'abord une requête normale, pour savoir ce que fait l'outil avec le nom qui lui est donné.

3. Le nom finit quelque part

   L'auteur qu'il tape revient sous forme de requête git. Git est un outil en ligne de commande, donc quelque part sur le serveur, ce nom est presque certainement placé dans une commande git. S'il est placé sous forme de texte, Bob peut l'ajouter à la commande.

4. Fermez l'argument, ajoutez une commande

   Bob demande des commits à un auteur dont le nom n'est pas un nom. Il termine la commande git par un point-virgule et ajoute le sien : récupérez un script sur son hôte et exécutez-le.

5. La réponse ennuyeuse a caché les dégâts

   La réponse de l'assistant est banale : aucun commit ne correspond. C'est là le point. La commande injectée ne renvoie pas de rapport via l'outil, elle s'exécute silencieusement sur le serveur.

6. Un Shell sur le serveur

   Le script que le serveur de Bob a rendu a ouvert une connexion directement avec son auditeur. Il y passe pour voir ce qu'un appel commit_search lui a acheté.

7. Pourquoi ça a marché

   L’outil a fait exactement ce que son code lui demandait de faire. La question est de savoir ce qui, dans ce code, a transformé un argument en commande.

8. Une coquille là où il ne devrait pas y en avoir

   Alice est bipée par l'équipe de sécurité. L'alerte ne concerne pas une connexion ou un fichier, mais un processus.

9. Ce que l’alerte indique

   L’alerte l’a réduit à un seul outil et une seule forme de saisie.

10. L'appel dans la trace

    L'agent conserve une trace de chaque appel d'outil. L'empoisonné est dedans.