SSRF contre le service de métadonnées cloud pour lire le rôle IAM

La falsification de requête côté serveur (SSRF) se produit lorsqu'une application récupère une URL fournie par l'utilisateur, et que l'attaquant peut la faire pointer vers une destination que l'application n'avait jamais prévue. Une fonctionnalité comme un proxy d'images, un testeur de webhook, ou un dérouleur de liens est le vecteur classique : elle prend une URL et va consciencieusement la récupérer depuis le serveur. Comme la requête part du serveur, elle peut atteindre des adresses que l'attaquant ne peut pas toucher depuis l'extérieur - services internes, panneaux d'administration, et l'endpoint de métadonnées cloud.

Sur une instance cloud, le service de métadonnées d'instance (IMDS) répond à l'adresse link-local 169.254.169.254. Il n'est accessible que depuis l'instance elle-même, donc tout ce qui tourne là, y compris un proxy vulnérable, peut l'interroger. Le chemin /latest/meta-data/iam/security-credentials/ liste le rôle IAM attaché à la machine, et ajouter ce nom de rôle renvoie des clés d'accès AWS actives et éphémères. Une SSRF capable d'atteindre l'IMDS se transforme donc directement en identifiants cloud avec les permissions de l'instance.

La faille n'est pas le service de métadonnées ; c'est que le proxy récupérait une URL arbitraire sans aucune restriction sur la destination. Sans liste blanche, le serveur est un adjoint manipulé : il porte l'intention de l'attaquant avec sa propre position réseau et ses propres privilèges.

• Supposer que le proxy ne peut atteindre que des CDN publics, alors qu'il récupérera toute adresse que le serveur lui-même peut router, y compris les adresses internes et link-local.
• Cibler d'abord localhost ou 127.0.0.1 et manquer le fait que les secrets cloud se trouvent à l'adresse de métadonnées link-local distincte 169.254.169.254.
• S'arrêter au listing du répertoire des identifiants sans réaliser que le nom de rôle qu'il renvoie est la réponse (et l'étape suivante vers des clés actives).
• Traiter la SSRF comme un bug de parsing plutôt que comme la vraie faille : il n'y a aucune liste blanche restreignant les destinations auxquelles le serveur peut envoyer des requêtes.

Le correctif consiste à restreindre les destinations sortantes autorisées pour le serveur et à durcir le service de métadonnées lui-même. Ne jamais récupérer une URL fournie par l'utilisateur sans valider la destination résolue par rapport à une liste blanche.

• Mettre en liste blanche les hôtes/domaines autorisés pour le proxy et rejeter tout le reste ; résoudre le nom d'hôte et bloquer les plages privées, loopback et link-local (y compris 169.254.0.0/16) après résolution, pour contrer le DNS rebinding.
• Imposer IMDSv2 (jeton de session requis) afin qu'une simple SSRF basée sur GET ne puisse plus lire les identifiants, et fixer la limite de sauts (hop limit) des métadonnées à 1.
• Restreindre le rôle IAM de l'instance au moindre privilège, pour qu'un identifiant divulgué soit beaucoup moins utile.
• Journaliser et alerter sur les requêtes sortantes vers des adresses internes ou link-local, afin que les tentatives de SSRF soient visibles.