IMDSv1 : comment une faille web banale devient la compromission d’un compte cloud

En 2019, une attaquante a extrait plus de cent millions de dossiers clients d’une grande banque américaine. Pas de malware, pas de mot de passe volé. Une faille de configuration dans un pare-feu applicatif, une requête vers une adresse locale, et les identifiants d’un rôle trop large. Ce scénario reste aujourd’hui l’un des plus fréquents sur les comptes cloud, et l’un des plus simples à fermer.

Ce qu’est le service de métadonnées

Chaque instance d’un cloud peut interroger une adresse locale (169.254.169.254 chez AWS, avec des équivalents chez les autres fournisseurs) pour connaître son identité, sa configuration, et surtout les identifiants temporaires du rôle qui lui est attaché. C’est ainsi qu’une application lit un bucket ou une base sans mot de passe en dur : elle demande ses identifiants au service de métadonnées.

Ce mécanisme est indispensable. Le problème, c’est à qui il répond.

IMDSv1 : une requête GET suffit

Dans sa première version, le service répond à n’importe quelle requête GET venant de l’instance. Toute chose capable de faire une requête HTTP depuis la machine obtient les identifiants : l’application, mais aussi un attaquant qui contrôle l’URL qu’elle appelle.

C’est le rôle de la SSRF (Server-Side Request Forgery), une faille web ordinaire : l’application accepte une adresse fournie par l’utilisateur et va la chercher elle-même. Un champ « URL de votre avatar », un proxy d’images, un webhook de test, un convertisseur de documents. L’attaquant fournit l’adresse locale du service de métadonnées, l’application la visite, et renvoie les identifiants dans sa réponse.

Avec ces identifiants, l’attaquant agit comme la machine, depuis n’importe où, jusqu’à leur expiration. Si le rôle de la machine peut lister et lire des buckets, il lit les buckets. S’il peut assumer d’autres rôles, il monte.

IMDSv2 : un jeton et une limite de sauts

La seconde version du service corrige précisément cela. Il faut d’abord obtenir un jeton de session par une requête PUT, avec un en-tête dédié, puis présenter ce jeton à chaque requête. Deux détails rendent la SSRF inopérante.

• Une SSRF classique ne sait faire que des GET avec les en-têtes de l’application : elle ne peut pas obtenir le jeton.
• La réponse au PUT porte une limite de sauts réseau de 1 par défaut : elle ne traverse pas un conteneur, un proxy ou une couche de routage intermédiaire.

Imposer IMDSv2 sur une instance se fait en un paramètre : « jetons de métadonnées : obligatoires ». Les autres clouds ont leurs équivalents, et la plupart des agents et bibliothèques modernes utilisent la version 2 d’eux-mêmes.

Pourquoi c’est encore partout

Parce que l’option est par défaut « facultative » sur beaucoup d’images anciennes, parce que la migration demande de vérifier que rien d’ancien n’appelle encore la version 1, et parce qu’un paramètre d’instance ne figure dans aucun tableau de bord de sécurité applicative. L’équipe web ne le voit pas, l’équipe infrastructure ne sait pas quelle application tourne dessus.

Comment vérifier

1. Listez les instances dont les jetons de métadonnées sont « facultatifs ».
2. Croisez avec l’exposition : lesquelles ont une adresse publique, ou sont derrière un équilibreur public.
3. Croisez avec le rôle attaché : lesquelles peuvent atteindre des données, des clés, d’autres rôles.
4. Commencez par celles qui cumulent les trois. Imposez la version 2 sur tout le reste au fil des redéploiements.

C’est exactement une combinaison toxique : une instance publique, IMDSv1, un rôle qui lit des données sensibles. Chaque élément est un réglage de routine ; ensemble, c’est l’affaire de 2019. Dans Ctadel, cette chaîne fait partie du catalogue des chemins d’attaque, avec les trois corrections possibles dans l’ordre du moindre effort. La page Chemins d’attaque décrit comment elle est évaluée.