Métadonnées et SSRF

Chaque VM cloud peut interroger un point de terminaison interne spécial pour obtenir des informations sur elle-même : le Instance Metadata Service (IMDS). Point essentiel, il peut également fournir les identifiants temporaires du rôle associé à l’instance.

• AWS / GCP / Azure exposent tous des métadonnées à l’adresse 169.254.169.254
• Il n’est accessible que depuis l’intérieur de l’instance
• Il n’exige aucune authentification de la part des processus locaux

Cette commodité devient une arme lorsqu’elle est associée à SSRF.

Avec l’ancien IMDSv1, une seule requête GET renvoie les métadonnées, notamment les identifiants du rôle. Aucun jeton n’est nécessaire.

C’est précisément ce qui rend IMDSv1 dangereux lorsqu’une application est vulnérable à SSRF.

La Server-Side Request Forgery (SSRF) est une vulnérabilité dans laquelle un attaquant trompe un serveur pour qu’il effectue des requêtes HTTP à sa place. Le serveur devient un proxy vers des endroits que l’attaquant ne peut pas atteindre directement.

• Un paramètre d’URL que le serveur récupère
• Un webhook, un générateur de PDF ou une fonctionnalité de redimensionnement d’images
• Tout élément qui accepte une URL fournie par l’utilisateur

Dans le cloud, la cible classique d’une SSRF est le point de terminaison des métadonnées.

La combinaison est redoutable : une application vulnérable à SSRF permet à l’attaquant de diriger le serveur vers 169.254.169.254. Le serveur récupère les identifiants IAM de l’instance et les renvoie.

L’attaquant détient alors des identifiants cloud, ce qui constitue souvent le début d’une compromission complète du compte.

La réponse des métadonnées contient une clé d’accès, une clé secrète et un jeton de session. L’attaquant les exporte et agit immédiatement en tant que rôle de l’instance.

À partir de là, il recense les autorisations et recherche des voies d’escalade.

AWS a introduit IMDSv2 pour limiter les SSRF. Il exige d’abord un jeton de session obtenu au moyen d’une requête HTTP PUT, ce que la plupart des mécanismes SSRF ne peuvent pas effectuer (ils ne font que des requêtes GET).

Imposer IMDSv2 et définir une faible limite de sauts réduit considérablement le vol de métadonnées via SSRF.

Les autres fournisseurs exposent eux aussi des métadonnées, avec leurs propres particularités. Tous deux exigent un en-tête spécial, ce qui constitue en soi une petite mesure d’atténuation contre les SSRF.

• Azure exige Metadata: true
• GCP exige Metadata-Flavor: Google

Les défenseurs bloquent souvent 169.254.169.254 à l’aide d’une liste noire. Les attaquants contournent les filtres naïfs au moyen d’autres encodages d’adresses IP et de redirections.

• IP décimale : 2852039166
• Encodages octal et hexadécimal de la même adresse
• Rebinding DNS vers un nom qui se résout vers l’IP des métadonnées
• Redirections ouvertes qui redirigent la requête vers l’URL des métadonnées

Des défenses robustes doivent valider l’IP résolue, et non la chaîne brute.

Les métadonnées sont la cible principale, mais les SSRF permettent d’atteindre davantage de ressources internes :

• Panneaux d’administration et tableaux de bord internes liés à localhost
• Bases de données et caches internes (Redis, Elasticsearch)
• Serveur d’API Kubernetes et points de terminaison kubelet
• Autres microservices non exposés extérieurement

Une SSRF perce efficacement le périmètre réseau depuis un point de vue de confiance.

Rompre la chaîne SSRF vers les métadonnées nécessite une défense en profondeur :

• Imposer IMDSv2 et définir la limite de sauts des métadonnées à 1
• Valider les URL sortantes et utiliser une liste d’autorisation dans les fonctionnalités de récupération
• Bloquer les requêtes vers les plages d’IP privées et de liaison locale après la résolution DNS
• Appliquer le principe du moindre privilège aux rôles d’instance afin de limiter les identifiants volés

Des rôles soumis au moindre privilège garantissent que même un vol réussi aura peu de conséquences.

Les tests de SSRF peuvent atteindre, par conception, des systèmes internes sensibles. Faites preuve de discipline :

• Vérifiez que l’hôte cible et le compte cloud sont dans le périmètre autorisé
• Ne vous introduisez pas dans des systèmes situés en dehors de l’engagement
• Arrêtez-vous et signalez le problème dès que vous avez prouvé l’accès aux identifiants

L’accès aux métadonnées a un impact élevé : démontrez-le avec précaution et n’utilisez pas sans limites les clés volées.

Vous avez appris quelle est la chaîne d’attaque cloud la plus lourde de conséquences.

• Le service de métadonnées à l’adresse 169.254.169.254 fournit les identifiants du rôle de l’instance
• SSRF permet à un attaquant de faire récupérer ce point de terminaison par le serveur
• Les identifiants temporaires volés permettent de prendre le contrôle du compte
• IMDSv2 bloque la plupart des SSRF en exigeant un jeton fondé sur une requête PUT
• Défendez-vous au moyen de listes d’autorisation d’URL, de la validation des IP et de rôles soumis au moindre privilège

Cette section sur les tests d’intrusion cloud est terminée. Prochain cours : chasse aux primes de bugs.