Voler les identifiants du rôle d'instance depuis le service de métadonnées

Les instances cloud fonctionnent souvent avec un rôle attaché afin que l'application puisse appeler des services cloud sans que personne n'ait à coder en dur des clés à longue durée de vie. La plateforme délivre les identifiants temporaires de ce rôle via une adresse link-local spéciale, 169.254.169.254, accessible uniquement depuis l'instance elle-même. Le code qui a besoin d'un identifiant interroge ce service de métadonnées au démarrage et lors des rafraîchissements. C'est pratique et sans clé, ce qui en fait justement une cible de choix.

N'importe quel processus sur l'instance, y compris un shell dans lequel un attaquant vient d'atterrir, peut atteindre la même adresse. Parcourir le chemin est mécanique : iam/security-credentials/ liste le nom du rôle, ici s3-backup-role, et interroger iam/security-credentials/s3-backup-role renvoie un document JSON contenant un AccessKeyId, un SecretAccessKey et un Token à courte durée de vie. Quiconque lit ce JSON détient désormais les mêmes permissions que celles accordées à l'instance.

La dernière étape transforme ces identifiants en butin. Les notes de l'instance mentionnent une sauvegarde vers un bucket de secrets via le point de stockage interne à 10.0.0.40. Envoyer le Token volé en tant qu'en-tête X-Instance-Token vers http://10.0.0.40/s3/acme-secrets/flag.txt authentifie la requête et renvoie le flag. La chaîne (shell, token de métadonnées, lecture authentifiée du stockage) est l'un des chemins d'escalade cloud les plus courants, et elle fonctionne parce qu'un point d'ancrage sur l'hôte hérite du rôle de l'hôte.

• Interroger le point de stockage sans token. 10.0.0.40 renvoie 403 missing or invalid x-instance-token tant que vous ne fournissez pas le token de métadonnées en en-tête.
• Deviner le nom du rôle. Le rôle n'est pas arbitraire, il est listé sous iam/security-credentials/ sous le nom s3-backup-role ; il faut le lire, pas l'inventer.
• Récupérer le mauvais champ. Le point de terminaison attend la valeur Token, pas l'AccessKeyId ni le SecretAccessKey.
• Essayer l'IP de métadonnées depuis l'extérieur de la machine. 169.254.169.254 est link-local et ne répond que depuis l'instance elle-même, c'est pourquoi un shell sur l'hôte est nécessaire pour y accéder.

Le service de métadonnées est une fonctionnalité, pas un défaut, mais il doit être durci pour qu'un point d'ancrage ne se transforme pas automatiquement en accès cloud :

• Imposer IMDSv2 (jeton de session obligatoire, limite de sauts fixée à 1) afin qu'une simple server-side request forgery ou un curl basique ne puisse pas atteindre le point de métadonnées.
• Appliquer le moindre privilège au rôle de l'instance : une machine de sauvegarde ne devrait pas porter un rôle capable de lire tous les secrets du compte.
• Restreindre et raccourcir la durée de vie des identifiants, et alerter lorsque les identifiants du rôle sont utilisés depuis une IP qui n'est pas celle de l'instance.
• Exiger une authentification forte, propre à chaque identité, sur les points de terminaison internes comme le service de stockage, plutôt que d'accepter n'importe quel token présenté par l'instance.

Si l'on pense que les identifiants de l'instance ont été volés, révoquer la session, faire tourner la confiance accordée au rôle, et examiner ce à quoi ce rôle pouvait accéder : les identifiants temporaires restent dangereux tant qu'ils n'ont pas expiré.