Pivoter sur trois hôtes pour récupérer un token vault et le flag
Le défi
Vous avez un point d'appui sur web01 dans un réseau interne. Un coffre de secrets se trouve quelque part sur le même sous-réseau, mais vous ne pouvez pas l'atteindre directement. Scannez le réseau, pivotez via l'hôte intermédiaire avec la clé que vous trouvez, récupérez le jeton du coffre et lisez le drapeau renvoyé par le coffre.
Ce que tu vas apprendre
- Cartographier un sous-réseau interne avec nmap pour identifier les hôtes et ports accessibles
- Repérer et réutiliser une clé privée SSH divulguée pour pivoter vers un autre hôte
- Récupérer un token de service dans les notes de déploiement et l'historique d'un hôte
- S'authentifier auprès d'une API HTTP via un en-tête de token pour lire un secret
- Expliquer pourquoi la segmentation réseau seule échoue quand des clés et des tokens fuitent
Compétences testées
Prérequis
- À l'aise avec ssh, nmap, curl et les commandes shell de base
- Comprendre comment une clé privée SSH authentifie une connexion
- Savoir qu'un token d'API est transmis dans un en-tête de requête
Comment ça marche
Les réseaux internes réels sont en couches. L'hôte sur lequel vous atterrissez en premier est rarement celui qui détient le trésor, c'est un tremplin. Ici, web01 se trouve dans la DMZ et peut communiquer avec la couche applicative, mais le coffre de secrets sur vault03 n'accepte que les requêtes qui portent déjà un token valide, et ce token est censé résider sur la couche applicative, jamais sur le nœud web. Le défi consiste à se déplacer de l'endroit où vous êtes vers l'endroit où se trouve le secret.
Le premier mouvement est la reconnaissance. nmap sur le segment 10.0.0.0/24 révèle trois hôtes actifs : votre point d'appui, app02 avec SSH ouvert sur le port 22, et vault03 avec l'API du coffre sur le port 8200. Interroger directement le coffre renvoie 403 missing client token : vous pouvez l'atteindre sur le réseau, mais vous n'avez pas d'identifiant. La voie à suivre passe par l'hôte intermédiaire, et la clé pour y accéder se trouve sur le disque : une clé privée de déploiement sous /var/www/deploy/.ssh/id_rsa qui authentifie en tant que deploy@app02.
Une fois le pivot effectué avec ssh -i, la couche applicative livre la pièce manquante. Le runbook de déploiement sur app02 documente l'appel API exact, token compris : curl -H "X-Vault-Token: s.7Hk2mQ9pZ" http://10.0.0.30:8200/v1/secret/data/flag. L'historique du shell confirme que l'opérateur l'a exécuté de la même manière. Rejouer cette requête depuis la couche applicative renvoie le flag. Tout l'exercice est une chaîne : scan, pivot, récupération du token, authentification, où chaque maillon n'est accessible qu'après le précédent.
Erreurs fréquentes
- Essayer de faire un curl vers le coffre depuis web01. Le coffre répond
403 missing client tokenà cet endroit : il vous faut le token, et le token ne se trouve jamais sur le nœud web. - Sauter le scan réseau. Sans
nmap, vous ne savez pas que app02 a SSH ouvert ni même que vault03 existe ; deviner gaspille tout l'exercice. - Ignorer la clé SSH présente sur le disque. La clé de déploiement sous
/var/www/deploy/.ssh/id_rsaest le seul moyen d'accéder à app02 : le pivot est obligatoire, pas optionnel. - Oublier l'en-tête du token. Un simple
curlvers le coffre échoue toujours depuis app02 ; la requête doit porterX-Vault-Tokenpour être autorisée.
Comment s'en protéger
La segmentation a ralenti l'attaquant mais ne l'a pas arrêté, car les clés et les tokens qui traversent les segments sont restés lisibles. Les corrections renforcent chaque maillon de la chaîne :
- Ne jamais stocker une clé privée SSH longue durée dans un répertoire web lisible par tous : délivrez des identifiants SSH éphémères, basés sur des certificats, limités à un unique bastion.
- Ne laissez pas les tokens du coffre traîner dans les notes de déploiement ou l'historique du shell : injectez-les au moment de l'exécution et utilisez des TTL courts pour qu'un token divulgué expire rapidement.
- Restreignez le coffre pour qu'il n'accepte les tokens que d'identités clientes approuvées, pas de n'importe qui sur le sous-réseau qui détient la chaîne.
- Surveillez les connexions SSH latérales et les lectures inhabituelles du coffre pour qu'un pivot depuis la DMZ vers la couche applicative déclenche une alerte.
Traitez tout token trouvé sur disque ou dans l'historique comme compromis : révoquez-le, faites tourner la clé de déploiement, et vérifiez ce que cette identité pouvait atteindre.
