cyber / pentest-red-team

Analyse de vulnérabilités : scanners et gestion des CVE

Leçon 51 exercice

Explication

Ce que vous allez apprendre

Utiliser des scripts NSE orientés détection de CVE connues
Rechercher des exploits publics correspondant à une version de service identifiée
Interroger l'API NVD pour enrichir un CVE avec son score CVSS
Distinguer le score CVSS (sévérité théorique) du score EPSS (probabilité réelle d'exploitation)
Valider manuellement un résultat de scanner avant de le remonter dans un rapport

Dans quel contexte ?

L'énumération de services (leçon précédente) a révélé qu'un serveur de lab fait tourner Apache 2.4.49. Ce simple numéro de version, en apparence anodin, peut en réalité correspondre à une vulnérabilité critique déjà documentée et activement exploitée dans la nature — encore faut-il savoir comment le vérifier méthodiquement plutôt que de deviner.

D'abord, il faut comprendre ce qu'apporte un scanner automatisé, et ses limites

Des scanners professionnels comme Nessus ou OpenVAS automatisent la détection de vulnérabilités connues à grande échelle, un gain de temps considérable sur un périmètre large. Mais un scanner automatisé se trompe régulièrement : un header serveur modifié par le défenseur, une version rétroportée (patché sans changer le numéro de version affiché) produisent des faux positifs qu'aucun outil ne peut détecter seul.

Une fois un résultat de scanner obtenu, comment vérifier qu'un exploit existe réellement pour cette version ?

searchsploit interroge une base locale d'Exploit-DB pour trouver des preuves de concept publiques correspondant à une version de service précise. Récupérer un exploit avec -m permet de l'analyser avant toute exécution — jamais de lancer un exploit "à l'aveugle" sans en comprendre le fonctionnement, particulièrement en environnement de test partagé.

Indicateur	Ce qu'il mesure	Limite
CVSS	Sévérité théorique intrinsèque d'une vulnérabilité	Ne dit rien sur la probabilité réelle d'exploitation
EPSS	Probabilité réelle d'exploitation dans les 30 prochains jours	Complète le CVSS, ne le remplace pas
Exploit public disponible	Facilité pratique d'exploitation	N'existe pas pour toutes les CVE, même critiques

Prérequis

Cette leçon suppose que des versions précises de services ont déjà été identifiées via l'énumération (voir la leçon précédente) : sans version connue, impossible de rechercher une CVE correspondante de façon fiable.

Maintenant, une question de priorisation essentielle en conditions réelles

Astuce

Un score CVSS élevé ne signifie pas automatiquement une priorité absolue : croise-le systématiquement avec le contexte métier. Un service critique exposé directement sur Internet avec un exploit public disponible mérite un traitement immédiat ; le même score CVSS sur un service isolé sur un VLAN interne sans accès reste important, mais nettement moins urgent. Le score EPSS, plus récent, formalise justement cette nuance en estimant la probabilité réelle d'exploitation à court terme.

Il reste une étape que rien ne remplace : la vérification manuelle

Piège fréquent

Remonter dans un rapport une vulnérabilité détectée automatiquement, sans jamais l'avoir vérifiée manuellement, est l'erreur la plus fréquente d'un pentester débutant. Un scanner qui affirme "Apache 2.4.49 vulnérable" peut se tromper si le header Server a été modifié ou masqué par le défenseur — une simple requête curl -sI permet souvent de lever le doute en quelques secondes, avant de perdre du temps sur une piste fausse.

Cette analyse de vulnérabilités maîtrisée, la prochaine leçon entre dans le vif du sujet : l'exploitation concrète des classes de vulnérabilités web les plus fréquentes, testées uniquement sur des applications volontairement vulnérables.

Commandes & code

Analyse de vulnérabilités : scanners et gestion des CVE

Un scanner de vulnérabilités automatise la détection, mais génère aussi des faux positifs : la validation manuelle reste indispensable.

# Nessus / OpenVAS : scanners professionnels (interface web, ici via CLI d'automatisation)
# Exemple avec Nmap NSE en attendant, orienté détection de CVE connues
nmap --script vulners --script-args mincvss=7.0 -sV 192.168.56.10

# Recherche d'exploits publics correspondant à une version de service identifiée
searchsploit apache 2.4.49
searchsploit -m 50383   # copie l'exploit localement pour analyse (jamais d'exécution aveugle)

# Interroger l'API NVD pour enrichir un CVE avec son score CVSS et sa description
import requests

def get_cve_details(cve_id: str) -> dict:
    url = f"https://services.nvd.nist.gov/rest/json/cves/2.0?cveId={cve_id}"
    resp = requests.get(url, timeout=10)
    resp.raise_for_status()
    vuln = resp.json()["vulnerabilities"][0]["cve"]
    return {
        "id": vuln["id"],
        "description": vuln["descriptions"][0]["value"],
        "cvss": vuln.get("metrics", {}).get("cvssMetricV31", [{}])[0]
                    .get("cvssData", {}).get("baseScore"),
    }

print(get_cve_details("CVE-2021-44228"))

# Priorisation : CVSS seul ne suffit pas, croiser avec le contexte métier
Score CVSS élevé + service exposé sur Internet + exploit public disponible = priorité maximale
Score CVSS élevé + service isolé sur VLAN interne sans accès          = priorité réduite (mais pas nulle)

# Le score EPSS (Exploit Prediction Scoring System) complète le CVSS :
# il estime la probabilité réelle d'exploitation dans les 30 prochains jours

# Vérifier manuellement un faux positif potentiel avant de le remonter dans le rapport
curl -sI https://192.168.56.10 | grep -i "server:"
# Un scanner peut se tromper de version si le header Server est modifié/masqué par le défenseur

Résumé

Un scanner automatisé donne une base, jamais une conclusion définitive : faux positifs fréquents.
searchsploit + NVD/CVE permettent de relier une version de service à des vulnérabilités connues.
CVSS mesure la sévérité théorique ; EPSS estime la probabilité réelle d'exploitation.
Toute vulnérabilité remontée dans un rapport doit être validée manuellement.

Exercices pratiques

1 disponible

Mission : valider (ou invalider) une CVE détectée automatiquement chez NordShield

Objectif : Confirmer manuellement un résultat de scanner automatisé avant de le faire figurer dans le rapport final.

Contexte

Un scan NSE orienté CVE signale que le serveur web de lab NordShield fait tourner Apache 2.4.49, une version associée à une CVE critique connue. Avant de foncer sur un exploit, tu dois valider méthodiquement ce résultat.

Résoudre l’exercice →