Server-Side Request Forgery (SSRF) : Exploitation des Métadonnées Cloud

Le Server-Side Request Forgery (SSRF) est passé d'une vulnérabilité de niche à l'un des vecteurs d'attaque les plus dévastateurs dans les applications natives du cloud. Figurant en bonne place dans le Top 10 de l'OWASP, le SSRF se produit lorsqu'une application récupère une ressource distante sans valider l'URL fournie par l'utilisateur. Un attaquant peut forcer le serveur vulnérable à effectuer des requêtes HTTP vers son réseau interne ou l'infrastructure cloud sur laquelle il réside.

Dans cet article technique approfondi, Cayvora Security examine comment le SSRF est militarisé pour exploiter les services de métadonnées d'instance cloud (IMDS), contourner les pares-feux internes et extraire des identifiants IAM hautement sensibles.

Mécanique du SSRF

Les applications web modernes ingèrent fréquemment des URL pour récupérer des images de profil, importer des données ou interagir avec des webhooks. Si le serveur d'application fait naïvement confiance à l'URL fournie :

# Point d'ancrage Python Flask Vulnérable
@app.route('/fetch_image')
def fetch_image():
    url = request.args.get('url')
    # Aucune validation !
    response = requests.get(url) 
    return response.content

Si un attaquant fournit http://localhost:6379/ (le port par défaut pour Redis), le serveur web effectuera une requête vers sa propre base de données Redis interne.

Exploitation des Métadonnées Cloud (IMDS)

La conséquence la plus catastrophique du SSRF dans les environnements cloud (AWS, Azure, GCP) est l'exploitation de l'Instance Metadata Service (IMDS). Ce service est accessible via l'adresse IP fixe et non routable : 169.254.169.254.

Exploitation AWS IMDSv1

Si l'application exécute IMDSv1, un attaquant peut extraire les identifiants en deux étapes :

1. Trouver le nom du rôle : L'attaquant soumet : http://169.254.169.254/latest/meta-data/iam/security-credentials/ Le serveur répond par le nom du rôle : S3-Admin-Role

2. Extraire les identifiants : L'attaquant ajoute le nom du rôle : http://169.254.169.254/latest/meta-data/iam/security-credentials/S3-Admin-Role Le serveur renvoie le JSON hautement sensible :

{
  "Code" : "Success",
  "AccessKeyId" : "ASIAIOSFODNN7EXAMPLE",
  "SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
  "Token" : "IQoJb3JpZ2luX2VjEJv..."
}

L'attaquant prend alors l'identité de S3-Admin-Role, lui permettant de lire/écrire des compartiments S3.

Contournement des Filtres SSRF

Les attaquants contournent les listes de blocage en utilisant : 1. Encodages IP alternatifs : Décimal http://2852039166/, Hexadécimal http://0xA9FEA9FE/. 2. Re-liaison DNS (DNS Rebinding) : Un domaine de l'attaquant résout initialement avec une IP saine, puis bascule sur l'IP locale après la validation. 3. Redirections Ouvertes : Exploiter la capacité de l'outil côté serveur à suivre les "Redirects 302".

Prévention et Durcissement

1. Imposer IMDSv2 (AWS)

AWS a introduit IMDSv2 pour atténuer le SSRF. Il nécessite un en-tête HTTP spécifique (X-aws-ec2-metadata-token) et s'appuie sur une requête PUT pour obtenir un jeton avant d'interroger les métadonnées.

Remédiation :

aws ec2 modify-instance-metadata-options     --instance-id i-1234567890abcdef0     --http-tokens required

2. Validation Stricte des URL

Ne vous fiez jamais aux listes de blocage. Implémentez une liste blanche rigoureuse. Vérifiez que l'adresse IP résolue ne se situe pas dans les plages privées (RFC 1918) ou la plage link-local (169.254.0.0/16).

Conclusion

En migrant strictement vers IMDSv2 et en validant soigneusement toutes les requêtes réseau sortantes, les organisations peuvent rompre ce vecteur d'attaque. Consultez notre guide complet sur les Injection XXE.