(SSRF) Server-side Request Forgery - PortSwigger (Writeup)
SSRF Attacks:
Basic SSRF against the local server:
Ce laboratoire dispose d'une fonctionnalité de vérification des stocks qui récupère des données à partir d'un système interne.
Pour résoudre le laboratoire, modifiez l'URL de vérification des stocks pour accéder à l'interface d'administration à l'adresse http://localhost/admin et supprimez l'utilisateur carlos.
Dans BurpSuite, nous trouvons une variable "stockApi" qui redirige tout le trafic vers une URL interne accessible uniquement depuis le serveur :
Voici le lien en URL encodée :
Nous allons donc pouvoir accéder au site interne de l'entreprise (localhost) en tant qu'administrateur.
Pour finir, nous pourrons supprimer l'utilisateur "carlos" de la base de données avec la requête suivante:
SSRF against another back-end system:
Ce laboratoire dispose d'une fonctionnalité de vérification de stock qui récupère des données à partir d'un système interne.
Pour résoudre le laboratoire, utilisez la fonctionnalité de vérification de stock pour scanner la plage interne 192.168.0.X à la recherche d'une interface administrateur sur le port 8080, puis utilisez-la pour supprimer l'utilisateur carlos.
Nous allons donc lancer une attaque de type Intruder pour identifier l'adresse IP contenant l'URL de l'interface administrateur.
Il faut indiquer un payload de type sequential allant du numéro 1 jusqu'à 254 (option possible).
Nous constatons que l'adresse 192.168.0.144 renvoie un code de statut 200, indiquant que nous avons trouvé l'adresse IP du serveur.
Ensuite, nous allons éliminer l'utilisateur carlos en utilisant la requête suivante :
SSRF with blacklist based input filter:
Ce laboratoire dispose d'une fonctionnalité de vérification de stock qui récupère les données depuis un système interne.
Pour résoudre le laboratoire, modifiez l'URL de vérification de stock pour accéder à l'interface d'administration à l'adresse http://localhost/admin et supprimez l'utilisateur carlos.
Le développeur a mis en place deux défenses anti-SSRF faibles que vous devrez contourner.
Nous recevons un message d'erreur indiquant que l'URL est bloquée pour des raisons de sécurité : "External stock check blocked for security reasons". Nous allons essayer de remplacer "localhost" par l'adresse IP qui pointe dans la même direction, 127.0.0.1, et même en hexadécimal, mais nous recevons :
En revanche, si nous indiquons l'adresse localhost sous la forme 127.1, ce qui revient au même que 127.0.0.1, nous réussissons à accéder au site localhost.
Cependant, il y a une deuxième restriction : le répertoire admin est inaccessible.
Pour contourner cela, il faut encoder une lettre de admin, par exemple le a, ce qui permettra de passer cette restriction :
Finalement, il faudra simplement supprimer l'utilisateur en utilisant la variable delete :
SSRF with filter bypass via open redirection vulnerability:
Ce laboratoire dispose d'une fonction de vérification de stock qui récupère des données depuis un système interne.
Pour résoudre le laboratoire, modifiez l'URL de vérification du stock pour accéder à l'interface admin à l'adresse http://192.168.0.12:8080/admin et supprimez l'utilisateur carlos.
Le vérificateur de stock est limité à l'accès uniquement à l'application locale, vous devrez donc d'abord trouver une redirection ouverte affectant l'application.
Il y a une variable "path" qui redirige vers un endroit du site vers un autre produit.
Si l'on remplace le chemin par l'URL d'un autre site web, la page enverra la requête depuis le serveur.
Utilisez la variable stockApi pour afficher le site interne de l'administrateur à l'adresse 192.168.0
Blind SSRF with out-of-band (OOB) detection:
Ce site utilise un logiciel d'analyse qui récupère l'URL spécifiée dans l'en-tête Referer lorsqu'une page de produit est chargée.
Pour résoudre le laboratoire, utilisez cette fonctionnalité pour provoquer une requête HTTP vers le serveur public Burp Collaborator. Note: Pour éviter que la plateforme Academy ne soit utilisée pour attaquer des tiers, notre pare-feu bloque les interactions entre les laboratoires et des systèmes externes arbitraires. Pour résoudre le laboratoire, vous devez utiliser le serveur public par défaut de Burp Collaborator.
En utilisant la fonctionnalité de Burp Suite Collaborator pour vérifier si l'on reçoit une requête depuis une URL externe au site, on peut confirmer que c'est possible. Cela indique une potentielle vulnérabilité à des attaques de type DDoS, utilisant le serveur comme relais.
SSRF with whitelist-based input filter:
Ce laboratoire dispose d'une fonctionnalité de vérification de stock qui récupère les données à partir d'un système interne.
Pour résoudre le laboratoire, modifiez l'URL de vérification de stock pour accéder à l'interface d'administration à l'adresse http://localhost/admin et supprimez l'utilisateur carlos.
Le développeur a mis en place une défense anti-SSRF que vous devrez contourner.
Pour accéder au site localhost/admin, il est nécessaire de disposer de l'URL du site stock.welikeshop.net.
Modifiez l'URL en http://[email protected]/ et observez que cela est accepté, indiquant que l'analyseur d'URL prend en charge les identifiants intégrés.
Ajoutez un # au nom d'utilisateur et constatez que l'URL est désormais rejetée.
Double-encodez l'URL du # en %2523 et observez la réponse "Internal Server Error" extrêmement suspecte, indiquant que le serveur a peut-être tenté de se connecter à "username".
Nous allons finalement supprimer l'utilisateur
Blind SSRF with Shellshock exploitation:
Ce site utilise un logiciel d'analyse qui récupère l'URL spécifiée dans l'en-tête Référent lorsqu'une page produit
Pour résoudre le lab, utilisez cette fonctionnalité pour réaliser une attaque SSRF aveugle contre un serveur interne dans la plage
192.168.0.Xsur le port 8080. Dans l'attaque aveugle, utilisez une charge utile Shellshock contre le serveur interne pour extraire le nom de l'utilisateur.
Premièrement, nous allons modifier la variable "Referer" et y insérer un payload collaborator. Cela implique l'envoi d'un lien vers un site temporaire pour vérifier si nous recevons une réponse
Lors de l'utilisation de Burp Suite Collaborator, la requête est reçue dans le répertoire "/test" et le User-Agent est également envoyé
Nous allons modifier le referer pour envoyer une requête au serveur web. Ensuite, nous utiliserons ShellShock pour injecter les commandes nslookup et whoami vers notre serveur, qui est à l'écoute avec Burp Suite Collaborator:
Envoyez simplement la trame à l'intruder pour exécuter une attaque par force brute afin de trouver l'équipement interne sur le port 80880
La pétition avec le nom de l'utilisateur "Peter-Euhceo" est finalement reçue via une requête DNS
Mis à jour
Ce contenu vous a-t-il été utile ?