Hack The Box : Comment MCP Inspector Transforme les Outils d'IA en un Nouveau Vecteur d'Attaque

La machine Kobold du Hack The Box Season 10 démontre un point important : les nouveaux risques autour de l'IA n'émergent pas seulement dans les modèles eux-mêmes, mais aussi dans les outils que les développeurs utilisent pour les maintenir. Dans cette analyse, le vecteur d'attaque initial se trouve dans MCP Inspector — un utilitaire dev pour les serveurs d'IA. La chaîne d'attaque se déploie alors selon un scénario familier de sécurité d'infrastructure : exécution de code, lecture de fichiers locaux dans le conteneur, réutilisation de credentials, et escalade de privilèges via Docker, jusqu'au compromis complet du système.

Kobold est positionnée comme une machine Easy, mais sa valeur réside non pas dans la complexité de l'exploitation, mais dans le réalisme de la chaîne de vulnérabilités. L'auteur montre comment un service de débogage et d'inspection de composants MCP peut soudainement devenir un périmètre externe. Pour les équipes construisant une pile d'IA à partir de serveurs, de connecteurs et d'outils auxiliaires, c'est un rappel inconfortable : tout ce qui est connecté au modèle et ayant accès à l'environnement local devient automatiquement partie de la surface d'attaque.

Et précisément ces éléments sont souvent moins bien protégés, car considérés comme internes, temporaires ou « réservés aux développeurs ». La première étape de la chaîne est RCE via MCP Inspector. Cette seule étape change déjà le tableau des menaces : un attaquant n'a pas besoin de casser l'application principale s'il y a un outil moins protégé à proximité avec des capacités étendues.

Après avoir obtenu l'exécution de code dans le conteneur, l'attaquant passe à LFI, c'est-à-dire la lecture de fichiers locaux. En pratique, ceci est l'une des étapes les plus productives de toute attaque sur des services conteneurisés : les configs, variables d'environnement, logs, clés, tokens de service et artefacts de construction se trouvent souvent dans des emplacements prévisibles. Même si les secrets ne sont pas divulgués directement, l'exposition de la structure des répertoires, des noms de services ou des adresses internes aide déjà à accélérer la progression ultérieure.

Le point important suivant est la réutilisation des credentials. Dans les projets d'IA, c'est un problème particulièrement courant : les équipes lancent rapidement des services expérimentaux, copient des fichiers .env, dupliquent les mots de passe entre conteneurs et laissent des credentials identiques pour différents rôles.

Dans l'analyse, précisément la réutilisation des secrets aide à la transition de l'accès local aux composants système plus sensibles, puis utilise les erreurs de configuration Docker pour l'escalade de privilèges. Le matériel montre deux chemins indépendants vers le contrôle complet de la machine, soulignant le point principal : si un attaquant a déjà du code à l'intérieur du conteneur, alors une socket Docker, des capacités supplémentaires, des montages non sécurisés et un accès trop large aux ressources d'hôte transforment rapidement le conteneur d'une barrière en un point intermédiaire pratique. Il est particulièrement utile que l'auteur mappe l'attaque vers MITRE ATT&CK.

Une telle analyse transforme la compromission étape par étape de la machine en matériel pratique pour les défenseurs : vous voyez non seulement la séquence d'actions, mais aussi les classes de techniques — exécution initiale, découverte, collecte, accès aux credentials, mouvement latéral et escalade de privilèges. Cela aide les équipes blue et DevSecOps à aligner le scénario de laboratoire avec les logs réels, les alertes et les mesures de détection.

La thèse principale s'étend bien au-delà d'une seule machine : l'écosystème MCP, y compris les inspecteurs, proxies, connecteurs et ponts locaux vers les fichiers, réseaux et secrets, devient une nouvelle surface d'attaque précisément parce qu'il existe à l'intersection de plusieurs zones de confiance. Qu'est-ce que cela signifie en pratique ? Pour les équipes construisant des services d'IA, il ne suffit plus de protéger seulement l'API du modèle et l'interface utilisateur.

Vous devez sortir les outils dev de l'accès public, activer l'authentification même pour les utilitaires « internes », interdire la réutilisation des credentials, réduire les privilèges du conteneur, auditer les configurations Docker et enregistrer les actions autour des composants MCP aussi attentivement qu'autour des services de production primaires. Kobold excelle parce que, sans excès de théorie, elle montre : le prochain incident grave dans une pile d'IA peut commencer non pas avec le modèle, mais avec un petit outil utilitaire que personne ne considérait comme critique.