Évaluer les vulnérabilités de sécurité 101 : présentation du CVSS pour les CVE

Comme les bogues logiciels sont classés selon leur niveau de gravité, les vulnérabilités de sécurité doivent elles aussi être évaluées en fonction de leur impact et du risque qu’elles représentent, afin de faciliter la gestion des vulnérabilités.

Le Forum of Incident Response and Security Teams (FIRST) est une organisation internationale de chercheurs et de spécialistes en sécurité informatique reconnus, chargée de créer des bonnes pratiques et des outils pour les équipes d’intervention en cas d’incident, ainsi que de normaliser les politiques et les méthodologies de sécurité.

L’une des initiatives de FIRST est un groupe d’intérêt spécial (SIG), chargé d’élaborer et de maintenir la spécification du Common Vulnerability Scoring System (CVSS), afin d’aider les équipes à comprendre la gravité des vulnérabilités de sécurité et à établir leurs priorités.

Évaluer les vulnérabilités

Le CVSS est reconnu comme un système de mesure standard par les secteurs industriels, les organisations et les gouvernements qui ont besoin d’évaluer avec précision et cohérence l’impact des vulnérabilités.

Le modèle quantitatif du CVSS garantit des mesures reproductibles et précises, tout en permettant aux utilisateurs de voir les caractéristiques sous-jacentes de la vulnérabilité qui ont servi à établir les scores.

Le CVSS est couramment utilisé pour établir les priorités des activités de correction des vulnérabilités et calculer la gravité des vulnérabilités découvertes sur ses systèmes.

Les limites du CVSS

Un contexte d’applicabilité manquant

Les scores de vulnérabilité ne tiennent pas toujours compte du contexte réel dans lequel une organisation utilise un composant vulnérable. Le système Common Vulnerabilities and Exposures (CVE) peut prendre en compte différentes variables pour déterminer le score d’une organisation. Dans tous les cas, d’autres facteurs peuvent influencer la façon dont une vulnérabilité est traitée, quel que soit le score qui lui est attribué dans une CVE.

Par exemple, une vulnérabilité de gravité élevée selon le CVSS, découverte dans un composant utilisé à des fins de test, comme un banc de test, peut recevoir peu ou pas d’attention de la part des équipes de sécurité, informatiques ou de R&D. Cela peut s’expliquer par le fait que ce composant est utilisé en interne comme outil et n’est en aucun cas exposé dans une interface accessible au public.

En outre, les scores de vulnérabilité ne tiennent pas compte de conséquences concrètes, par exemple lorsqu’une vulnérabilité concerne des dispositifs médicaux, des voitures ou des réseaux de services publics. Chaque organisation doit évaluer les vulnérabilités et prendre en compte les implications spécifiques, en fonction de la prévalence des composants concernés dans ses produits.

Évaluation incorrecte

Le score d’une vulnérabilité repose sur plus d’une douzaine de caractéristiques clés. Sans indications adéquates, expérience et informations complémentaires, les erreurs sont faciles à commettre. Une récente étude universitaire[1] a révélé que les participants n’avaient correctement répondu qu’à 57 % des questions de sécurité portant sur l’évaluation des vulnérabilités CVE. L’étude précise également quels indices sont essentiels pour améliorer la précision et lesquels risquent au contraire de semer la confusion et de réduire la précision de l’évaluation.

Il n’est pas rare de trouver des faux positifs dans une CVE ou des inexactitudes dans les scores attribués à différents groupes de métriques. Cela risque d’ébranler la confiance dans une CVE ou de provoquer une panique injustifiée au sein des organisations.

Le CVSS utilise une échelle de 0 à 10, qui correspond à des niveaux de gravité allant de faible à élevé ou critique. Une évaluation inexacte des variables peut entraîner un score correspondant à un niveau CVSS incorrect. Une autre étude[2] de l’Université Carnegie Mellon est parvenue à des conclusions similaires sur la précision des scores. Le rapport indique : « Plus de la moitié des personnes interrogées ne se situent pas systématiquement dans une marge de précision de quatre points CVSS », alors qu’un écart de seulement quatre points peut faire passer une gravité élevée ou critique à un niveau inférieur.

[1] Allodi, Luca & Banescu, Sebastian & Femmer, Henning & Beckers, Kristian. (2018). Identifying Relevant Information Cues for Vulnerability Assessment Using CVSS. 119-126. 10.1145/3176258.3176340.

[2] Spring, J.M, Hatleback, E. Householder, A. Manion, A. Shick, D. « TOWARDS IMPROVING CVSS » Carnegie Mellon University, décembre 2018

La méthode Snyk

Chez Snyk, nous utilisons CVSS v3.1 pour évaluer et communiquer les caractéristiques des vulnérabilités de sécurité et leur impact.

L’équipe dédiée de recherche en sécurité de Snyk contribue à la découverte de nouvelles vulnérabilités dans différents écosystèmes. Elle travaille également à l’évaluation des scores CVE pour confirmer qu’ils reflètent correctement le niveau de gravité et compenser ainsi les inexactitudes évoquées plus haut, commises par d’autres autorités qui publient des CVE.

La base de données des vulnérabilités de Snyk fournit des métadonnées complémentaires aux informations CVE pour chaque vulnérabilité. L’équipe de recherche en sécurité enrichit chaque fiche de vulnérabilité avec des informations telles qu’une présentation du composant vulnérable et des détails sur le type de vulnérabilité, accompagnés d’exemples et de liens de référence vers des commits, des correctifs ou d’autres ressources associées.

L’image suivante présente une vulnérabilité de sécurité de cross-site scripting (XSS) découverte dans le framework frontend React, qui affecte différentes versions de la branche 16.x du module React DOM.

L’image présente également la métrique de base du score CVSS v3.1, avec une ventilation détaillée des métriques.

Fonctionnement du CVSS

Le CVSS a connu trois versions depuis sa première publication en 2004, en passant par l’adoption généralisée de CVSS v2.0, jusqu’à la spécification actuelle, CVSS v3.1. La suite de cet article porte sur CVSS v3.1.

La spécification fournit un cadre qui normalise la méthode d’évaluation des vulnérabilités en les classant selon différents domaines de préoccupation.

Les métriques d’un score CVSS sont réparties en trois groupes :

1. Base — métriques d’évaluation de l’impact et de l’exploitabilité qui ne dépendent ni du moment où la vulnérabilité est évaluée ni de l’environnement de l’utilisateur, comme la facilité avec laquelle elle peut être exploitée. Par exemple, si une vulnérabilité empêche totalement l’accès à un composant vulnérable, son impact sur la disponibilité sera élevé.

2. Temporelles — métriques qui prennent en compte les circonstances susceptibles d’influencer le score d’une vulnérabilité. Par exemple, si un exploit connu existe pour une vulnérabilité, son score augmente ; si un correctif est disponible, il diminue.

3. Environnementales — métriques qui permettent d’adapter le score à l’impact dans l’environnement spécifique d’un utilisateur ou d’une organisation. Par exemple, si la disponibilité d’un composant vulnérable est particulièrement importante pour une organisation, celle-ci peut définir un niveau d’exigence élevé en matière de disponibilité et augmenter ainsi le score CVSS global.

Le groupe des métriques de base constitue le fondement d’un vecteur CVSS. Lorsque des métriques temporelles ou environnementales sont disponibles, elles sont prises en compte dans le score CVSS global.

Groupes de métriques CVSS 3.0 par FIRST / CC-BY-SA-3.0

Scores de base

Les métriques de base CVSS comprennent des sous-groupes de métriques d’exploitabilité et d’impact. Elles évaluent leur applicabilité à un composant logiciel, susceptible d’avoir un impact sur d’autres composants (logiciels, matériels ou appareils réseau).

L’exploitabilité représente les efforts et les moyens nécessaires pour exploiter une vulnérabilité de sécurité. Elle se compose des éléments suivants :

• Vecteur d’attaque (AV) — désigne les quatre types de vecteurs par lesquels une exploitation peut avoir lieu : physique, local, adjacent et réseau. Plus le vecteur est accessible, plus le score est élevé.

Par exemple, une vulnérabilité de cross-site scripting (XSS) dans jQuery exploitable sur un site Web accessible au public serait évaluée comme une attaque par réseau.

• Complexité de l’attaque (AC) — correspond à un score faible ou élevé, selon que l’attaque nécessite ou non une circonstance ou une configuration particulière comme condition préalable à sa réussite. Par exemple, une traversée de chemin, relativement facile à réaliser et découverte dans le package Next.js en 2018 et 2017, est considérée comme une attaque de faible complexité. Une attaque par mesure du temps découverte dans Apache Tomcat présente, elle, une complexité élevée.

• Privilèges requis (PR) — correspond à l’un des niveaux suivants : aucun, faible ou élevé. Ces niveaux reflètent les privilèges qu’un attaquant doit obtenir pour exploiter la vulnérabilité. Par exemple, une injection de code arbitraire dans Wordpress MU permettait aux utilisateurs authentifiés de téléverser et d’exécuter des fichiers malveillants à distance. Le niveau est faible, car tout utilisateur authentifié pouvait lancer l’attaque, quels que soient son rôle et ses autorisations dans une application Wordpress.

• Interaction de l’utilisateur (UI) — correspond à un score élevé lorsqu’aucune action de l’utilisateur n’est nécessaire pour qu’une attaque réussisse, et à un score plus faible lorsqu’une forme d’interaction est requise. Par exemple, l’installation de modules malveillants qui compromettraient l’environnement nécessite une interaction de l’utilisateur. Dans l’écosystème npm, nous avons observé des dizaines de packages malveillants, dont l’un cherchait à dérober des variables d’environnement au moyen d’une attaque par typosquattage dans un package appelé crossenv. Ces attaques obtiennent un score faible, car une interaction de l’utilisateur est nécessaire.

Le sous-groupe des métriques d’impact représente les effets d’une exploitation réussie d’un composant vulnérable sur sa confidentialité, son intégrité et sa disponibilité. Il se compose des éléments suivants :

• Confidentialité (C) — mesure le degré de perte de confidentialité du composant concerné, par exemple la divulgation d’informations à des utilisateurs non autorisés. Une perte importante de confidentialité se produit, par exemple, lorsqu’une vulnérabilité d’injection de script arbitraire est exploitée dans des applications Angular (plus précisément AngularJS). Une entrée utilisateur provenant d’un événement DOM et insuffisamment assainie peut entraîner l’exécution de code.

• Intégrité (I) — mesure le degré de perte d’intégrité du composant concerné, par exemple la possibilité de modifier des données après l’exploitation réussie du composant vulnérable. Une perte importante d’intégrité s’est produite dans le framework open source Apache Struts 2, où une sérialisation incorrecte a permis l’exécution de commandes arbitraires. Cette vulnérabilité a fait la une de l’actualité en 2017, en raison de son rôle dans la fuite de données d’Equifax. Vous pouvez en savoir plus sur notre blog.

• Disponibilité (A) — mesure la perte de disponibilité des ressources et des fonctionnalités du composant concerné, par exemple lorsqu’une attaque visant le composant vulnérable peut entraîner un déni de service pour les utilisateurs. Par exemple, une version de lodash est vulnérable à un déni de service par expression régulière, ce qui peut fortement perturber la disponibilité. Lorsque lodash est utilisé comme bibliothèque frontend, l’exploitation de cette vulnérabilité affecte les navigateurs des utilisateurs finaux. Le problème s’aggrave toutefois lorsque lodash est utilisé dans une application serveur Node.js : la boucle d’événements devient alors inactive, ce qui affecte toutes les requêtes entrantes d’un service API.

Il est important de noter que lorsque la portée a changé, les métriques d’impact représentent les conséquences les plus importantes, qu’elles concernent le composant vulnérable lui-même ou le composant affecté.

Enfin, la portée est une nouvelle métrique introduite par CVSS v3.0. Elle indique si une vulnérabilité de sécurité affecte d’autres ressources qu’elle-même. Les valeurs attribuées à cette métrique peuvent être inchangée ou modifiée. Si l’exploitation réussie d’un composant vulnérable affecte des ressources régies par un autre périmètre d’autorisation, la portée est considérée comme modifiée.

Par exemple, les vulnérabilités de type cross-site scripting (XSS) dans phpMyAdmin constituent un changement de périmètre, car le composant vulnérable est phpMyAdmin, une application PHP exécutée côté serveur ; le périmètre de l’impact est toutefois le navigateur de l’utilisateur.

Les vulnérabilités de sécurité telles que l’exécution de commandes à distance, où le composant vulnérable dispose de privilèges très élevés, illustrent bien comment le périmètre peut dépasser l’autorisation propre à ce composant et potentiellement affecter d’autres composants.

Scores temporels

Le score temporel permet de contextualiser la gravité d’une CVE en fonction du moment considéré. Par exemple, si des exploits publics sont connus pour une vulnérabilité de sécurité, sa criticité et la gravité de la CVE augmentent, car les ressources permettant de mener de telles attaques sont alors beaucoup plus facilement accessibles.

Le score CVSS global est calculé en tenant compte du score temporel, à partir de la valeur de risque la plus élevée, et celui-ci n’est inclus que s’il existe un risque temporel. Ainsi, les valeurs temporelles attribuées à la vulnérabilité maintiennent le score CVSS global au même niveau ou peuvent le réduire, mais ne peuvent pas l’augmenter.

Les métriques du score temporel sont les suivantes :

• Maturité du code d’exploitation (E) — mesure la probabilité que la vulnérabilité soit exploitée, en fonction de la maturité du code d’exploitation public disponible. Les valeurs possibles sont « U » en l’absence de code d’exploitation, « P » pour un code de preuve de concept connu, « F » lorsqu’un code d’exploitation fonctionnel est disponible, ou « H » lorsque la probabilité d’exploitation est élevée, grâce à des outils d’attaque automatisés tels que le célèbre framework Metasploit, ou lorsqu’aucun code d’exploitation spécifique n’est nécessaire pour réussir l’attaque.

• Niveau de correction (RL) — mesure la facilité avec laquelle il est possible d’atténuer cette vulnérabilité ou d’y remédier complètement. Par exemple, si une vulnérabilité a été correctement divulguée et prise en charge par un fournisseur, le composant vulnérable disposera d’une voie de mise à niveau lorsque la CVE sera rendue publique. Les valeurs possibles sont « O » lorsqu’un correctif officiel du fournisseur est disponible sous forme de correctif ou de mise à niveau, « T » lorsqu’une correction temporaire est disponible, par exemple une version contenant un correctif à chaud ou une solution de contournement pour atténuer la vulnérabilité, « W » lorsqu’une solution de contournement est connue, mais qu’elle n’est pas officielle et n’est pas prise en charge par le fournisseur, et enfin « U » lorsqu’aucune mesure d’atténuation ou correction connue du public n’est disponible.

• Fiabilité du rapport (RC) — mesure le degré de confiance accordé au rapport de vulnérabilité. Les rapports de sécurité divulgués ne fournissent parfois pas suffisamment d’informations générales ni de pièces justificatives, telles qu’une preuve de concept ou des étapes de reproduction, ce qui complique l’évaluation de leur crédibilité et de leur impact. Les valeurs possibles sont « C » pour indiquer un degré élevé de certitude quant à la reproduction du rapport, « R » lorsque des éléments raisonnables ont été fournis pour le confirmer, et « U » lorsque les détails de la cause profonde de la vulnérabilité sont inconnus.

La valeur « X » peut être attribuée aux trois métriques temporelles pour indiquer qu’aucune valeur ne doit leur être attribuée et qu’elles ne doivent pas influer sur le score de base.