Comment la dangerosité des failles informatiques est-elle mesurée ?
« Alerte !
Il faut dire que la cybersécurité est truffée de termes et autres acronymes spécifiques (et anglophones, qui plus est), pour qualifier les scénarios d'attaque. On parle de RCE, de XSS, de « web shell » ou encore d'élévation des privilèges. Le plus souvent, les bulletins d'alertes s'adressent aux spécialistes et se contentent d'utiliser le jargon. Ils n'insistent que rarement sur les risques concrets que représente une nouvelle vulnérabilité pour le grand public.
Comme si ce n'était pas suffisamment compliqué, une majorité de failles touche des logiciels inconnus du grand public bien qu'ils soient très utilisés par les entreprises. À titre d'exemple, le top 10 des vulnérabilités les plus marquantes de 2020 de l'Anssi (l'agence française en charge de la réponse aux incidents informatiques) cite des failles sur les outils Pulse Connect Secure, FortiOS, Saltstacks ou encore Citrix Gateaway.
Pour y voir plus clair dans ces alertes de sécurité, il existe un moyen standardisé pour évaluer les failles : le CVSS (pour Common Vulnerability Scoring System). Loin d'être parfait, ce système de notation sur 10 offre tout de même un repère intéressant, et peut être compris par tout le monde.
À 0, le risque que représente la faille sera nul (logique)
De 0,1 à 3,9 : risque faible.
De 4,0 à 6,9 : risque modéré.
De 7,0 à 8,9 : risque élevé.
De 9,0 à 10 : risque critique.
Le score vous donnera un ordre d'idée, mais il faut rentrer dans le détail de son calcul pour mieux comprendre en quoi une faille est dangereuse. Par exemple, une faille peut ne représenter qu'un risque faible parce qu'elle est très compliquée à exploiter, ou parce que son exploitation ne causera que peu de dégâts. Deux situations très différentes, qui peuvent obtenir le même score. Regardons de plus près le score CVSS pour distinguer ces détails.
Le CVSS expliqué grâce à la Numerafaille
Le CVSS a fait ses preuves : il est adopté tant du côté des éditeurs de logiciels que du côté de l'industrie de la cybersécurité depuis 2005. Le score va déterminer la « criticité » -- encore un mot du jargon, utilisé pour désigner le « degré d'importance » -- de la faille. Il va permettre aux éditeurs du logiciel concerné, mais aussi à ses clients, de réagir en conséquence.
Comme l'explique le Cert-IST le calcul d'un score CVSS passe par trois blocs de critères, qui répondent à trois questions clés, afin d'affiner la précision du résultat :
Quel impact aura la vulnérabilité ?
Quel danger représente-t-elle à l'instant T ?
Comment s'applique-t-elle à un cas de figure particulier ?
Pour mieux vous expliquer, nous allons nous-mêmes calculer le score d'une vulnérabilité imaginaire. Baptisée « Numerafaille », elle se situerait sur l'application mobile de Numerama, et permet d'accéder à des données d'utilisateurs de l'app (désolé chers lecteurs imaginaires).
Pour y parvenir, nous allons utiliser le calculateur du First (forum of incident response and security teams), l'organisation à l'origine du CVSS. Comme vous pouvez le voir dans la capture d'écran, le calcul du CVSS consiste à répondre à un QCM de 22 questions. Détailler ce calcul permet de voir toute la complexité d'une vulnérabilité.
Quel impact aura la vulnérabilité ? (8 critères)
Quel est le vecteur d'attaque ? (AV)
Plus un attaquant peut exploiter la vulnérabilité de loin, plus elle sera dangereuse. À l'inverse, si l'assaillant doit obtenir un accès physique à un ordinateur de l'entreprise, lui-même situé derrière deux portiques de sécurité, la vulnérabilité sera bien plus difficile à exploiter. Et pour cause : l'attaquant devra aussi trouver une solution pour s'infiltrer dans les bâtiments de l'entreprise.
La Numerafaille peut être lancée à distance, depuis Internet, elle score donc le maximum de point dans cette catégorie.
Quelle est la complexité de l'attaque ? (AC)
Ce critère mesure la complexité des moyens à déployer pour lancer l'attaque : faut-il un gadget, un logiciel particulier ? Le calculateur ne nous laisse choisir qu'entre deux options : basse et haute.
La Numerafaille peut être lancée depuis n'importe quel ordinateur avec un accès à Internet. Nous lui attribuons l'évaluation « basse » puisqu'elle sera facile à lancer.
Quel est le degré d'interaction avec les utilisateurs ? (UI)
Un utilisateur aura-t-il besoin de cliquer quelque part ou de lancer un programme pour que l’attaquant puisse exploiter la vulnérabilité ? En effet, plus l'attaquant pourra agir seul, plus la vulnérabilité sera dangereuse. On parle de faille « zero clic » quand un malfrat peut s'en prendre à une victime sans la pousser au préalable à l'erreur.
Pour exploiter la Numerafaille, il faut que l'utilisateur lance l'app, puis ouvre un article. Nous cochons donc qu'une interaction est « requise ».
Faut-il un certain niveau de privilège pour lancer l'attaque ? (PR)
Chaque système informatique propose différents niveaux d'accès pour les utilisateurs. Par exemple, sur votre ordinateur personnel, vous pouvez créer un compte administrateur, qui pourra changer certains paramètres profonds de la machine, et un compte « invité » qui ne pourra pas par exemple installer ou désinstaller des logiciels. À l'échelle d'un réseau, le fonctionnement est similaire.
Pour faire les manipulations nécessaires à l’exploitation de certaines failles, il faut obtenir un accès administrateur. Cela signifie que l'attaquant devra au préalable obtenir des identifiants d'un responsable du réseau avec un phishing, ou hacker un compte avec les bonnes autorisations.
La Numerafaille peut être exploitée depuis un simple compte utilisateur, nous lui attribuons le score « bas ».
Quelle est la portée de l'attaque ? (S)
Ce critère répond à une question : la faille de sécurité affecte-t-elle la sécurité d'autres produits ? Autrement dit, est-ce qu'un attaquant peut rebondir sur la vulnérabilité pour attaquer d'autres logiciels ? Va-t-elle produire des dégâts collatéraux ?
Pour la Numerafaille, nous considèrerons qu'elle n'affecte que l'app Numerama, et nous cochons « inchangé ».
La vulnérabilité affecte-t-elle la confidentialité de l'information ? (C)
Ici, il s'agit de mesurer la perte de confidentialité de l'information. Autrement dit, de mesurer à quel volume d'informations les attaquants ont obtenu un accès.
Dans le cas de la Numerafaille, les attaquants ont pu accéder à toutes les adresses email et tous les noms des utilisateurs de l'app Numerama. Nous cochons « haute ».
La vulnérabilité affecte-t-elle l'intégrité du logiciel ? (I)
La vulnérabilité permet-elle de modifier le logiciel concerné ? Permet-elle de manipuler certaines fonctionnalités ?
La Numerafaille ne permet pas de modifier l’app Numerama, nous mettons donc « nul » dans le tableau.
La vulnérabilité affecte-t-elle la disponibilité du logiciel ? (A)
Ce critère permet de mesurer à quel point le hacker peut prendre la main sur le système. Si la vulnérabilité lui permet de prendre le contrôle et de bloquer l'accès aux autres utilisateurs, le score sera maximal.
Dans le cas de la Numerafaille, le hacker ne pourra pas prendre le contrôle de l'app, nous attribuons donc un score nul.
Grâce aux évaluations que nous avons renseignées, nous obtenons un score de « base » de 5,7. La Numerafaille représente donc un risque modéré. Plutôt facile à exploiter, elle permet d'accéder à des informations confidentielles, mais ne fait pas d'autres dégâts.
Le calculateur nous donne également la « chaîne » de notre score, qui détaille nos réponses à chacun des critères : « AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N ». En reprenant le tableau, il est plutôt facile de déchiffrer cette chaîne.
Quel danger la faille représente-t-elle à l'instant T ?
Une fois la base du calcul posée, le calculateur propose une deuxième série de critères, qui va permettre de pondérer le score que nous venons d'obtenir avec un « score temporel ». Il nous faut répondre à trois questions :
Où en est le développement d'un code pour exploiter la vulnérabilité ?
Où en est le développement d'un patch pour réparer la vulnérabilité ? Existe-t-il des contre-mesures ?
À quel point les chercheurs sont-ils sûrs que la vulnérabilité existe telle que décrite ?
Pour la Numerafaille, on considère qu'il existe déjà un outil pour l'exploiter efficacement, mais que les équipes techniques du site ont déjà déployé un moyen pour contourner le problème, en attendant un vrai patch. L'existence de la faille telle que décrite par ceux qui l’ont découverte a été confirmée.
Ces trois critères abaissent le score de criticité de 5,7 à 5,6, mais ils devront être changés lorsqu'un patch pour la Numerafaille sera publié. Le score baissera alors de 0,1 supplémentaire.
Comment s'applique la faille à un cas de figure particulier ?
Une troisième série de critères permet de faire émerger un « score environnemental ». Il pondère la dangerosité de la faille en fonction des particularités de l'organisation concernée. L'évaluateur est invité à annoter chacun des critères du score de base pour qu'ils correspondent plus correctement au fonctionnement réel, et non théorique du logiciel concerné.
Le score CVSS a (forcément) des limites
S'il est bien pratique pour l'industrie de s'appuyer sur un système d'évaluation comme le score CVSS, il n'est pas sans défaut :
Les critères manquent de parfois de précision : vous l'aurez peut-être remarqué, à chaque question, nous avions le choix entre 2 et 4 réponses. Ces cases prédéfinies facilitent le calcul, mais elles réduisent sa précision. À cause de ces arrondis, une différence inférieure à deux points entre deux scores n'est pas forcément significative. C'est pourquoi il faut avant tout avoir en tête les fourchettes de risques lorsqu’on évalue la dangerosité d’une vulnérabilité à partir d’un score CVSS.
Un score soumis à interprétation : deux évaluateurs d'une vulnérabilité ne trouveront pas forcément le même score CVSS, puisque les critères laissent une marge d’interprétation. Le désaccord sur un score est d’ailleurs situation commune dans le milieu du bug bounty. Des chercheurs présentent des vulnérabilités aux entreprises, qui vont discuter avec eux de la sévérité de la faille. Plus le score CVSS sera élevé, plus la prime sera élevée pour le chercheur, et plus elle coûtera cher à l'entreprise. Pour éviter les négociations autour du score CVSS, plusieurs programmes de bug bounty utilisent d'autres critères.
Vous l'aurez compris, le score CVSS est un excellent repère, mais il ne reste qu'un indicateur. Il n'est pas possible de réagir à une vulnérabilité qu'à partir de son score, il faut prendre en compte ses particularités.