Comment exploiter la base CVE du Nist ?

Lorsque l’on travaille dans la détection de vulnérabilités, l’exploitation de la base CVE du Nist est incontournable. Vous pouvez retrouver cette base de données sur https://nvd.nist.gov/ et les parties exploitables sur https://nvd.nist.gov/vuln/data-feeds.

Dans cet article, nous allons voir comment exploiter ces données et les pièges à éviter.

Entrons dans le vif du sujet. Première chose à savoir, la base CVE est passée en version 1.1 (septembre 2019) avec l’arrêt de l’ancienne version (septembre 2020). Qu’est-ce que cela change ? Des champs ont été supprimés comme la partie « affects » qui permettait « d’échapper » à l’utilisation de la partie « CPE ».

Qu’est-ce que le format « CPE » (Common Plateforme Enumeration) ?

Le format « CPE » a été inventé pour décrire de manière standard et lisible le codage des noms de produits et plates-formes informatiques. Voici une explication succincte du format (plus d’informations sur ce site : https://cpe.mitre.org/specification/).

Voici un exemple de CPE :

cpe:2.3:a:microsoft:internet_explorer:8.0.6001:beta:*:*:*:*:*:*

En découpant cette chaîne par « : », on obtient :

• « cpe » : c’est juste pour indiquer le format
• « 2.3 » : c’est la version du format CPE
• « a » : cela nous indique que c’est de l’applicatif (on a aussi o : operating system et h:hardware)
• « microsoft » : c’est le « vendor » (la marque)
• « internet_explorer » : c’est le « product » (le nom du produit)
• « 8.0.6001 » : c’est le numéro de version

Les autres champs ne vont pas nous intéresser dans cet article.

Voyons comment est structurée l’information CPE dans la base CVE du Nist (au format JSON) :

On voit qu’on a la notion d’« operator » : « AND » et « OR » (ce sont les opérateurs logiques ET / OU). Nous avons également la notion de « children » (traduction : enfant) pour définir des sous-groupes.

Dans la section « cpe_match », on trouve la notion de « vulnerable » qui est un booléen et qui va indiquer si la vulnérabilité décrite touche le CPE qui va être décrit. Je m’explique, dans l’exemple (CVE-2009–1072), la vulnérabilité ne touche pas le système d’exploitation windows directement, c’est le virtualcenter (tournant sous Windows) qui est incriminé.

Et pour finir, on trouve le « cpe23Uri » qui est le cpe au format 2.3

En résumé, voici ce que l’exemple dit :

« Si vous avez un produit vcenter server (version 4.0) ou un produit virtualcenter (version 2.0.2 ou 2.5) de la marque vmware tournant sous Windows, alors vous êtes concernés par cette vulnérabilité ». C’est la notion de « Running on/with » que vous trouverez dans les fiches CVE du site.

Voici une vulnérabilité qui laisse à penser que c’est un faux positif : CVE-2007–2768

C’est un cas particulier. Cette vulnérabilité est valable pour toutes les versions d’openssh mais seulement dans le cas d’une utilisation de OTP (one-time passwords).

Voici un nouvel exemple (CVE-2018–16843) qui amène un bon sujet de réflexion :

Dans la section « cpe_match », on a la possibilité d’avoir :

• versionStartIncluding
• versionStartExcluding
• versionEndIncluding
• versionEndExcluding

Dans notre exemple, cela signifie que les versions de nginx qui sont concernées par la vulnérabilité sont : de 1.9.5 à 1.14.1 (en excluant 1.9.5 et 1.14.1) et de 1.15.0 à 1.15.6 (en excluant 1.15.0 et 1.15.6). Vous commencez à entrevoir la problématique ? Comment je sais les versions qui existent dans les intervalles ? On peut également avoir le cas où l’on nous définit la borne « versionEnd » seulement, ce qui signifie : « toutes les versions jusqu’à »

Heureusement, le Nist met à disposition le dictionnaire des CPE : https://nvd.nist.gov/products/cpe

Le dictionnaire CPE va nous permettre de trouver toutes les versions incluses dans un intervalle donné. Mais attention, tous les intervalles présents dans la base CVE du Nist ne sont pas présents dans le dictionnaire CPE. Il a fallu par moment « piocher » dans un intervalle du dictionnaire CPE pour déduire l’intervalle décrit dans une CVE.

Prenons un exemple fictif. Dans le dictionnaire CPE, on nous donne toutes les versions jusqu’à une borne de fin pour un produit donné. C’est la seule info disponible pour ce produit. Dans la vulnérabilité CVE qui nous intéresse, on parle de ce produit avec une borne de début et une borne de fin (cet intervalle étant inclus dans la définition du dictionnaire CPE). Il va falloir trouver un moyen pour résoudre cet intervalle à partir du dictionnaire CPE.

Sur le site du Nist, vous avez le moyen de visualiser les versions présentes dans le dictionnaire CPE en cliquant sur les liens « Show Matching CPE(s) » et les refermer avec « Hide Matching CPE(s) ». Ici c’est la CVE-2017–11294 :

A noter que l’opérateur « OR » permet de créer plusieurs configurations pour une CVE. Exemple pour la CVE-2008–1531 :

Vous noterez au passage que pour lighttpd, on inclut la version 1.5 mais on exclut la version 1.5.0 et qu’en réalité, on ne trouve pas d’intervalle.

Il existe des cas où l’on n’arrive pas à résoudre l’intervalle. Par exemple : CVE-2007–5615

On peut retrouver l’opérateur « AND » sans la notion de « Running on/with » et du coup, il faut qu’une condition soit remplie dans les blocs sous jacent. Exemple pour la CVE-2013–0454 :

Allez, quand on croit maitriser le sujet, on tombe sur des cas un peu tordus comme celui-ci. Voici la CVE-2014–1730 (la liste étant longue, la capture d’écran ne comporte pas toutes les lignes cpe. Il vaut mieux vous rendre sur : https://nvd.nist.gov/vuln/detail/CVE-2014-1730)

Cette CVE est assez complexe. Toutes les versions de « chrome » sont inclus (dernière ligne du bloc « OR ») sauf toutes les versions qui sont définies juste au dessus. Argh !

On observe donc la notion « SAUF » qu’on retrouve sur d’autres CVE comme https://nvd.nist.gov/vuln/detail/CVE-2013-1378.

Il existe encore d’autres surprises à découvrir, elles ne figurent pas toutes dans cet article.

Cet article a pour but de vous montrer que l’exploitation de la base CVE du Nist n’est pas un long fleuve tranquille. Au sein de ProHacktive, nous avons effectué un travail de R&D l’an passé pour améliorer la détection de vulns dans notre outil Sherlock tout en limitant les faux positifs.