Qu'est-ce que le service de métadonnées d'instance (IMDS) et comment IMDSv2 atténue-t-il la SSRF ?
Réponse courte
IMDS est un point d'accès link-local (169.254.169.254) qui fournit à une instance ses métadonnées, dont les identifiants temporaires de son rôle IAM attaché. La SSRF peut tromper le serveur pour qu'il récupère cette URL et fasse fuiter ces identifiants. IMDSv2 exige un PUT pour obtenir un jeton de session à courte durée de vie, définit une limite de saut (hop limit) / TTL IP par défaut de 1, et rejette les requêtes avec certains en-têtes — si bien qu'un simple GET de SSRF ne peut plus l'atteindre.
C'est une question cloud senior favorite car elle relie une vulnérabilité web (SSRF) à une attaque cloud-native (vol d'identifiants) — et le correctif est élégant.
Ce que fait IMDS
Chaque instance peut interroger une adresse link-local, 169.254.169.254, pour lire ses propres métadonnées : région, ID d'instance, réseau et — surtout — les identifiants temporaires du rôle IAM qui lui est attaché. Les applications l'utilisent pour ne jamais avoir besoin de clés statiques. Le problème : le point d'accès fait confiance à toute requête provenant de l'instance.
Pourquoi la SSRF est si dangereuse ici
Dans une attaque par falsification de requête côté serveur (SSRF), un attaquant contraint l'application à effectuer une requête HTTP vers une URL choisie par lui. S'il la pointe vers http://169.254.169.254/latest/meta-data/iam/security-credentials/..., le serveur récupère les identifiants du rôle et les renvoie. L'attaquant détient alors des identifiants cloud valides, limités au rôle — la fuite Capital One en est l'exemple canonique.
Comment IMDSv2 la comble
IMDSv1 répondait à un simple GET, ce qui est exactement ce que produit une SSRF. IMDSv2 est orienté session :
- Le client doit d'abord émettre un
PUTpour obtenir un jeton de session à courte durée de vie, puis envoyer ce jeton dans un en-tête à chaque lecture. La plupart des primitives de SSRF ne peuvent effectuer que de simplesGET, donc elles ne peuvent pas compléter la poignée de main. - La limite de saut (TTL IP) de réponse par défaut est de 1, si bien que la réponse ne peut pas traverser un proxy de transfert ni s'échapper de l'espace de noms réseau d'un conteneur pour atteindre un attaquant externe.
- Les requêtes portant un en-tête
X-Forwarded-Forsont rejetées, bloquant l'abus de proxy ouvert.
Imposez IMDSv2 uniquement au lancement (et à l'échelle du compte via politique), et restreignez tout de même le rôle de l'instance pour qu'une fuite ait un rayon d'impact minimal.
Ce que recherchent les recruteurs
Connaître l'IP de métadonnées, le fait qu'elle serve des identifiants de rôle, le lien avec la SSRF, et précisément pourquoi la conception jeton PUT plus limite de saut la déjoue.
Questions de suivi probables
- Pourquoi une limite de saut par défaut de 1 casse-t-elle la SSRF à travers un conteneur ou un proxy ?
- Comment imposeriez-vous IMDSv2 uniquement sur l'ensemble d'un compte ?
- Quel rayon d'impact a un identifiant de rôle d'instance fuité, et comment le limiter ?