SSRF sur AWS : Comment une faille Web peut compromettre tout votre Cloud (Guide IMDSv2)
Le paysage de la cybersécurité a radicalement changé. Aujourd’hui, dans un environnement Cloud, une SSRF AWS (Server-Side Request Forgery) est souvent synonyme de compromission totale de l’infrastructure. Pourquoi ? Parce que derrière chaque instance EC2 se cache un service discret mais extrêmement bavard : l’IMDS (Instance MetaData Service).
Pourquoi la faille SSRF AWS est-elle si critique ?
Lorsqu’une application tourne sur le Cloud d’Amazon, elle utilise souvent des rôles IAM pour interagir avec des services comme S3 ou DynamoDB. Pour éviter de stocker des clés en dur, AWS met à disposition l’IMDS à l’adresse IP interne fixe 169.254.169.254.
Une vulnérabilité SSRF AWS permet à un attaquant de forcer le serveur à effectuer des requêtes vers cette adresse interne, inaccessible depuis l’extérieur, pour récupérer des informations sensibles.
Anatomie d’une attaque SSRF AWS réussie
Le scénario classique d’une SSRF AWS se déroule en trois étapes clés que tout pentester doit connaître.
1. Détection du vecteur d’attaque
L’attaquant cherche un paramètre d’URL qui accepte une adresse externe (ex: un générateur de PDF ou un importateur d’image). Il injecte alors l’adresse de l’IMDS : https://vulnerable-app.com/proxy?url=http://169.254.169.254/latest/meta-data/
2. Énumération des rôles IAM
Si le serveur répond, l’attaquant navigue dans l’arborescence pour trouver le nom du rôle attaché à l’instance. C’est une étape cruciale de toute exploitation SSRF AWS. http://169.254.169.254/latest/meta-data/iam/security-credentials/
3. Exfiltrer les credentials avec la SSRF AWS
Une fois le nom du rôle obtenu (ex: admin-role), une simple requête finale permet d’afficher l’AccessKeyId, le SecretAccessKey et le Token de session en clair sur l’écran de l’attaquant.
Note de sécurité : Pour comprendre les risques en profondeur, consultez la documentation officielle d’AWS sur l’IMDSv2.
IMDSv2 : Le rempart contre l’exploitation SSRF AWS ?
Pour contrer ce vecteur, Amazon a introduit l’IMDSv2. Contrairement à la V1, elle impose une requête PUT pour obtenir un jeton de session avant de pouvoir lire les données.
Cependant, un pentest complet montre que la protection n’est pas infaillible. Si votre application présente une vulnérabilité de type « Header Injection » ou si elle permet des méthodes HTTP arbitraires, le contournement de l’IMDSv2 devient possible. C’est pourquoi l’audit de vos SSRF AWS reste une priorité absolue.
Comment protéger votre infrastructure ?
Pour sécuriser vos déploiements, nous vous recommandons de suivre ces étapes issues de nos services d’audit de sécurité Cloud :
Forcer IMDSv2 : Désactivez totalement le support de l’IMDSv1 sur toutes vos instances EC2.
Principe du moindre privilège : Un rôle EC2 ne doit jamais avoir de permissions « FullAdmin ».
WAF et Filtrage : Utilisez un Web Application Firewall pour bloquer toute requête sortante vers l’IP
169.254.169.254.Audit régulier : Effectuez un pentest web complet pour détecter les failles logicielles avant qu’elles ne soient exploitées.
Conclusion
La SSRF AWS n’est pas une simple erreur de code, c’est une porte ouverte sur l’intégralité de vos données Cloud. En comprenant comment l’IMDS fonctionne, les développeurs et les administrateurs peuvent mieux verrouiller leurs environnements.