Le jeton nomme l'hôte : reconnaissance à partir d'un JWT de service capturé
Le défi
Vous avez capturé un JWT de service à service sur un réseau interne. Il est censé être opaque, mais la charge utile d'un JWT n'est que du base64 et se décode sans aucune clé. L'une de ses revendications nomme discrètement un système interne avec lequel le service est autorisé à communiquer. Décodez la charge utile dans l'atelier et soumettez ce nom d'hôte interne.
Ce que tu vas apprendre
- Comprendre que la charge utile d'un JWT se décode en revendications en clair, sans clé
- Identifier les revendications iss, aud et scope dans un jeton de service
- Extraire un nom d'hôte interne à partir de la revendication audience
- Expliquer comment des jetons capturés révèlent des informations sur l'environnement
- Reconnaître pourquoi les jetons de service doivent être éphémères et transmis sur des canaux chiffrés
Compétences testées
Prérequis
- Un JWT est composé de trois parties en base64url : en-tête, charge utile, signature
- Des revendications standard comme iss et aud transportent l'émetteur et l'audience
Comment ça marche
L'authentification de service à service utilise souvent des JWT, et comme tout JWT, la charge utile est encodée en base64url, pas chiffrée. Quiconque capture le jeton (en sniffant le trafic interne, en lisant un log ou en le récupérant dans une configuration) peut décoder les revendications instantanément, sans clé.
Décoder ce jeton donne {"iss":"auth.acme","aud":"vault.internal.acme","scope":"read"}. Les revendications standard sont une mine d'or pour la reconnaissance : iss (émetteur) nomme le serveur d'authentification, scope indique ce que le détenteur peut faire, et aud (audience) nomme le service auquel le jeton est destiné. Ici, l'audience est vault.internal.acme, un nom d'hôte interne qu'un attaquant externe n'aurait aucun autre moyen d'apprendre. Cette seule chaîne lui indique qu'un coffre-fort de secrets existe, comment il s'appelle, et qu'un chemin y mène sur le réseau.
Aucune falsification n'est nécessaire pour ce type de fuite. La valeur d'un jeton capturé tient en partie à l'accès qu'il accorde et en partie au renseignement qu'il transporte : noms d'hôtes, points de terminaison, identifiants de compte et portées qui cartographient l'environnement pour la prochaine étape.
Erreurs fréquentes
- Traiter le jeton comme s'il était chiffré. C'est du base64, décodez-le directement, sans clé ni cassage nécessaire.
- Lire l'émetteur au lieu de l'audience.
issvautauth.acme; l'hôte interne recherché est la revendicationaud. - Ajouter un schéma ou un chemin. La réponse est le nom d'hôte brut
vault.internal.acme, pas une URL. - Essayer de falsifier le jeton. Il s'agit d'une tâche de reconnaissance en lecture seule ; rien n'est à modifier.
Comment s'en protéger
Considérez que chaque revendication d'un jeton de service peut être lue par quiconque l'intercepte, et minimisez ce qu'elle révèle.
- Ne transmettez les jetons que sur TLS pour qu'ils ne puissent pas être capturés directement sur le réseau.
- Gardez les jetons de service éphémères et strictement limités en portée, afin qu'un jeton capturé devienne vite inutile.
- Évitez de placer des noms d'hôtes internes sensibles ou des indices de topologie dans les revendications lorsqu'un identifiant opaque suffirait.
- Surveillez l'utilisation de jetons depuis des sources inattendues, ce qui peut signaler une capture suivie d'un rejeu.