HackTheBox - Vulnerability Assessment : Vulnerability Scoring and Reporting

Informations sur le module

Cette section du module Vulnerability Assessment couvre le système de notation des vulnérabilités CVSS et comment calculer correctement la sévérité d’une faille de sécurité.

Lien : Vulnerability Assessment - Vulnerability Scoring and Reporting

Objectifs d’apprentissage

Ce module couvre les compétences suivantes :

• Comprendre le système CVSS et ses différents groupes de métriques
• Calculer manuellement un score de sévérité pour une vulnérabilité
• Évaluer l’impact d’une vulnérabilité selon la triade CIA
• Prioriser les vulnérabilités en fonction de leur score et contexte

---

Vulnerability Scoring and Reporting

Pourquoi scorer les vulnérabilités ?

Quand j’ai commencé à scanner des systèmes, je me retrouvais avec des dizaines voire centaines de vulnérabilités détectées. La question qui se posait : par où commencer ?

C’est là qu’intervient le CVSS (Common Vulnerability Scoring System), un standard industriel qui permet de calculer un score de sévérité pour chaque vulnérabilité découverte.

Pour les débutants : Le CVSS est comme un système de notation sur 10 qui permet de classer les vulnérabilités de “pas grave” à “critique”. Cela aide à savoir quoi corriger en premier.

La plupart des outils de scan appliquent automatiquement ces scores, mais j’ai appris qu’il est essentiel de comprendre comment ils sont calculés pour pouvoir les justifier ou les recalculer manuellement si nécessaire.

Le modèle DREAD de Microsoft

Avant de plonger dans CVSS, j’ai découvert que Microsoft utilise un système complémentaire appelé DREAD qui évalue le risque selon 5 facteurs sur une échelle de 10 points :

Facteur	Signification	Ce que j’évalue
Damage Potential	Potentiel de dommage	Quelle destruction cette faille peut causer ?
Reproducibility	Reproductibilité	Facilité à reproduire l’exploit
Exploitability	Exploitabilité	Difficulté technique pour exploiter
Affected Users	Utilisateurs affectés	Combien de personnes sont impactées ?
Discoverability	Découvrabilité	Facilité à trouver cette faille

Ce système aide Microsoft à prioriser les correctifs pour ses produits et sert de référence pour les professionnels de la sécurité.

Structure du CVSS : Trois groupes de métriques

Le système CVSS se divise en trois groupes principaux que j’ai appris à analyser séparément :

1. Base Metric Group : Caractéristiques intrinsèques de la vulnérabilité
2. Temporal Metric Group : Disponibilité d’exploits et de patches
3. Environmental Metric Group : Impact spécifique à l’organisation

Chaque groupe apporte des informations différentes pour calculer le score final.

Base Metric Group : L’essence de la vulnérabilité

Exploitability Metrics : Comment l’exploiter ?

Ce groupe évalue les moyens techniques nécessaires pour exploiter la faille. J’analyse quatre métriques :

Attack Vector (Vecteur d’attaque)

• Détermine si l’attaquant doit être physiquement présent ou peut attaquer à distance
• Plus le vecteur est distant, plus le score est élevé

Attack Complexity (Complexité d’attaque)

• Évalue la difficulté technique de l’exploitation
• Une attaque simple augmente la sévérité

Privileges Required (Privilèges requis)

• Quel niveau d’accès l’attaquant doit avoir
• Moins de privilèges nécessaires = score plus élevé

User Interaction (Interaction utilisateur)

• L’attaque nécessite-t-elle qu’un utilisateur fasse quelque chose ?
• Aucune interaction requise = plus dangereux

Les vulnérabilités exploitables à distance sans authentification et sans interaction utilisateur sont les plus critiques.

Impact Metrics : La triade CIA

J’ai appris que l’impact se mesure selon trois piliers fondamentaux de la sécurité :

Confidentiality Impact (Impact sur la confidentialité)

Cela concerne la protection des informations sensibles.

• Haute sévérité : Un attaquant vole tous les mots de passe ou clés de chiffrement
• Basse sévérité : L’attaquant accède à des informations non critiques

Exemple personnel : Si j’exploite une faille qui me donne accès à la base de données complète des clients, l’impact sur la confidentialité est maximal.

Integrity Impact (Impact sur l’intégrité)

Cela concerne la modification non autorisée des données.

• Haute sévérité : L’attaquant modifie des fichiers critiques de l’entreprise
• Basse sévérité : L’attaquant ne peut pas contrôler précisément ce qu’il modifie

Availability Impact (Impact sur la disponibilité)

Cela concerne l’accessibilité des ressources pour l’organisation.

• Haute sévérité : L’environnement complet devient inutilisable (DoS total)
• Basse sévérité : Certains utilisateurs peuvent encore accéder à certaines ressources

Mon observation : Une vulnérabilité peut avoir un impact fort sur UN seul élément de la triade CIA et être quand même considérée comme critique.

Pour approfondir le concept de la triade CIA : NIST - CIA Triad

Temporal Metric Group : État actuel de la menace

Ce groupe évalue la disponibilité d’exploits et de correctifs. J’utilise trois métriques temporelles :

Exploit Code Maturity (Maturité du code d’exploit)

Cette métrique représente la probabilité qu’une faille soit exploitée selon la disponibilité d’outils :

Valeur	Signification	Mon interprétation
Not Defined	Métrique ignorée	Je saute cette évaluation
High	Exploit automatisé disponible	DANGER : N’importe qui peut exploiter
Functional	Code d’exploit public	Des compétences basiques suffisent
Proof-of-Concept	PoC disponible mais nécessite modifications	Attaquants expérimentés uniquement
Unproven	Théorique uniquement	Risque faible à court terme

Quand je vois une vulnérabilité avec un exploit Metasploit disponible, je sais que c’est une priorité absolue à corriger.

Remediation Level (Niveau de remédiation)

Cette métrique aide à prioriser les actions :

Valeur	Signification	Action à prendre
Not Defined	Métrique ignorée	-
Unavailable	Aucun patch disponible	Chercher des mitigations temporaires
Workaround	Solution non officielle	Appliquer en attendant le patch
Temporary Fix	Correctif temporaire du vendeur	Déployer rapidement
Official Fix	Patch officiel publié	Appliquer immédiatement

Mon expérience : J’ai appris à ne pas attendre le patch officiel si un workaround efficace existe. Mieux vaut une protection imparfaite que rien du tout.

Report Confidence (Confiance dans le rapport)

Cette métrique évalue la fiabilité des informations sur la vulnérabilité :

• Confirmed : Plusieurs sources détaillées confirment la faille
• Reasonable : Informations publiées mais manque de détails pour reproduire
• Unknown : Informations insuffisantes

Si la confiance est “Unknown”, je consacre plus de temps à la vérification manuelle avant de l’inclure dans mon rapport.

Environmental Metric Group : Impact sur MON organisation

Ce groupe est crucial car il permet d’adapter le score CVSS au contexte spécifique de l’organisation cible.

Modified Base Metrics

Les métriques de base peuvent être ajustées si l’organisation considère que l’impact sur la confidentialité, l’intégrité ou la disponibilité est différent de l’évaluation standard.

Valeur	Impact sur l’organisation
Not Defined	On garde le score de base
High	Effets astronomiques sur l’organisation et les clients
Medium	Effets significatifs
Low	Effets minimaux

Exemple concret : Une vulnérabilité sur un serveur de développement aura un score “Low”, mais la même vulnérabilité sur le serveur de production contenant les données clients sera “High”.

Calculer un score CVSS

Le calcul d’un score CVSS v3.1 prend en compte toutes les métriques que j’ai détaillées. Le National Vulnerability Database propose un calculateur officiel :

Calculateur CVSS : NIST CVSS Calculator

Exemple pratique : Windows Print Spooler RCE

J’ai analysé la vulnérabilité Windows Print Spooler Remote Code Execution :

Score CVSS Base : 8.8 (Haute sévérité)

Les métriques principales :

• Attack Vector : Network (exploitable à distance)
• Attack Complexity : Low (facile à exploiter)
• Privileges Required : Low (peu de privilèges nécessaires)
• User Interaction : None (aucune action utilisateur requise)
• Confidentiality Impact : High
• Integrity Impact : High
• Availability Impact : High

Ce score de 8.8 indique une vulnérabilité critique nécessitant un correctif immédiat.

Pour consulter les détails complets : CVE Print Spooler Details

Ce que j’ai appris sur la priorisation

Comprendre CVSS m’a permis de :

1. Justifier mes recommandations auprès des clients avec des scores standardisés
2. Prioriser efficacement les correctifs selon le contexte organisationnel
3. Comprendre l’urgence réelle d’une vulnérabilité au-delà du simple nom

Le CVSS n’est pas parfait, mais c’est un langage commun que toute l’industrie comprend.

La prochaine section couvrira comment classifier les vulnérabilités de manière standardisée pour référencer les bases de données publiques comme CVE.

---

Common Vulnerabilities and Exposures (CVE)

OVAL : Un langage standardisé pour l’évaluation

Avant de parler des CVE, j’ai découvert OVAL (Open Vulnerability Assessment Language), un standard international qui permet d’évaluer l’état de sécurité d’un système sans avoir à l’exploiter.

Pour les débutants : OVAL est comme un langage universel qui permet de décrire les vulnérabilités et configurations d’un système de manière standardisée, un peu comme l’anglais permet à différentes nationalités de communiquer.

OVAL est co-supporté par le U.S. Department of Homeland Security et contient plus de 7000+ définitions disponibles publiquement. Ce qui m’a impressionné, c’est qu’OVAL est également utilisé par le NIST SCAP (Security Content Automation Protocol) pour automatiser la gestion des vulnérabilités et vérifier la conformité des systèmes.

Pour plus d’informations sur SCAP : NIST SCAP Overview

Le processus OVAL en trois étapes

J’ai appris qu’OVAL suit une structure claire lors de l’évaluation :

1. Identifier les configurations à tester sur le système
2. Évaluer l’état actuel du système
3. Générer un rapport avec les informations découvertes

Les résultats peuvent être classés en quatre états :

• Vulnerable : Le système présente une faille
• Non-compliant : Le système ne respecte pas les politiques
• Installed Asset : Inventaire des logiciels présents
• Patched : Le système est correctement patché

Définitions OVAL : Le format XML

Les définitions OVAL sont enregistrées au format XML et permettent d’identifier les vulnérabilités, mauvaises configurations et informations système sans exploitation.

Mon observation : C’est l’un des grands avantages d’OVAL - je peux scanner un système de production sans risque de le compromettre ou de le faire planter.

Les quatre classes principales de définitions OVAL :

Classe	Fonction	Mon utilisation
Vulnerability Definitions	Identifie les vulnérabilités système	Pour mes scans de vulnérabilités
Compliance Definitions	Vérifie la conformité aux politiques	Pour les audits de conformité
Inventory Definitions	Détecte la présence de logiciels spécifiques	Pour cartographier l’environnement
Patch Definitions	Vérifie si les correctifs sont appliqués	Pour valider le patch management

Format des identifiants OVAL

Chaque définition OVAL a un identifiant unique au format : oval:Organization Domain Name:ID Type:ID Value

Les types d’ID possibles :

• def : definition (définition)
• obj : object (objet)
• ste : state (état)
• var : variable

Exemple d’identifiant : oval:org.mitre.oval:obj:1116

Des scanners comme Nessus peuvent utiliser OVAL pour configurer des templates de scan de conformité sécuritaire.

CVE : Le catalogue universel des vulnérabilités

Common Vulnerabilities and Exposures (CVE) est un catalogue public de vulnérabilités sponsorisé par le U.S. Department of Homeland Security. Chaque vulnérabilité ou exposition reçoit un identifiant CVE unique attribué par une autorité de numérotation appelée CNA (CVE Numbering Authority).

Le but du système CVE est de créer une standardisation pour référencer une vulnérabilité de manière unique à travers toute l’industrie.

Base de données CVE officielle : CVE Database

Critères pour obtenir un CVE ID

J’ai appris que toutes les vulnérabilités ne méritent pas un CVE. Pour qu’une vulnérabilité reçoive un identifiant CVE, elle doit respecter trois critères :

1. Être corrigeable indépendamment - La faille peut être patchée séparément
2. Affecter une seule base de code - Pas plusieurs produits différents
3. Être reconnue et documentée par le vendeur concerné

Si une vulnérabilité affecte plusieurs produits différents avec des bases de code distinctes, elle recevra plusieurs CVE - un par produit.

Définition d’une vulnérabilité selon CVE

Selon l’équipe CVE, une vulnérabilité doit être du code exploitable qui :

• Résulte en un impact négatif sur la confidentialité, l’intégrité OU la disponibilité
• Nécessite un changement de code, de spécification, ou une dépréciation pour être mitigée

Les 9 étapes pour obtenir un CVE

Stage 1 : Identifier si un CVE est nécessaire

Avant de demander un CVE, je dois vérifier :

• Est-ce vraiment une vulnérabilité selon la définition CVE ?
• Un CVE n’existe-t-il pas déjà dans la base de données ?

Mon conseil : J’utilise toujours la recherche CVE avant de signaler une nouvelle faille pour éviter les doublons.

Stage 2 : Contacter le vendeur du produit affecté

Je dois faire un effort de bonne foi pour contacter directement le vendeur. C’est la base de la divulgation responsable.

La divulgation responsable protège les utilisateurs en donnant au vendeur le temps de corriger avant l’annonce publique.

Documentation officielle sur les pratiques de divulgation : CVE Disclosure Practices

Stage 3 : Identifier si le vendeur est un CNA

Si l’entreprise est un CNA participant, elle peut assigner elle-même un CVE ID pour ses produits. Sinon, je dois contacter un coordinateur tiers.

Liste des CNAs participants : CVE CNAs List

Stage 4 : Demander un CVE via le formulaire web

Si les méthodes précédentes ne fonctionnent pas, l’équipe CVE propose un formulaire en ligne pour soumettre la demande.

Formulaire de demande CVE : CVE Request Form

Stage 5 : Confirmation de réception

Après soumission du formulaire, je reçois un email de confirmation. L’équipe CVE me contactera si des informations supplémentaires sont nécessaires.

Stage 6 : Réception du CVE ID

Si la vulnérabilité est confirmée, l’équipe CVE notifie l’attribution d’un CVE ID.

Important : À ce stade, le CVE ID n’est pas encore public. Il ne doit pas être divulgué avant coordination avec le vendeur.

Stage 7 : Divulgation publique du CVE ID

Le CVE ID peut être annoncé publiquement dès que les vendeurs et parties concernées sont informés. Cela évite la duplication des CVE IDs.

Mon expérience : Cette coordination est cruciale pour s’assurer que personne n’est pris au dépourvu par l’annonce.

Stage 8 : Annoncer le CVE

Lors de l’annonce de plusieurs CVE, je dois m’assurer que chaque CVE indique clairement les différentes vulnérabilités. Ne pas mélanger plusieurs failles sous un même CVE.

Stage 9 : Fournir des informations à l’équipe CVE

L’équipe CVE demande au chercheur de fournir des informations supplémentaires pour la liste officielle CVE sur le site web. Le NVD (National Vulnerability Database) maintient également ces informations.

Base de données NVD : National Vulnerability Database

Divulgation responsable : Un pilier éthique

J’ai appris que la divulgation responsable est essentielle dans la communauté sécurité. Elle permet au chercheur de travailler directement avec le vendeur en lui fournissant d’abord les détails de la faille pour qu’un patch soit disponible avant l’annonce publique.

Le danger des zero-days

Si une vulnérabilité n’est pas divulguée de manière responsable, des acteurs malveillants peuvent l’exploiter avant qu’un patch existe. On appelle cela un zero-day ou 0-day.

Un zero-day est une vulnérabilité exploitée dans la nature avant que le vendeur ne soit au courant ou ait publié un correctif.

Mon approche : Je contacte toujours le vendeur en premier et j’accorde généralement 90 jours pour le développement d’un patch avant divulgation publique, sauf si la faille est activement exploitée.

Exemples de CVE notoires

CVE-2020-5902 : BIG-IP TMUI RCE

Cette vulnérabilité est une exécution de code à distance non authentifiée dans l’interface de gestion BIG-IP Traffic Management User Interface.

Caractéristiques :

• Exploitable quand TMUI est accessible via le port de management
• Permet une prise de contrôle complète du système
• L’attaquant peut exécuter du code, éditer des fichiers, activer/désactiver des services

Détails complets : CVE-2020-5902 Details

CVE-2021-34527 : PrintNightmare

PrintNightmare est une vulnérabilité d’exécution de code à distance dans le Windows Print Spooler service. J’ai étudié cette faille en détail car elle a eu un impact majeur.

Pourquoi c’est dangereux :

• Le service Print Spooler gère mal les privilèges lors d’opérations sur les fichiers
• Nécessite seulement qu’un utilisateur soit authentifié (pas admin)
• Permet la prise de contrôle complète locale ou distante
• Exploitable sur les serveurs ET contrôleurs de domaine

Cette faille permettait à un attaquant de prendre le contrôle total d’un domaine Active Directory entier en compromettant les contrôleurs de domaine.

Mon observation : PrintNightmare a démontré qu’une vulnérabilité dans un service “banal” comme l’impression peut avoir des conséquences catastrophiques sur toute l’infrastructure.

Détails complets : CVE-2021-34527 Details

Ce que j’ai retenu

Le système CVE m’a permis de :

• Communiquer efficacement sur les vulnérabilités avec un langage universel
• Rechercher rapidement si une faille a déjà été découverte
• Comprendre l’importance de la divulgation responsable
• Référencer mes découvertes de manière standardisée

La prochaine section me permettra de mettre la main à la pâte avec deux outils populaires de scan de vulnérabilités : Nessus et OpenVAS.

Cours complété