Points d'accès de métadonnées d'instance cloud : pourquoi les jetons IMDSv2 et une limite de saut de 1 atténuent le SSRF

Ce que c'est

Les fournisseurs cloud exécutent un service de métadonnées d'instance sur une adresse locale au lien, accessible depuis l'intérieur de chaque machine virtuelle. Sur AWS, il renvoie les détails de l'instance et, si un rôle IAM est attaché, des identifiants temporaires pour ce rôle. Tout processus capable d'émettre des requêtes HTTP depuis l'instance peut les demander.

AWS propose deux modes. IMDSv1 répond à de simples requêtes GET. IMDSv2 exige d'abord un jeton de session obtenu par une requête PUT ; la documentation précise que de telles requêtes PUT sont rejetées si elles contiennent un en-tête X-Forwarded-For, et que, par défaut, la réponse au PUT a une limite de saut (durée de vie IP) de 1.

Pourquoi c'est important

Un bug de falsification de requête côté serveur (SSRF), ou un agent doté d'un outil de récupération d'URL s'exécutant sur une VM cloud, peut être dirigé vers l'adresse de métadonnées. Avec IMDSv1, une seule requête GET peut renvoyer des identifiants. IMDSv2 relève la barre : un primitif SSRF typique ne peut envoyer que des requêtes GET avec des URL contrôlées par l'attaquant, pas un PUT avec un en-tête personnalisé, et la limite de saut de 1 empêche la réponse contenant le jeton d'atteindre un processus situé à un saut réseau de distance, comme un conteneur sur un réseau en pont.

Comment l'appliquer

• Exiger IMDSv2 sur toutes les instances (définir les jetons HTTP comme « required ») et vérifier que les SDK utilisés le prennent en charge ; AWS indique que les SDK actuels le font.
• Garder la limite de saut à 1, sauf si une charge de travail en conteneur a réellement besoin des métadonnées ; AWS mentionne les services de conteneurs comme la raison habituelle de l'augmenter. Préférer donner aux conteneurs leurs propres identifiants via l'orchestrateur.
• Donner aux rôles d'instance le moindre privilège nécessaire ; les permissions du rôle sont ce qu'un attaquant obtiendrait.
• Dans les défenses contre le SSRF et les outils de récupération des agents, bloquer les plages locales au lien et privées après résolution DNS, et ne pas suivre les redirections vers celles-ci.
• Alerter sur toute utilisation d'identifiants de métadonnées depuis l'extérieur de l'instance, ce que les journaux du fournisseur peuvent révéler.

Pièges

• Activer IMDSv2 en option ; IMDSv1 reste disponible tant que les jetons ne sont pas rendus obligatoires.
• Augmenter la limite de saut pour corriger un seul conteneur et l'exposer du même coup à tous les autres.
• Les autres clouds utilisent des en-têtes et des adresses différents ; vérifier la documentation de chaque fournisseur plutôt que de réutiliser les réglages AWS.