Introduction
La falsification de requête côté serveur (SSRF, pour Server-Side Request Forgery) est une vulnérabilité de sécurité web qui permet à un attaquant d'inciter une application côté serveur à effectuer des requêtes HTTP vers un domaine arbitraire de son choix.
Le point crucial est que c'est le serveur qui effectue la requête, et non l'attaquant directement. Cela signifie que la requête hérite de la position réseau du serveur, de ses relations de confiance et de son accès aux destinations réservées au réseau interne.
Dans une attaque SSRF classique, l'attaquant peut amener le serveur à se connecter à des services internes au sein de l'infrastructure de l'organisation. Dans d'autres cas, il peut forcer le serveur à se connecter à des systèmes externes arbitraires, ce qui peut entraîner la fuite de données sensibles, telles que des identifiants d'autorisation.
Dans ce laboratoire, vous interagirez avec une application web vulnérable simulée. Vous apprendrez à identifier la vulnérabilité SSRF, à observer comment les filtres de sécurité de base tentent de bloquer les requêtes malveillantes, à contourner ces filtres et, enfin, à extraire des données internes sensibles ainsi que des métadonnées cloud simulées. Pour assurer la compatibilité de cet exercice avec des environnements de laboratoire partagés, le service de métadonnées simulé utilise un port élevé non privilégié au lieu du port 80.
Identifier les paramètres d'URL
Dans cette étape, vous apprendrez à identifier les vulnérabilités SSRF potentielles en recherchant les fonctionnalités de l'application qui récupèrent des données à partir d'URL externes.
De nombreuses applications web doivent récupérer des ressources sur d'autres serveurs. Par exemple, une application peut récupérer une photo de profil depuis un site de réseau social ou extraire des données via une API tierce. Si l'application accepte une URL en tant qu'entrée utilisateur et la récupère sans validation appropriée, elle peut être vulnérable au SSRF.
C'est pourquoi le SSRF apparaît souvent dans des fonctionnalités légitimes de « récupération d'URL ». Le comportement dangereux est dissimulé au sein d'un flux de travail qui semble normal du point de vue du produit.
Une application web vulnérable a été démarrée pour vous sur le port 8080. Cette application possède un point de terminaison /check qui accepte un paramètre url. Il est conçu pour vérifier le statut de sites web externes.
Vous pouvez tester cette fonctionnalité en demandant à l'application de récupérer un site web externe bénin, tel que http://example.com. Utilisez la commande curl dans votre terminal pour envoyer une requête HTTP GET à l'application vulnérable. Si vous n'êtes pas familier avec curl, considérez-le comme un navigateur web en ligne de commande simple qui envoie des requêtes et affiche la réponse du serveur dans le terminal.
curl "http://localhost:8080/check?url=http://example.com"
Lorsque vous exécutez cette commande, l'application vulnérable tournant sur le port 8080 reçoit votre requête, extrait le paramètre url et effectue sa propre requête HTTP vers http://example.com. Elle vous renvoie ensuite la réponse HTML.
<!doctype html>
<html>
<head>
<title>Example Domain</title>
...
En observant que le serveur a récupéré et renvoyé avec succès le contenu de l'URL demandée, vous avez confirmé que le paramètre url est activement traité et utilisé pour effectuer des requêtes côté serveur. C'est le premier indicateur d'une vulnérabilité SSRF.
Tester le SSRF contre Localhost (127.0.0.1)
Dans cette étape, vous tenterez d'exploiter la vulnérabilité SSRF pour accéder à un service interne tournant sur le serveur.
Le danger principal du SSRF réside dans le fait que le serveur effectuant la requête occupe souvent une position privilégiée sur le réseau. Il peut accéder à des services internes qui ne sont pas exposés sur l'internet public. Dans notre scénario, il existe un panneau d'administration interne tournant sur le port 5000. Ce panneau est lié à 127.0.0.1 (localhost), ce qui signifie qu'il ne peut être accédé que depuis le serveur lui-même, et non depuis une autre machine. Vous pouvez considérer 127.0.0.1 comme l'ordinateur qui communique avec lui-même.
En tant qu'attaquant, vous pouvez utiliser la vulnérabilité SSRF sur le port 8080 pour tromper le serveur afin qu'il accède au panneau d'administration sur le port 5000 en votre nom.
Tentez d'accéder au panneau d'administration interne en passant son URL locale au point de terminaison vulnérable /check.
curl "http://localhost:8080/check?url=http://127.0.0.1:5000/admin"
Lorsque vous exécutez cette commande, vous remarquerez que la requête n'aboutit pas. À la place, vous recevez un message d'erreur.
Error: Localhost access is blocked by WAF!
Les développeurs implémentent souvent des pare-feu d'application web (WAF) ou des filtres d'entrée pour empêcher les attaques SSRF. Dans ce cas, l'application vérifie si l'URL fournie contient la chaîne 127.0.0.1 ou localhost. Comme votre entrée correspondait à ce filtre, l'application a bloqué la requête.
Les filtres de chaînes simples sont fragiles car les destinations réseau possèdent plusieurs représentations équivalentes. Les défenseurs ont besoin d'une validation qui comprend la signification réseau canonique, et non seulement le texte littéral.
Comprendre comment l'application filtre les entrées est une étape cruciale pour exploiter le SSRF, car cela vous indique quelles restrictions vous devez contourner.
Contourner les filtres d'entrée
Dans cette étape, vous apprendrez à contourner le filtre d'entrée de base que vous avez rencontré à l'étape précédente.
Les techniques de contournement fonctionnent ici parce que l'analyse des URL, la résolution des noms d'hôte et le filtrage des entrées n'utilisent pas toujours les mêmes règles d'interprétation.
Les filtres d'entrée qui reposent sur une simple correspondance de chaînes (comme le blocage de 127.0.0.1) sont souvent défaillants car les adresses IP peuvent être représentées de multiples façons. La pile réseau du système d'exploitation résoudra toujours ces représentations alternatives vers la même destination, mais le filtre textuel de l'application pourrait ne pas les reconnaître.
Voici quelques moyens courants de représenter l'adresse IP de localhost (127.0.0.1) qui pourraient contourner un filtre mal implémenté. Vous pouvez utiliser une IP raccourcie comme 127.1, une IP décimale telle que 2130706433, une IP octale comme 0177.000.000.001, ou une IP hexadécimale comme 0x7f000001.
Puisque l'application bloque uniquement les chaînes exactes 127.0.0.1 et localhost, vous pouvez utiliser la représentation IP raccourcie 127.1 pour contourner le filtre et accéder au panneau d'administration interne.
Exécutez la commande suivante pour tester la technique de contournement :
curl "http://localhost:8080/check?url=http://127.1:5000/admin"
Comme 127.1 ne correspond pas aux chaînes bloquées, l'application autorise la requête. La pile réseau du serveur résout 127.1 en 127.0.0.1 et récupère avec succès la page d'administration interne.
Welcome to the Internal Admin Panel. Secret Key: SSRF_ADMIN_SUCCESS
Vous avez réussi à contourner le filtre d'entrée et à exploiter la vulnérabilité SSRF pour accéder à un service interne restreint.
Accéder aux métadonnées internes
Dans cette étape, vous utiliserez la vulnérabilité SSRF pour accéder à des métadonnées cloud sensibles.
Lorsque les applications sont hébergées dans des environnements cloud (comme AWS, Google Cloud ou Azure), elles ont souvent accès à une adresse IP spéciale non routable : 169.254.169.254. Cette adresse héberge le service de métadonnées d'instance (IMDS), qui fournit des informations sur l'instance cloud en cours d'exécution, y compris des identifiants temporaires hautement sensibles IAM (Identity and Access Management). « Non routable » signifie que l'adresse est destinée à l'infrastructure cloud locale plutôt qu'à un accès internet public général.
Si un attaquant découvre une vulnérabilité SSRF dans une application hébergée dans le cloud, interroger ce point de terminaison de métadonnées est souvent son objectif principal, car cela peut mener à une compromission totale de l'environnement cloud.
Dans cet environnement de laboratoire, un service de métadonnées cloud simulé tourne sur 169.254.169.254:8000. Le véritable service de métadonnées cloud utilise généralement le port 80, mais ce laboratoire utilise intentionnellement le port 8000 afin que le service puisse démarrer sans privilèges spéciaux et sans entrer en conflit avec d'autres logiciels. Tout d'abord, utilisez la vulnérabilité SSRF pour lister les répertoires de métadonnées disponibles.
curl "http://localhost:8080/check?url=http://169.254.169.254:8000/latest/meta-data/"
Le serveur récupérera la liste des répertoires de métadonnées et vous la renverra.
iam/security-credentials/admin-role
La sortie révèle un rôle IAM nommé admin-role. Vous pouvez maintenant ajouter ce chemin à votre charge utile (payload) SSRF pour extraire les identifiants de sécurité réels associés à ce rôle.
Exécutez la commande suivante pour récupérer les identifiants sensibles :
curl "http://localhost:8080/check?url=http://169.254.169.254:8000/latest/meta-data/iam/security-credentials/admin-role"
Le service de métadonnées simulé renverra les identifiants au format JSON.
{"AccessKeyId":"AKIAIOSFODNN7EXAMPLE","SecretAccessKey":"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"}
Si cette requête ne renvoie pas de données dans votre environnement, vérifiez brièvement /tmp/meta.log et confirmez qu'un service est bien à l'écoute sur 169.254.169.254:8000.
En extrayant avec succès ces identifiants, vous avez démontré l'impact grave d'une vulnérabilité SSRF dans un environnement cloud.
Résumé
Dans ce laboratoire, vous avez exploré et exploité avec succès une vulnérabilité de type Server-Side Request Forgery (SSRF). Vous avez appris à identifier les paramètres d'URL vulnérables en observant le comportement de récupération côté serveur. Vous avez ensuite rencontré un filtre d'entrée de base conçu pour bloquer l'accès local et l'avez contourné avec succès en utilisant des représentations alternatives d'adresses IP. Enfin, vous avez démontré l'impact critique du SSRF en extrayant des identifiants de métadonnées cloud simulés sensibles. La compréhension de ces techniques est essentielle tant pour identifier les vulnérabilités lors des évaluations de sécurité que pour mettre en œuvre des défenses robustes dans les applications web.
