Métadonnées cloud : la surface d'attaque cachée

Chaque grand fournisseur cloud expose un service de métadonnées d'instance aux machines virtuelles qui s'exécutent sur sa plateforme, en général accessible à l'adresse de lien local 169.254.169.254. Depuis l'intérieur de l'instance, une simple requête HTTP vers cette adresse peut renvoyer la configuration de l'instance, des informations réseau et, dans de nombreuses configurations par défaut, des identifiants de sécurité temporaires associés au rôle ou à l'identité attribué à l'instance.

Pourquoi c'est particulièrement dangereux combiné à une SSRF

Le point de terminaison de métadonnées n'est censé être joignable que depuis l'instance elle-même : il n'est pas exposé à l'internet public. Mais si un processus côté serveur peut être amené à émettre une requête HTTP vers une adresse choisie par un attaquant (SSRF classique), et que cette adresse se trouve être le point de terminaison de métadonnées, l'attaquant fait récupérer au serveur ses propres identifiants cloud et les lui fait renvoyer dans la réponse. Aucun accès réseau direct au point de terminaison de métadonnées n'est nécessaire depuis l'extérieur : le serveur vulnérable effectue la récupération pour le compte de l'attaquant.

• 169.254.169.254 fait partie de la plage de lien local plus large 169.254.0.0/16, qui ne devrait jamais être traitée comme une cible légitime de résolution DNS publique.
• Certains fournisseurs sont passés à une version du service de métadonnées protégée par jeton, précisément pour compliquer les SSRF les plus naïves, mais bloquer purement et simplement l'adresse au niveau applicatif reste la défense la plus robuste.
• C'est exactement pourquoi les adresses de lien local doivent figurer sur la même liste de blocage que les plages privées et de bouclage dans tout outil qui résout des domaines fournis par l'utilisateur : ce n'est pas une catégorie de risque distincte ni secondaire.

L'enseignement à retenir en pratique

Tout système qui résout et appelle une URL pour le compte d'un utilisateur doit considérer 169.254.169.254, ainsi que toute la plage de lien local dans laquelle elle se trouve, comme strictement interdite. La vérification doit avoir lieu au moment de la requête réelle, à chaque fois, quelle que soit la manière dont l'adresse a été obtenue (saisie directement, ou atteinte via un enregistrement DNS qui pointe droit dessus).

Ce n'est pas propre à un seul fournisseur cloud

L'adresse 169.254.169.254 est précisément la convention d'AWS, de Google Cloud et d'Azure, mais le schéma sous-jacent, une adresse de lien local qui expose l'identité et les identifiants de l'instance à elle seule, se retrouve sous une forme ou une autre sur pratiquement toutes les grandes plateformes cloud et de conteneurs, parfois à la même adresse, parfois à une adresse propre au fournisseur. Les clusters Kubernetes disposent couramment de leurs propres points de terminaison internes de type métadonnées, accessibles depuis l'intérieur d'un pod. Il vaut la peine de mémoriser l'adresse exacte pour les principaux fournisseurs cloud, mais c'est le principe général qui se généralise vraiment : considérez tout point de terminaison de type métadonnées comme interdit à tout ce qui résout et récupère une URL fournie par l'utilisateur, quelle que soit la plateforme sur laquelle il s'exécute.

IMDSv2 : une vraie mesure d'atténuation, pas un simple filtre

La réponse d'AWS à des années d'exploitation de ce schéma précis a été une seconde version de son service de métadonnées, IMDSv2, qui exige un jeton de session obtenu via une requête PUT spécifique avant de pouvoir lire la moindre métadonnée. Point essentiel : cette requête PUT ne peut pas être reproduite par la simple requête GET que déclenche une SSRF et qu'émettent la plupart des chemins de code vulnérables.

C'est une amélioration significative, mais elle est facultative sur de nombreux comptes pour des raisons de rétrocompatibilité, et elle ne protège que le point de terminaison de métadonnées : elle ne fait rien contre toutes les autres adresses privées et internes qu'une SSRF pourrait encore atteindre. Le filtrage applicatif des adresses résolues reste nécessaire quelle que soit la version du service de métadonnées utilisée.