SSRF à travers une protection qui fait confiance au loopback pour atteindre un magasin KV interne

Réseau & Infrastructure Niveau 4/4 ~10 min 14 août 2026

Le défi

Ce récupérateur de health-check a une protection : il bloque les hôtes externes mais autorise volontiers le loopback, car "seuls des services internes y vivent". Cette supposition est le bug. Sondez l'interface loopback, suivez l'indice que le serveur laisse fuiter quand vous frappez à la mauvaise porte, et extrayez le flag du magasin clé-valeur interne vers lequel il vous oriente.

Connecte-toi pour essayer

Ce que tu vas apprendre

Comprendre pourquoi une protection SSRF qui autorise le loopback n'est pas une frontière de sécurité
Énumérer les services qui écoutent sur l'interface loopback via une primitive SSRF
Lire les réponses d'erreur pour repérer des détails internes fuités (nom du service, port, forme d'URL)
Pivoter d'un indice dans un 403 vers une API Consul KV interne et lire un secret stocké
Expliquer pourquoi une liste blanche positive de cibles et des services internes authentifiés sont les véritables correctifs

Compétences testées

Inspection de requêtes HTTP et manipulation en plusieurs étapes avec un éditeur de type proxyExploitation d'une SSRF contre des services internes protégés par une protection faibleLecture des réponses d'API pour découvrir une cible interne et pivoter vers elleComprendre les API d'infrastructure interne telles que Consul KV

Prérequis

Bonne compréhension des requêtes HTTP, des URL, des ports et de l'interface loopback
Familiarité avec la SSRF en tant que classe de vulnérabilité et sa capacité à atteindre des endpoints internes
Conscience que l'infrastructure interne (service mesh, magasins clé-valeur) expose des API HTTP

Comment ça marche

Il s'agit d'une server-side request forgery (SSRF) à plusieurs niveaux. Le récupérateur possède bien une protection, mais c'est une liste noire : elle rejette les hôtes externes et laisse passer tout ce qui se trouve sur le loopback, en partant du principe que seuls des services internes de confiance y vivent. Cette hypothèse est la vulnérabilité. Une liste noire d'hôtes externes ne dit rien de ce qui est co-localisé sur la machine, or les hôtes modernes font tourner beaucoup de choses : un agent de service mesh, un endpoint de métadonnées, une API admin, un magasin clé-valeur. Chacun d'eux devient accessible dès que le loopback est autorisé.

L'attaque n'est donc pas un simple basculement mais une petite chaîne de découverte. Sonder un chemin admin sur le loopback renvoie un 403, mais le corps de l'erreur en dit trop : il nomme un agent Consul sur le port 8500 et décrit la forme d'URL /v1/kv/<key> utilisée par ses secrets. L'API HTTP KV de Consul n'est pas authentifiée par défaut dans de nombreux déploiements, donc lister l'espace de clés puis lire /v1/kv/flag livre le secret stocké. Chaque étape n'est éclairée que par la réponse à la précédente : c'est ce qui en fait un exercice réaliste de découverte interne plutôt qu'un simple basculement d'un seul paramètre.

La cause profonde consiste à traiter où va une requête comme un indicateur de si elle est autorisée. Le loopback n'est pas une frontière de confiance, et les services internes qui supposent que le réseau les protège tombent dès qu'une SSRF les atteint.

Erreurs fréquentes

Essayer des URL externes et conclure que l'endpoint est sûr quand la protection les bloque, alors que tout l'intérêt est que le loopback reste autorisé.
Survoler le 403 sur /admin sans lire son corps, qui nomme pourtant l'agent Consul, son port et la forme d'URL du KV.
Supposer qu'une API d'infrastructure interne comme Consul KV nécessite une authentification, alors que son API HTTP est fréquemment exposée sans authentification sur le loopback.
Lire le listing du KV et s'arrêter là, au lieu de suivre la piste jusqu'à la clé /v1/kv/flag spécifique qui contient le secret.

Comment s'en protéger

Remplacez la liste noire par une liste blanche positive de cibles exactes et prévues, et ne traitez jamais le loopback comme intrinsèquement sûr. Combinez cela avec une authentification sur chaque service interne, afin qu'une simple accessibilité réseau ne suffise pas.

N'autorisez que les noms d'hôtes et chemins précis dont le récupérateur a légitimement besoin ; rejetez tout le reste, y compris le loopback et le link-local, sauf exigence explicite.
Résolvez puis revérifiez la destination après la résolution DNS pour contrer le rebinding, et interdisez les redirections vers des cibles non autorisées.
Exigez une authentification et des ACL sur les API internes : activez les ACL Consul, liez l'agent à une interface restreinte, et n'exposez jamais l'API KV sans jeton.
Rendez les réponses d'erreur génériques : ne laissez jamais fuiter de noms de services internes, de ports ou de schémas d'URL dans un corps d'erreur destiné au client.