Regard critique sur CVSS

Pendant très longtemps, l’évaluation de la gravité d’une faille de sécurité est restée un exercice délicat. D’un côté, les chercheurs en sécurité décrivaient le problème sous son jour le plus noir, et de l’autre les éditeurs ou constructeurs tempéraient systématiquement – quand ils ne niaient pas purement et simplement le problème.

Aucune échelle commune n’étant définie, il fallait faire confiance à l’un ou l’autre, et apprendre à déchiffrer les différents bulletins de sécurité pour savoir si le risque était réellement faible, moyen, élevé, critique, si on se trouvait plutôt « dans le vert », « dans le rouge », ou au milieu de tout cela. À moins d’avoir de bonnes bases techniques, il était donc aisé de tomber dans la paranoïa ou – pire – d’ignorer les problèmes.

C’est de ce constat qu’est né CVSS (Common Vulnerability Scoring System), un système de notation des vulnérabilités créé par le FIRST (Forum of Incident Response and Security Teams) et largement soutenu par les éditeurs logiciels et les constructeurs. Son principal objectif est de permettre de calculer, comparer et de comprendre la gravité des failles de sécurité. Il est utilisé par la majorité des bases de données (CVE, NVD, OSVD, Security Focus, Secunia, etc.) et par de nombreux acteurs de l’informatique  (Cisco, Oracle, Adobe, Qualys, etc.)

Cet article fait référence à la version actuelle de CVSS (CVSSv2).

Une notation détaillée et transparente

CVSS permet de calculer trois notes :

• Un score de base, permettant à tous d’évaluer un problème. C’est ce score qui est le plus couramment utilisé, notamment par les auditeurs.
• Une note environnementale, qui permet de prendre en compte les spécificités de l’environnement ciblé pour ajuster le score de base en fonction du contexte., qui permet de tenir compte du cycle de vie de la vulnérabilité : a-t-elle été corrigée, existe-t-il des mesures palliatives, est-elle activement exploitée ? Comme la note environnementale, elle permet de revoir le score de base à la hausse ou à la baisse.  

Sans rentrer dans les détails du calcul de la note (dont l’algorithme est public), le score de base repose sur l’évaluation de deux métriques : l’exploitabilité de la vulnérabilité et l’impact qu’elle peut avoir sur la sécurité. Chacune de ces deux métriques est évaluée en fonction de trois critères.

Pour l’exploitabilité :

• Le vecteur d’accès : la vulnérabilité peut être exploitée depuis Internet, depuis un réseau adjacent, ou requiert un accès local ?
• La complexité d’accès : est-il simple, modérément complexe ou très complexe d’accéder au composant vulnérable ? 
• Les pré-requis d’authentification : est-il possible d’accéder de façon anonyme au composant vulnérable pour exploiter la faille ? Ou y’a-t-il un, ou plusieurs niveaux d’authentification ?

Pour l’impact :

• L’impact sur la confidentialité : est-il complet, partiel ou inexistant ?
• L’impact sur l’intégrité : est-il complet, partiel ou inexistant ?
• L’impact sur la disponibilité : est-il complet, partiel ou inexistant ? 

Une fois les différents critères évalués, on obtient une note finale sur 10. Plus le score est élevé, plus la vulnérabilité est critique. On obtient également – et c’est là que CVSS est particulièrement intéressant – un vecteur de reproduction détaillé, qui permet de savoir comment chaque critère a été évalué pour calculer la note.

Prenons un exemple : un site web est configuré pour retourner des pages d’erreur extrêmement détaillées, contenant des références au code fautif. En cela, il divulgue des informations potentiellement sensibles qui permettront à une personne malintentionnée de mieux cibler les attaques.

Il s’agit ici d’un site web, très simplement accessible depuis Internet avec un navigateur. Aucune connaissance technique particulière n’est nécessaire pour pousser le serveur à la faute, et aucune authentification n’est nécessaire.

L’exploitabilité peut donc s’exprimer ainsi :

• Vecteur d’accès : Internet (Access Vector: Network)
• Complexité d’accès : Faible (Access Complexity: Low)
• Authentification : Aucune (Authentication: None) 

Le vecteur partiel représentant cette métrique s’écrira ainsi : AV:N/AC:L/Au:N

L’impact, quant à lui, ne porte que sur la confidentialité. Et l’atteinte n’est que partielle :

• Impact sur la Confidentialité : Partiel (Confidentiality Impact: Partial)
• Impact sur l’Intégrité : Aucun (Integrity Impact: None)
• Impact sur la Disponibilité : Aucun (Availability Impact: None)

Le vecteur partiel représentant cette métrique s’écrira donc : C:P/I:N/A:N 

Le vecteur final correspondant à cette vulnérabilité sera donc : AV:N/AC:L/Au:N/C:P/I:N/A:N. Ce vecteur correspond à un score de 5.0, ce qui en fait une vulnérabilité de criticité moyenne. Ce score peut être déterminé ou vérifié très simplement en utilisant le calculateur CVSS du NIST, disponible en ligne.

Un score de base parfois inadapté

Le même problème peut parfois avoir un impact très différent.

Imaginons qu’il soit possible d’accéder de façon anonyme à l’ensemble des documents qui sont uploadés sur un site en contournant une étape de validation :

• Sur un site de partage destiné à héberger des photos des plats préférés des utilisateurs, l’impact sera potentiellement mineur. Au pire, on pourra accéder à la photo du dimsum raté dont Bernard avait un peu honte (mais pas suffisamment pour ne pas la garder pour lui, visiblement).
• Sur un site permettant de charger des documents confidentiels, en revanche, l’impact sera majeur. On pourrait y trouver des contrats, des copies de pièces d’identité, des fiches de paie…

Dans les deux cas, on obtiendra le même vecteur et le même score (ici 5.0, avec le même vecteur que celui que l’on vient de calculer plus haut). Cela ne reflète aucunement la situation réelle, et c’est une limite claire du score de base. C’est l’une des raisons pour lesquelles les critères environnementaux existent.

Ces critères sont au nombre de cinq, et sont tous optionnels :

• Le potentiel de dommage collatéral lié à la vulnérabilité (Aucun, Faible, Faible à Moyen, Moyen à Élevé, Élevé)
• Le nombre de systèmes vulnérables dans l’environnement cible (Aucun, Faible, Moyen, Élevé)
• Le niveau d’exigence en termes de confidentialité (Faible, Moyen, Élevé)   
• Le niveau d’exigence en termes d’intégrité (Faible, Moyen, Élevé)
• Le niveau d’exigence en termes de disponibilité (Faible, Moyen, Élevé)

Si on reprend les deux exemples ci-dessus, dans un cas les dommages collatéraux sont faibles et dans l’autre ils sont potentiellement catastrophiques. De même, le niveau d’exigence en termes de confidentialité n’est pas le même (faible pour l’un, élevé pour l’autre). En intégrant ces deux critères au calcul, on obtiendra deux scores finaux bien différents :

• 4.5 pour le premier cas (AV:N/AC:L/Au:N/C:P/I:N/A:N/CDP:L/CR:L). Ce score est moyen et correspond relativement bien au niveau de criticité de la faille.
• 8.0 pour le second cas (AV:N/AC:L/Au:N/C:P/I:N/A:N/CDP:H/CR:H). Ce score est cohérent et correspond à la criticité élevée de la faille.

On voit ici clairement les limites du score de base, et l’intérêt de l’affinage au moyen des critères environnementaux.

Pour autant, il est parfois difficile pour un auditeur d’évaluer correctement ces critères environnementaux. Sans une connaissance détaillée de la cible – ce qui est assez classique lors de tests en boîte noire – évaluer le potentiel de dommages collatéraux est périlleux. Or, sans ce critère, le score obtenu dans le second cas est nettement moins élevé (6.0 – AV:N/AC:L/Au:N/C:P/I:N/A:N/CR:H) et reflète mal la criticité de la faille.

Malgré ses qualités, CVSS a donc des limites parfois complexes à dépasser, et un score peut être vidé de sa substance en sous-utilisant ou en abusant des critères optionnels.

Des critères temporels confus

Le troisième groupe de critères permet de suivre le cycle de vie d’une vulnérabilité et – une fois de plus – d’en ajuster la note. Il couvre :

• L’exploitabilité – existe-t-il un code public permettant d’exploiter la vulnérabilité, est-il fonctionnel, est-ce une preuve de concept, a-t-on un doute sur son existence ?
• L’existence de contre-mesures – sont-elles disponibles, n’existe-t-il que des solutions palliatives, ou un correctif non-officiel ?
• L’existence même de la vulnérabilité – a-t-elle été confirmée, ou n’a-t-on que des soupçons ?

Lorsque l’on a une confiance pleine dans l’existence des vulnérabilités, comme c’est souvent le cas lors d’un audit, ces critères sont peu adaptés. De plus, dans la mesure où ils ne permettent que d’abaisser la criticité d’une vulnérabilité, on peut se poser la question de savoir s’il est toujours judicieux de les utiliser ; sous prétexte qu’une vulnérabilité n’a pas  encore été exploitée, est-il souhaitable d’en minorer la note ? Cela ne risque-t-il pas de donner au lecteur un faux sentiment de sécurité, alors qu’une vulnérabilité de type 0day  est peut-être déjà en train de compromettre son périmètre ?

En vérité, il y a débat. Un consensus semble néanmoins se dégager dans les discussions en cours autour de CVSSv3, qui consisterait à utiliser les critères temporels pour élever le score plutôt que de le réduire. En attendant, je suis de ceux qui préféreront un score élevé accolé à un plan d’action clair.

Il peut néanmoins être intéressant, par exemple pour un CERT ou dans une démarche d’observation continue de la sécurité d’un périmètre, de mettre à jour le score d’une vulnérabilité au fil du temps.

CVSS sous le feu des critiques 

Outre ces difficultés à juger du contexte pour obtenir un score reflétant la réalité des problèmes, de nombreuses critiques ont été faites à CVSS.

La plus fréquente concerne l’évaluation des impacts en trois niveaux (aucun, partiel, complet), et insiste sur son manque de granularité : en effet, un message d’erreur révélant l’adressage IP interne et une vulnérabilité de type path traversal permettant de télécharger le fichier /etc/passwd auront tous les deux un impact partiel sur la confidentialité, mais les conséquences seront potentiellement très différentes. Plusieurs sociétés ont émis l’idée d’introduire un niveau supplémentaire pour permettre de refléter cette différence. C’est notamment le cas d’Oracle, qui a introduit un niveau « partiel+ », déviant ainsi de la norme CVSSv2.

Une autre critique courante est l’impossibilité d’évaluer correctement la sécurité des mots de passe avec CVSS. Il est courant de trouver sur un réseau des périphériques ou des applications configurés avec un mot de passe par défaut ; en utilisant ce mot de passe, on prend le contrôle de la cible, voire de l’environnement complet ; pour autant, comment refléter de défaut de sécurisation en utilisant CVSS ? Si on positionne le critère « Authentification » à « Simple », le score baisse drastiquement, échouant ainsi à refléter la réalité de la criticité. Mais  en le positionnant à « Aucune », on tord également la réalité pour obtenir un score, ce qui va à l’encontre du principe de transparence de la notation. Lors de nos audits, nous sommes régulièrement confrontés à ce dilemme.

Autre reproche justifié, il est impossible d’évaluer la criticité d’un scénario d’attaque avec CVSS. Parfois, il est possible d’exploiter plusieurs vulnérabilités de criticité modérée pour arriver à compromettre complètement un périmètre. Cependant, l’évaluation CVSS ne portera que sur chacune des failles prises de façon indépendante ; il sera nécessaire pour l’auditeur de présenter le scénario dans sa globalité et de mettre en lumière le risque final, sans qu’il ne puisse s’appuyer sur un vecteur d’évaluation spécifique.

Enfin, on peut reprocher à CVSS sa trop grande granularité ; il est parfois difficile, voire inutile, de faire une différence entre un score de 5.6 et un score de 5.8. Le FIRST a d’ailleurs proposé une échelle simplifiée à trois niveaux pour répondre à cette critique :

• Un score de 0 à 3.9 correspond à une criticité basse
• Un score de 4 à 6.9 correspond à une criticité moyenne
• Un score de 7 à 10 correspond à une criticité haute

Un bilan plutôt positif

Malgré les reproches qu’on peut lui faire, la notation CVSS va dans le bon sens :

• Pour une société souhaitant évaluer son niveau de sécurité, elle permet de mieux comprendre l’évaluation faite par l’auditeur. En utilisant les critères environnementaux pour affiner l’analyse, elle permet également de mettre en avant les failles posant un risque fort et de mieux gérer les plans d’actions correctives.
• Pour une société réalisant des audits, elle pousse le consultant à bien considérer chaque problème et son impact, et limite les évaluations alarmistes ou fantaisistes. Elle permet également d’appuyer son propos auprès du client, grâce au vecteur détaillé notamment.
• De par sa large adoption par les différents acteurs du marché de la sécurité, elle permet enfin de disposer d’une base de discussion et d’évaluation commune. Cette normalisation, malgré ses imperfections, est la bienvenue.

Pour finir, le FIRST essaie de répondre aux différentes critiques faites à CVSSv2 en incluant encore davantage d’acteurs dans le processus de normalisation de la version 3. Cette version devrait être stabilisée courant 2014. Gageons que d’ici là, le débat sera passionnant.