takito1812/web-hacking-playgroundApplication web avec des vulnérabilités trouvées dans des cas réels, à la fois lors de tests d'intrusion et dans des programmes Bug Bounty.
Web Hacking Playground est un environnement de hacking web contrôlé. Il contient des vulnérabilités trouvées dans des cas réels, à la fois dans des tests d'intrusion et dans des programmes de Bug Bounty. L'objectif est que les utilisateurs puissent s'entraîner avec celles-ci et apprendre à les détecter et à les exploiter.
D'autres sujets d'intérêt seront également abordés, tels que : le contournement de filtres par la création de payloads personnalisés, l'exécution d'attaques en chaîne exploitant diverses vulnérabilités, le développement de scripts de preuve de concept, entre autres.
Le code source de l'application est visible. Cependant, l'approche du laboratoire est celle d'une boîte noire. Par conséquent, le code ne doit pas être examiné pour résoudre les défis.
De plus, il convient de noter que le fuzzing (à la fois des paramètres et des répertoires) et les attaques par force brute n'offrent aucun avantage dans ce laboratoire.
Il est recommandé d'utiliser Kali Linux pour réaliser ce laboratoire. En cas d'utilisation d'une machine virtuelle, il est conseillé d'utiliser l'hyperviseur VMware Workstation Player.
L'environnement est basé sur Docker et Docker Compose, il est donc nécessaire d'avoir les deux installés.
Pour installer Docker sur Kali Linux, exécutez les commandes suivantes :
sudo apt update -y
sudo apt install -y docker.io
sudo systemctl enable docker --now
Pour installer Docker sur d'autres distributions basées sur Debian, exécutez les commandes suivantes :
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo systemctl enable docker --now
Pour installer Docker Compose, exécutez la commande suivante :
sudo apt install -y docker-compose
Note : En cas d'utilisation de M1, il est recommandé d'exécuter la commande suivante avant de construire les images :
export DOCKER_DEFAULT_PLATFORM=linux/amd64
L'étape suivante consiste à cloner le dépôt et à construire les images Docker :
git clone https://github.com/takito1812/web-hacking-playground.git
cd web-hacking-playground
sudo docker-compose build
Il est également recommandé d'installer l'extension de navigateur Foxy Proxy, qui permet de modifier facilement les paramètres du proxy, et Burp Suite, que nous utiliserons pour intercepter les requêtes HTTP.
Nous allons créer un nouveau profil dans Foxy Proxy pour utiliser Burp Suite comme proxy. Pour ce faire, allez dans les options de Foxy Proxy et ajoutez un proxy avec la configuration suivante :
Une fois tout ce dont vous avez besoin installé, vous pouvez déployer l'environnement avec la commande suivante :
git clone https://github.com/takito1812/web-hacking-playground.git
cd web-hacking-playground
sudo docker-compose up -d
Cela créera deux conteneurs d'applications développées en Flask sur le port 80 :
Il est nécessaire d'ajouter l'IP des conteneurs au fichier /etc/hosts, afin qu'ils puissent être accessibles par nom et que le serveur d'exploitation puisse communiquer avec l'application web vulnérable. Pour ce faire, exécutez les commandes suivantes :
sudo sed -i '/whp-/d' /etc/hosts
echo "$(sudo docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' whp-socially) whp-socially" | sudo tee -a /etc/hosts
echo "$(sudo docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' whp-exploitserver) whp-exploitserver" | sudo tee -a /etc/hosts
Une fois cela fait, l'application vulnérable est accessible depuis http://whp-socially et le serveur d'exploitation depuis http://whp-exploitserver.
Lorsque vous utilisez le serveur d'exploitation, les URLs ci-dessus doivent être utilisées, en utilisant le nom de domaine et non les IP. Cela garantit une communication correcte entre les conteneurs.
En ce qui concerne le piratage, pour représenter le serveur de l'attaquant, l'IP Docker locale doit être utilisée, car le laboratoire n'est pas destiné à envoyer des requêtes à des serveurs externes tels que Burp Collaborator, Interactsh, etc. Un serveur HTTP Python peut être utilisé pour simuler un serveur web et recevoir des interactions HTTP. Pour ce faire, exécutez la commande suivante :
sudo python3 -m http.server 80
L'environnement est divisé en trois étapes, chacune avec des vulnérabilités différentes. Il est important de les réaliser dans l'ordre, car les vulnérabilités des étapes suivantes s'appuient sur celles des étapes précédentes. Les étapes sont :
Ci-dessous se trouvent des spoilers pour les vulnérabilités de chaque étape. Si vous n'avez pas besoin d'aide, vous pouvez passer cette section. En revanche, si vous ne savez pas par où commencer ou si vous voulez vérifier si vous êtes sur la bonne voie, vous pouvez dérouler la section qui vous intéresse.
À cette étape, la session d'un utilisateur spécifique peut être volée via Cross-Site Scripting (XSS), ce qui permet d'exécuter du code JavaScript. Pour ce faire, la victime doit pouvoir accéder à une URL dans le contexte de l'utilisateur ; ce comportement peut être simulé avec le serveur d'exploitation.
Les indices pour résoudre cette étape sont :
À cette étape, un jeton peut être généré qui permet un accès en tant qu'admin. Il s'agit d'une attaque typique de JSON Web Token (JWT), dans laquelle le payload du jeton peut être modifié pour élever les privilèges.
L'indice pour résoudre cette étape est qu'il existe un endpoint qui, étant donné un JWT, retourne un cookie de session valide.
À cette étape, le fichier /flag peut être lu via une vulnérabilité de Server Site Template Injection (SSTI). Pour ce faire, vous devez amener l'application à exécuter du code Python sur le serveur. Il est possible d'exécuter des commandes système sur le serveur.
Les indices pour résoudre cette étape sont :
La fonctionnalité vulnérable est protégée par une authentification à deux facteurs. Par conséquent, avant d'exploiter la SSTI, un moyen de contourner la demande de code OTP doit être trouvé. Il arrive que l'application fasse confiance aux requêtes provenant du même serveur et les en-têtes HTTP jouent un rôle important dans cette situation.
La SSTI est aveugle (Blind), cela signifie que la sortie du code exécuté sur le serveur n'est pas obtenue directement. Le module Python smtpd permet de créer un serveur SMTP qui imprime les messages qu'il reçoit sur la sortie standard :
sudo python3 -m smtpd -n -c DebuggingServer 0.0.0.0:25
L'application utilise Flask, on peut donc en déduire que le moteur de template est Jinja2 car il est recommandé par la documentation officielle de Flask et largement utilisé. Vous devez obtenir un payload compatible Jinja2 pour obtenir le flag final.
Le message électronique a une limite de caractères. Des informations sur la manière de contourner cette limitation peuvent être trouvées sur Internet.
Des solutions détaillées pour chaque étape se trouvent dans le dossier Solutions.
Les ressources suivantes peuvent être utiles pour résoudre les étapes :
Les pull requests sont les bienvenues. Si vous trouvez des bugs, veuillez ouvrir une issue.