Scan, exploitation encadrée et preuves

Prérequis : cours précédent (périmètre écrit !).

Pourquoi

Trouver une faille ne suffit pas : il faut prouver l'impact (sinon « théorique, on verra ») sans rien casser (sinon c'est toi l'incident). Méthode + preuves = rapport qui fait bouger.

Concepts

• Scan : vulnérabilités connues (Nessus/OpenVAS : CVE par versions), config (SSLyze : TLS noté), web (ZAP/Burp : crawl + fuzz léger). Le scan liste, il ne prouve pas.
• Exploitation encadrée : PoC minimale (lire /etc/hostname via la faille, pas /etc/shadow !), captures (requête/réponse, horodatage), jamais de : données réelles exfiltrées, DoS, pivot non autorisé, persistance.
• Critcité : CVSS en base + contexte (internet ? auth requise ? données ?) = priorité réelle. Un 9.8 sur un service interne isolé < un 7.5 internet sur la prod.

Exemple : PoC propre (XXE)

POST /upload-xml  →  <!ENTITY xxe SYSTEM "file:///etc/hostname">]>
Réponse contenant le hostname = preuve suffisante. On s'arrête là.

Cas réel

Presta qui « teste » en prod : fuzz agressif → 2M de logs, table de sessions saturée, 20 min de down facturées au client… par le presta. Depuis : tests en staging cloné, fenêtres écrites, rate-limit du scanner.

Pièges

• Exploiter au-delà de la preuve : exfiltrer « pour montrer » = fuite causée par le testeur. Preuve minimale toujours.
• Scanner la prod en journée : même « léger », ça charge. Fenêtres + staging d'abord.
• Oublier de prévenir (SOC, hébergeur) : l'alerte bleue déclenchée par ton test = incident pour rien + confiance perdue.

À retenir

Scanner = lister, PoC minimale = prouver, contexte = prioriser ; staging d'abord, périmètre toujours.