CVE et NVD vous aident à trouver les informations pour sur des vulnérabilités. Ces ressources publiques permettent d’identifier celles déjà connues, de comprendre leur gravité et de retrouver les recommandations associées.
Vous apprendrez à déchiffrer un identifiant CVE, à consulter une fiche NVD et à repérer les versions concernées. L’objectif de ce chapitre : transformer une référence obscure en informations utiles.
Comprendre ce qu’est une vulnérabilité
Une vulnérabilité est une faiblesse dans un logiciel, un équipement ou un système. Une personne malveillante peut parfois l’utiliser pour accéder à des données, modifier un contenu ou interrompre un service.
Imaginez une application qui laisse télécharger les factures des autres clients en changeant simplement un numéro dans l’adresse. Ce défaut de contrôle d’accès constitue une vulnérabilité.
Un exploit, lui, est un moyen d’exploiter cette faiblesse, par exemple un programme spécialement conçu pour déclencher le problème.
CVE : un identifiant commun pour chaque faille
CVE signifie Common Vulnerabilities and Exposures. Le programme CVE attribue des identifiants communs aux vulnérabilités publiques et publie les fiches correspondantes.
Sans cette référence, un éditeur, un chercheur et un administrateur pourraient parler de la même faille sous trois noms différents. Avec un identifiant partagé, tout le monde retrouve le bon dossier. Une sorte de numéro de suivi, sans le colis perdu.
Comment lire un identifiant CVE ?
Prenons cet exemple :
CVE-2021-44228Le préfixe indique qu’il s’agit d’une référence CVE. L’année correspond à l’attribution de l’identifiant ou à la divulgation publique selon les règles du programme ; elle ne donne pas nécessairement la date de découverte. Le dernier nombre distingue la fiche : il n’indique pas sa gravité.
Une fiche publiée contient notamment une description et des références. Les organismes autorisés à attribuer ces identifiants sont appelés CNA : ce sont, par exemple, des éditeurs ou des organismes de cybersécurité.
Retrouver une fiche CVE
Ouvrez cve.org, puis recherchez l’identifiant complet. Pour notre exemple, vous pouvez accéder directement à CVE-2021-44228.
Cette vulnérabilité, surnommée Log4Shell, concerne Log4j, un composant Java servant à enregistrer les événements d’une application. Dans certaines conditions, elle permet l’exécution de code à distance : un attaquant peut faire exécuter des instructions par le système touché.
Lisez d’abord la description, puis les liens vers les avis de sécurité. Ceux-ci précisent les produits concernés et les corrections proposées.
Utilisez CVE.org pour le pentesting
Sur CVE.org, vous obtenez principalement une « carte d’identité » officielle de la vulnérabilité ainsi que des liens vers les sources qui vous permettront de creuser.
Il est important de noter que CVE.org fonctionne comme un annuaire centralisé : il ne fournit pas directement les détails techniques d’exploitation, mais il vous oriente vers eux. En tant que pentesteur, voici ce que vous y trouverez :
La description détaillée (Le « Quoi ? »)
C’est un résumé textuel qui explique la nature du problème. On y apprend :
- Quel composant du logiciel pose problème (par exemple, un module de journalisation, une fonction d’authentification).
- Quelle est l’erreur de conception ou de programmation (par exemple, le logiciel accepte des données sans les vérifier).
- Ce qu’un attaquant peut réussir à faire (par exemple, exécuter du code à distance, voler des données, ou faire planter le service).
Pour l’identifiant CVE de notre exemple, la fiche explique que la bibliothèque Java Log4j (un outil utilisé par des millions de serveurs pour noter les journaux d’activité) gère mal les requêtes de recherche de texte. Si un attaquant envoie un message texte spécifique contenant un lien malveillant, le serveur le lit et va télécharger puis exécuter du code à distance de manière totalement autonome.
Le type de faiblesse (La classification CWE)
La fiche indique souvent un code CWE (Common Weakness Enumeration). C’est la catégorie officielle de l’erreur. Par exemple, elle indique s’il s’agit d’une injection SQL, d’un dépassement de mémoire (buffer overflow), ou d’un défaut de gestion des mots de passe. Cela permet de comprendre la « famille » de la faille.
Le périmètre exact des logiciels touchés (Les versions)
C’est une liste très précieuse qui indique :
- Le nom du produit et l’éditeur concerné.
- Les versions exactes qui contiennent la faille (par exemple : du logiciel X de la version 1.0 à la version 3.2).
- Souvent, la version à partir de laquelle le problème a été corrigé (la mise à jour salvatrice).
Pour Log4Shell, la fiche liste toutes les versions d’Apache Log4j concernées (de la version 2.0-beta9 à la version 2.14.1), tout en indiquant généralement la version corrigée vers laquelle il faut mettre à jour.
En pentesting, utiliser le périmètre exact des logiciels touchés (les numéros de version précis) permet de passer de la simple découverte à une attaque ciblée, propre et efficace.
Voici concrètement comment les pentesters exploitent cette information :
- Identifier la version sur la cible (Banner Grabbing) Lors de la phase de reconnaissance, le pentester scanne le système pour récupérer la version exacte du service qui tourne (par exemple, découvrir qu’un serveur web utilise Apache 2.4.49).
- Vérifier l’appartenance à la fourchette vulnérable Il compare cette version avec la liste des versions touchées indiquée dans la fiche CVE. Si le logiciel scanné est inclus dans la tranche (par exemple, de la version 2.4.0 à 2.4.49), la cible est validée comme potentiellement vulnérable.
- Choisir le bon script d’exploitation Un exploit informatique est souvent très pointilleux : s’il ne correspond pas exactement à la version du logiciel, il peut simplement faire planter le service (provoquer un crash ou un déni de service) au lieu de donner un accès discret. Connaître le périmètre exact permet de sélectionner le code ou le module (sur Metasploit ou Exploit-DB) taillé sur mesure.
- Éviter les faux positifs (les pièges de version) Parfois, un éditeur de logiciels applique un correctif de sécurité sur une ancienne version sans changer le numéro de version officiel (on appelle cela le backporting). Le pentester utilise sa connaissance fine du périmètre et des notes de l’éditeur pour croiser d’autres indices et s’assurer que la faille est bien présente avant d’agir.
Le niveau de gravité et les conditions (Le score CVSS et le vecteur)
La fiche fournit une évaluation chiffrée (de 0 à 10) accompagnée d’une « formule » (le vecteur CVSS) qui détaille le contexte de l’attaque :
- À distance ou en local ? L’attaquant doit-il être physiquement sur la machine ou peut-il agir depuis Internet ?
- Privilèges requis : Faut-il déjà avoir un compte sur le système ou n’importe quel inconnu peut-il attaquer ?
- Interaction utilisateur : Est-ce que la victime doit cliquer quelque part ou ouvrir un fichier, ou l’attaque est-elle totalement automatique ?
- Impact : Les données sont-elles volées, modifiées, ou le système est-il simplement détruit ?
Pour notre exemple de vulnérabilité, le score attribué est le maximum possible, soit 10,0 / 10 (Critique). Pourquoi ? Parce que l’attaque peut être menée entièrement à distance, sur Internet, sans qu’aucun mot de passe ni compte ne soit requis, et sans que l’utilisateur n’ait besoin de cliquer sur quoi que ce soit.
L’historique et la traçabilité
On peut y lire :
- La date à laquelle la faille a été découverte et publiée pour la première fois.
- L’organisation ou le chercheur qui a découvert la vulnérabilité.
- L’agence ou l’entreprise (appelée CNA) qui a attribué et validé cette CVE.
Les liens et ressources externes (La section « Références »)
C’est la partie la plus utile pour aller plus loin ou pour le pentesting :
- Des liens vers les bulletins de sécurité officiels de l’éditeur du logiciel.
- Des analyses techniques approfondies rédigées par des experts en cybersécurité.
- Des liens vers des codes de démonstration (Proof of Concept ou PoC) pour comprendre concrètement comment la faille se déclenche.
Pour Log4Shell, vous y trouverez des liens directs vers le site d’Apache pour télécharger les correctifs de sécurité urgents, ainsi que des articles d’analyse technique et des exemples de scripts sur GitHub permettant de comprendre comment le mécanisme fonctionne.
La section « Références » d’une fiche CVE est souvent considérée comme la mine d’or du pentester pour plusieurs raisons très concrètes :
- Obtenir des scripts d’exploitation prêts à l’emploi (PoC) Les liens renvoient souvent vers des dépôts GitHub ou des plateformes spécialisées où des chercheurs en sécurité ont partagé un Proof of Concept (un code de démonstration). Le pentester y trouve directement le code (souvent en Python ou en script shell) qui permet de reproduire la faille, lui évitant d’avoir à l’écrire de zéro.
- Comprendre la logique interne de la faille Les articles de blogs de cybersécurité ou les analyses techniques listés dans les références expliquent pourquoi le code bugue (par exemple, comment un paramètre est mal nettoyé). En lisant ces explications, le pentester comprend comment adapter l’attaque si la cible est protégée ou configurée d’une manière légèrement inhabituelle.
- Repérer les contournements de correctifs (Bypasses) Parfois, un premier correctif publié par l’éditeur était incomplet. Les références pointent souvent vers des articles montrant que le correctif pouvait être contourné d’une autre manière, ce qui offre de nouvelles pistes d’attaque si la cible a appliqué une mise à jour partielle.
- Trouver des outils de détection ou de scan spécifiques Certaines références pointent vers des scripts créés par la communauté pour détecter rapidement si un serveur est vulnérable sans l’endommager, ce qui permet au pentester de valider sa cible discrètement avant de lancer une action plus intrusive.
NVD : des informations pour évaluer la vulnérabilité
La NVD, pour National Vulnerability Database, est une base américaine du NIST, un organisme de référence en matière de normes et de technologies.
Elle reprend les vulnérabilités publiées dans CVE et les complète avec des informations d’analyse lorsqu’elles sont disponibles.
| Ressource | Utilité principale |
|---|---|
| CVE | Identifier une vulnérabilité et publier sa fiche de référence |
| NVD | Rassembler et enrichir les informations utiles à son évaluation |
La distinction reste souple : une fiche CVE peut aussi contenir des scores et des informations détaillées. La NVD n’a donc pas l’exclusivité de l’analyse.
La CVE est simplement un annuaire mondial qui attribue un identifiant unique et une courte description à chaque faille de sécurité pour lui donner un nom officiel. La NVD (National Vulnerability Database), gérée par le gouvernement américain, reprend ces fiches CVE pour les enrichir d’informations plus poussées : elle y ajoute notamment une analyse d’impact détaillée, le score de gravité CVSS, la liste exacte des logiciels configurés qui sont touchés et des liens vers des correctifs.
En résumé, la CVE donne un nom et un résumé à la vulnérabilité, tandis que la NVD en fournit une analyse complète et exploitable.
Comprendre le score CVSS
Sur une fiche NVD, vous rencontrerez souvent CVSS, un système de notation de la gravité technique des vulnérabilités.
Voici l’échelle utilisée notamment par CVSS 3.1 et 4.0 :
| Score | Gravité |
|---|---|
| 0,0 | Nulle |
| 0,1 à 3,9 | Faible |
| 4,0 à 6,9 | Moyenne |
| 7,0 à 8,9 | Élevée |
| 9,0 à 10,0 | Critique |
Cette classification permet d’interpréter rapidement une note.
Un score de base élevé signale un problème techniquement sérieux. Il ne mesure cependant pas, à lui seul, le risque pour un site. L’exposition sur Internet, la configuration et la présence réelle du composant comptent aussi.
Regardez également la version de CVSS et l’organisme ayant fourni le score : plusieurs évaluations peuvent apparaître sur une fiche.
Décoder CPE et CWE
Le CPE est une manière standardisée de nommer les produits et leurs versions. Il aide à préciser quels logiciels sont concernés.
Le CWE classe les catégories de faiblesses : mauvais contrôle d’accès, validation insuffisante des données, etc.
Pour retenir la différence : CVE désigne une faille précise, CWE décrit sa famille et CPE identifie des produits.
Consulter une fiche NVD étape par étape
Pour consulter et exploiter une fiche sur la base NVD (National Vulnerability Database) lors d’un test d’intrusion, voici la procédure détaillée étape par étape, illustrée avec l’exemple concret de la célèbre faille CVE-2021-44228 (Log4Shell).
Commencez par accéder au site et rechercher la référence de la vulnérabilité. Rendez-vous sur le site officiel de la NVD (nvd.nist.gov). Dans la barre de recherche principale, tapez directement l’identifiant CVE.
Pour l’exemple avec Log4Shell, vous tapez CVE-2021-44228 dans la barre de recherche. Le site vous ouvre la page web dédiée à cette faille précise.
Lire la description officielle
En haut de la page, vous trouverez le résumé textuel rédigé par les experts. Il vous indique en quelques lignes ce que fait la faille et pourquoi le code informatique réagit mal.
Pour Log4Shell, la description indique que la bibliothèque Java Apache Log4j ne protège pas correctement contre des requêtes d’annuaire (JNDI), permettant à un attaquant de charger du code malveillant à distance.
Analyser le score CVSS et le vecteur d’attaque (Le « mode d’emploi » de l’exploit)
Faites défiler la page pour trouver la section CVSS Severity. C’est ici que vous étudiez la gravité, mais surtout les conditions requises pour réussir l’attaque. Regardez les sous-critères (le « vecteur ») :
- Attack Vector (AV) : Est-ce exploitable sur le réseau (Network) ou faut-il être physiquement sur la machine (Local) ?
- Privileges Required (PR) : Faut-il un mot de passe ou un compte utilisateur (Low/High), ou aucun accès préalable (None) ?
- User Interaction (UI) : Est-ce que la victime doit cliquer quelque part (Required) ou l’attaque est-elle automatique (None) ?
Exemple (Log4Shell) : Vous lisez un score de 10,0 / 10 (Critique). Le vecteur indique : Réseau (AV:N), Zéro privilège requis (PR:N), Zéro interaction utilisateur (AV:N). Pour un pentester, cela signifie : « C’est le jackpot, on peut attaquer n’importe quel serveur sur Internet de manière totalement automatisée et sans être connecté ».
Vérifier la liste des logiciels et versions touchés (Les CPE)
Recherchez la section dédiée aux logiciels affectés (souvent étiquetée sous le format CPE – Common Platform Enumeration). La NVD y liste de manière structurée tous les produits, fabricants et numéros de versions exacts qui possèdent le bug.
Exemple (Log4Shell) : La NVD déploie la liste des produits de la fondation Apache, montrant que toutes les versions de Log4j de la 2.0-beta9 à la 2.14.1 sont concernées, ce qui vous permet de valider si la version repérée sur votre cible lors de vos scans correspond.
Cette partie n’est parfois pas présente. C’est tout à fait normal et c’est un problème fréquent lors de la consultation de certaines fiches sur la NVD.
Sur une fiche NVD, la liste des logiciels touchés (les codes CPE) est censée se trouver dans une section intitulée « Configurations » ou « Known Affected Software Configurations », placée un peu plus bas sur la page, après les scores de gravité CVSS.
Si cette section est vide ou semble incomplète, c’est principalement dû aux retards de traitement et aux arriérés (backlogs) de la NVD. L’équipe du NIST prend parfois beaucoup de temps à analyser et à associer manuellement les codes CPE normalisés à chaque nouvelle faille, ce qui laisse certaines fiches sans cette liste technique pendant de longues périodes.
Puisque la NVD peut parfois manquer de données techniques structurées sur certaines fiches, les professionnels contournent le problème ainsi :
- Lisez attentivement la description textuelle : Le résumé situé tout en haut de la fiche donne presque toujours la fourchette exacte des versions vulnérables en clair (par exemple, pour la CVE-2021-44228, la description mentionne explicitement « Apache Log4j2 2.0-beta9 through 2.15.0 »).
- Consultez la section « References » : Tout en bas de la page NVD, suivez les liens vers les bulletins de sécurité officiels de l’éditeur (comme le site d’Apache). C’est là que se trouve la source la plus fiable et la plus rapide pour connaître le périmètre exact.
- Vérifiez sur CVE.org : L’annuaire officiel cve.org intègre parfois les détails de version fournis par l’organisation d’origine (le CNA) de manière plus directe.
Explorer les liens et références externes
Tout en bas de la fiche NVD, vous trouverez la section References. C’est une liste de liens hypertextes classés par catégories (avis de l’éditeur, bulletins de sécurité, articles d’analyse).
Exemple (Log4Shell) : La NVD liste des dizaines de liens vers le site d’Apache, des alertes de CERT gouvernementaux et des dépôts de code tiers expliquant comment tester la vulnérabilité, ce qui vous donne des pistes directes pour trouver un script de test adapté.
En pentesting, trouver une CVE marque le début de l’enquête avant l’exploitation. Le logiciel est-il réellement concerné ? Sa configuration permet-elle d’exploiter la faille ? Quelles seraient les conséquences pour l’organisation ? CVE et NVD vous donnent des pistes ; vos vérifications sur un périmètre autorisé permettent d’établir le risque réel.
Pour progresser, choisissez une vulnérabilité documentée et étudiez-la dans un laboratoire de test. Comparez les informations de sa fiche avec vos observations, puis vérifiez l’efficacité du correctif. Vous apprendrez ainsi à transformer une alerte en un constat solide, accompagné de recommandations utiles : c’est là que votre travail de pentester prend toute sa valeur.
Fondateur de l’agence Créa-troyes.
Affilié France Num
Intervenant en Freelance.
Contactez-moi