Chapitre 4 : Vulnerability Assessment

Vulnerabilities

Panorama des Vulnérabilités Windows & Linux

Un chapitre volontairement synthétique : comprendre les grandes familles de vulnérabilités et les outils de scan, sans entrer dans le détail de l'exploitation — ce sera l'objet des chapitres de pentesting à venir.

1. Vulnérabilités Windows

Surface d'attaque, types de failles courantes et services fréquemment ciblés.

2. CVE Historiques Marquantes

EternalBlue, BlueKeep, Shellshock — comprendre leur contexte, pas encore les exploiter.

3. Scan de Vulnérabilités

Automatiser la détection avec Metasploit, Nessus et WMAP.

Panorama des Vulnérabilités Windows

Windows / VA

Pourquoi Windows est une Cible

  • Système d'exploitation dominant dans le monde (plus de 70% de part de marché), ce qui en fait une cible privilégiée.
  • Historique marqué par des vulnérabilités majeures, de MS08-067 (Conficker) à MS17-010 (EternalBlue).
  • Sa popularité fait que la plupart de ces failles disposent d'un code d'exploitation public, ce qui facilite leur exploitation.

Types de Vulnérabilités Courantes

  • Fuite d'information : accès à des données confidentielles.
  • Buffer overflow : erreur de programmation permettant d'écrire au-delà de la mémoire allouée.
  • Exécution de code à distance (RCE) : exécuter du code sur le système cible.
  • Élévation de privilèges : obtenir plus de droits après un premier accès.
  • Déni de service (DoS) : épuiser les ressources du système ciblé.

CVE Historiques Marquantes (1/2)

EternalBlue / BlueKeep

EternalBlue — MS17-010

  • Faille dans le protocole SMBv1, développée par la NSA puis fuitée publiquement en 2017 par le groupe Shadow Brokers.
  • Utilisée dans la propagation du ransomware WannaCry en juin 2017.
  • Touche de nombreuses versions de Windows (Vista à Server 2016) ; corrigée depuis mars 2017, mais encore présente sur des systèmes non mis à jour.

BlueKeep — CVE-2019-0708

  • Vulnérabilité du protocole RDP, rendue publique par Microsoft en mai 2019.
  • Permet potentiellement une exécution de code à distance sans authentification.
  • Environ 1 million de systèmes vulnérables recensés à l'époque ; touche XP à Server 2008 R2. De nombreux PoC publics ne sont pas fiables — seul du code vérifié doit être utilisé.

CVE Historiques Marquantes (2/2)

Shellshock / Pass-the-Hash

Shellshock — CVE-2014-6271

  • Famille de vulnérabilités dans le shell Bash, permettant l'exécution de commandes arbitraires à distance.
  • Ne concerne que Linux/Unix — Windows n'utilise pas Bash nativement.
  • Les serveurs Apache exécutant des scripts CGI constituent un vecteur d'exposition classique.

Pass-the-Hash

  • Technique consistant à capturer un hash NTLM (ou un mot de passe en clair) pour s'authentifier directement, sans connaître le mot de passe réel.
  • Permet un accès via des identifiants légitimes plutôt que via l'exploitation d'un service.
  • Sera détaillée en profondeur dans les chapitres de pentesting consacrés à la post-exploitation.

Services Windows & Linux Fréquemment Ciblés

Attack Surface

Côté Windows

  • Les services natifs de Windows (SMB, RDP, WinRM...) sont souvent exposés et constituent des vecteurs d'accès classiques.
  • Comprendre leur fonctionnement est un préalable indispensable avant de les tester en conditions réelles.

Côté Linux

  • Linux est typiquement déployé comme système d'exploitation serveur.
  • Des services et protocoles spécifiques (SSH, Apache/CGI, bases de données) constituent la surface d'attaque habituelle sur ce type de système.

Scan de Vulnérabilités avec Metasploit

MSF / Scanning

Principe

  • Le scan de vulnérabilités consiste à identifier les failles potentielles d'un système, puis à vérifier si elles sont réellement exploitables.
  • Les modules auxiliaires et d'exploitation de Metasploit permettent d'automatiser cette vérification sur les services, l'OS et les applications web.

Démarche Générale

# Scanner la cible et l'importer dans un workspace
db_nmap -sS -sV -O @IP_cible

# Rechercher un module correspondant à une CVE connue
search cve:<annee> name:<service>

# Vérifier si la cible est vulnérable
# (module auxiliaire de vérification, pas d'exploitation)
use auxiliary/scanner/smb/smb_ms17_010
set rhosts @IP_cible
run

Scanners Tiers — Nessus & WMAP

Nessus / WMAP

Nessus

  • Scanner de vulnérabilités propriétaire développé par Tenable.
  • Automatise l'identification des failles et fournit le code CVE associé à chacune.
  • Les résultats peuvent être importés dans Metasploit pour analyse et suite du test.

Import Nessus & Plugin WMAP

# Importer un rapport Nessus (format XML) dans MSF
db_import /chemin/rapport_nessus.nessus
vulns -p @port

# Charger le plugin WMAP pour l'audit d'applications web
load wmap
wmap_sites -a @IP_cible
wmap_run -e
wmap_vulns -l

Vulnerability Assessment — Modèle Mental

Méthodologie

Un Vulnerability Assessment ne consiste pas à lancer un scanner et à recopier ses résultats. Le but est de détecter, contextualiser, vérifier et documenter les vulnérabilités potentielles avant de décider si une exploitation contrôlée est nécessaire.

1 — DécouvrirHôtes, ports, services, versions et technologies.
→
2 — CorrélerVersions ↔ CVE ↔ configuration ↔ exposition.
→
3 — VérifierRéduire les faux positifs avec des preuves techniques.
→
4 — PrioriserImpact, exposition, exploitabilité et contexte.

Vulnérabilité, CVE, CWE, Exploit : Ne Pas Confondre

Concepts

Vulnérabilité

Faiblesse technique ou logique pouvant compromettre confidentialité, intégrité ou disponibilité.

CVE

Identifiant public permettant de référencer une vulnérabilité précise affectant un produit ou une version.

CWE

Classification de la cause ou du type de faiblesse : injection, contrôle d'accès insuffisant, overflow, etc.

Point clé : la présence d'une CVE dans un scanner ne prouve pas automatiquement que la cible est exploitable. Il faut confirmer le produit, la version, les conditions préalables et l'exposition réelle.

Scanner ≠ Preuve de Vulnérabilité

Faux Positifs

Pourquoi un scanner se trompe

  • Détection basée uniquement sur une bannière de version.
  • Patch backporté sans changement apparent de version.
  • Service détecté mais non exposé dans les conditions nécessaires.
  • Signature générique déclenchée par un comportement similaire.

Validation manuelle

  • Identifier précisément le produit et la version.
  • Comparer avec l'avis constructeur/CVE.
  • Vérifier les préconditions d'exploitation.
  • Utiliser un module de check lorsque disponible avant toute exploitation.

Faux Négatif — Pourquoi un Scan Peut Ne Rien Voir

Limites

Causes fréquentes

  • Port fermé ou filtré.
  • Authentification nécessaire.
  • Service derrière un reverse proxy/WAF.
  • Version masquée ou fingerprint incomplet.
  • Plugin/scanner non à jour.

Conséquence

« Aucun résultat » signifie seulement qu'aucune vulnérabilité n'a été détectée avec les méthodes et données utilisées. Ce n'est pas une preuve d'absence de vulnérabilité.

Workflow de Reconnaissance Avant le VA

Recon
ScopeIP, hostname, plage, exclusions.
→
DiscoveryHôtes actifs et ports accessibles.
→
EnumerationServices, versions, OS, applications.
→
VATests de vulnérabilités adaptés.
# Découverte et fingerprinting de base
nmap -sS -sV -O --open <IP>

# Scripts NSE orientés vulnérabilités
nmap -sV --script vuln <IP>

Comprendre les États Nmap Avant le Scan de Vulnérabilités

Nmap

open

Un service accepte des connexions. C'est généralement la surface à énumérer.

closed

Le port est accessible mais aucun service n'écoute actuellement.

filtered

Un filtrage empêche Nmap de déterminer correctement l'état du port.

Interprétation : une vulnérabilité ne peut être associée à un service que si le service et ses conditions d'exposition sont correctement identifiés.

Fingerprinting de Version — Ce qu'il Faut Vérifier

Enumeration

Informations utiles

  • Produit : Apache, OpenSSH, IIS, SMB, RDP...
  • Version exacte lorsque possible.
  • Protocole et configuration.
  • OS et architecture.
  • Contexte : Internet, LAN, VPN, segment interne.

Commandes

nmap -sV -sC <IP>
nmap -O <IP>
nmap -A <IP>

# Vérifier un service spécifique
nmap -sV -p 22,80,443,445 <IP>

CVE Matching — De la Version au Contexte

CVE
1. Version détectée ? → vérifier sa fiabilité.
2. CVE applicable à cette version ? → vérifier le produit exact.
3. Préconditions présentes ? → configuration, authentification, module activé.
4. Service exposé de manière pertinente ? → réseau et filtrage.
5. Validation possible sans impact ? → privilégier une vérification non destructive.

CVSS — Lire un Score Sans Le Surinterpréter

Priorisation

Ce que mesure CVSS

  • Caractéristiques techniques de la vulnérabilité.
  • Vecteur d'attaque, complexité, privilèges, interaction utilisateur.
  • Impacts confidentialité, intégrité et disponibilité.

Ce que CVSS ne dit pas à lui seul

  • Si votre instance est réellement vulnérable.
  • La criticité métier de votre actif.
  • La probabilité réelle d'exploitation dans votre environnement.

Metasploit : Scanner Sans Exploiter

MSF

Dans une phase VA, privilégier les modules auxiliaires capables de vérifier une condition plutôt que de lancer directement un exploit. L'objectif est de confirmer le finding avec le minimum d'impact.

msfconsole

# Recherche
search type:auxiliary scanner smb
search cve:2017-0144

# Exemple de vérification
use auxiliary/scanner/smb/smb_ms17_010
set RHOSTS <IP>
run
À retenir : « module trouvé » ≠ « cible vulnérable ». Le résultat du module et les préconditions doivent être analysés.

Nessus — Lire un Résultat Correctement

Nessus

Dans chaque finding

  • Plugin ID et titre.
  • Hôte et port concernés.
  • Preuve fournie par le plugin.
  • CVE/CVSS si disponible.
  • Solution/remédiation.

Question à poser

« Quelle donnée observée permet d'affirmer que cette vulnérabilité est présente ? »

Si la réponse est uniquement « la bannière indique une version vulnérable », une vérification supplémentaire peut être nécessaire.

Vulnerability Management vs Vulnerability Assessment

Processus
Asset DiscoveryConnaître ce qui existe.
→
AssessmentDétecter les faiblesses.
→
ValidationConfirmer les findings.
→
RemediationCorriger.
→
RetestVérifier la correction.

Windows — Lecture de la Surface d'Attaque

Windows

SMB

Partages, authentification réseau, anciennes versions du protocole et configuration.

RDP

Exposition distante, versions, NLA et contrôles d'accès.

WinRM

Administration distante ; vérifier exposition, authentification et configuration.

Méthode : identifier d'abord le service et sa version/configuration ; ne pas passer directement de « port ouvert » à « vulnérable ».

Linux — Lecture de la Surface d'Attaque

Linux

SSH

Version, méthodes d'authentification et exposition.

HTTP/HTTPS

Serveur web, framework, modules, virtual hosts et applications.

Services

FTP, SMTP, bases de données, RPC et autres services selon l'environnement.

Scanner les Services Web

Web VA

Reconnaissance

  • Headers HTTP.
  • Technologie/framework.
  • Répertoires et fichiers.
  • Virtual hosts.
  • TLS et certificats.

Commandes

curl -I http://<IP>
whatweb http://<IP>
nikto -h http://<IP>

# Découverte de contenu
ffuf -w wordlist.txt -u http://<IP>/FUZZ

NSE — Choisir le Bon Niveau de Scan

Nmap NSE

Catégories utiles

defaultsafediscoveryversionvulnauth

Attention

Les scripts NSE n'ont pas tous le même niveau d'impact. Lire leur description avant exécution et respecter le périmètre du test.

# Voir les informations d'un script
nmap --script-help <script>

# Exemple ciblé
nmap -p 445 --script smb-vuln-ms17-010 <IP>

Comparer Plusieurs Sources de Détection

Correlation

Nmap

Exposition, ports, services, versions et scripts ciblés.

Nessus

Large couverture automatisée et corrélation CVE/plugin.

Validation manuelle

Confirme la condition réellement présente sur la cible.

Bonne pratique : lorsqu'un finding important est confirmé par plusieurs sources indépendantes, conserver les preuves de chaque source dans les notes de test.

Cas Pratique — Une CVE Détectée sur un Service

Case Study
Observation : Nmap identifie un service et une version.
Recherche : plusieurs CVE correspondent potentiellement à cette version.
Filtrage : vérifier OS, configuration, protocole, authentification et conditions nécessaires.
Validation : utiliser un check non destructif ou une preuve passive.
Conclusion : documenter « confirmé », « probable » ou « non confirmé » selon les preuves disponibles.

Que Documenter Pendant le Scan ?

Evidence

Preuves techniques

  • Adresse IP / hostname.
  • Port et protocole.
  • Service/version.
  • Commande exécutée.
  • Sortie pertinente du scanner.
  • Date et contexte du test.

Pour le rapport

  • Description courte.
  • Preuve reproductible.
  • Impact potentiel.
  • Conditions d'exploitation.
  • Remédiation.
  • Résultat du retest.

Priorisation Technique d'un Finding

Triage

Exposition

Internet, DMZ, réseau interne, localhost.

Préconditions

Authentification, interaction utilisateur, configuration particulière.

Impact

Confidentialité, intégrité, disponibilité et portée de l'accès.

Principe : le score du scanner est une donnée d'entrée. La qualification finale doit intégrer le contexte réel de l'actif.

Après le Scan : Éviter le « Dump de Vulnérabilités »

Reporting

À éviter

  • Copier tous les résultats du scanner.
  • Conserver des doublons.
  • Présenter une CVE comme confirmée sans preuve.
  • Confondre version vulnérable et exploitation certaine.

À faire

  • Regrouper les findings.
  • Éliminer les faux positifs.
  • Conserver les preuves.
  • Expliquer les conditions réelles.
  • Associer une remédiation exploitable.

Checklist Opérationnelle — Vulnerability Assessment

Checklist
☐ Scope et exclusions vérifiés
☐ Hôtes et ports découverts
☐ Services et versions identifiés
☐ OS/fingerprint évalué
☐ Scans automatisés exécutés avec un périmètre contrôlé
☐ Findings importants validés manuellement
☐ Faux positifs éliminés
☐ Preuves conservées
☐ Findings corrélés et dédoublonnés
☐ Remédiations documentées

Arbre de Décision — Du Port Ouvert au Finding

Decision Flow
Port ouvert ? → Non : poursuivre la découverte. → Oui : identifier le service.
Version fiable ? → Non : approfondir le fingerprinting. → Oui : rechercher les vulnérabilités applicables.
Conditions présentes ? → Non : finding non applicable. → Oui : tenter une validation sûre.
Preuve suffisante ? → Non : conserver comme piste. → Oui : documenter le finding.
Impact significatif ? → contextualiser et prioriser avec l'environnement réel.

Mini Cheatsheet — Vulnerability Assessment

Cheatsheet

Nmap

nmap -sV -sC <IP>
nmap -O <IP>
nmap -A <IP>
nmap --script vuln <IP>
nmap --script-help <script>

Metasploit

search cve:<CVE>
search type:auxiliary scanner
use auxiliary/...
set RHOSTS <IP>
check
run

Mini Cheatsheet — Web & Corrélation

Cheatsheet

Web

curl -I http://<IP>
whatweb http://<IP>
nikto -h http://<IP>
ffuf -w wordlist.txt -u http://<IP>/FUZZ

MSF / Nessus

db_import rapport.nessus
vulns
vulns -p <port>
hosts
services

Synthèse & Methodology Checklist — Chapitre 4

Récapitulatif

Checklist Pratique de Vulnerability Assessment

  • 1. Objectif : identifier les vulnérabilités, pas encore les exploiter en profondeur — cette phase sera approfondie dans les chapitres de pentesting.
  • 2. Contexte : connaître les CVE majeures (EternalBlue, BlueKeep, Shellshock) aide à prioriser un audit, même sans les exploiter immédiatement.
  • 3. Vérification : un module auxiliaire MSF permet de confirmer qu'une cible est vulnérable avant toute tentative d'exploitation.
  • 4. Outils tiers : Nessus et WMAP automatisent le scan, mais un résultat automatisé se vérifie toujours manuellement.
  • 5. Facteur humain : le Pass-the-Hash rappelle qu'un accès peut aussi passer par des identifiants compromis, pas uniquement par une faille logicielle.