Les vulnérabilités connues de votre site

1 Introduction

Beaucoup de serveurs web annoncent ce qu'ils font tourner. Un en-tête de réponse comme Server: nginx/1.9.0 ou X-Powered-By: PHP/7.2.24 donne à chaque visiteur le produit et sa version exacte. Les attaquants le lisent aussi, et ils disposent de bases qui indiquent quelles versions sont touchées par quelle faille publique.

Le bloc « Known vulnerabilities » d'un scan de domaine fait cette recherche à votre place : il prend chaque produit et chaque version que votre site laisse voir et liste les vulnérabilités publiées (CVE) que cette version ne permet pas d'écarter. Cette page explique comment lire cette liste, quelles entrées demandent une action aujourd'hui, et pourquoi certaines ne vous concernent peut-être pas du tout.

KEV

Le catalogue de la CISA des vulnérabilités dont l'exploitation réelle est avérée, publié depuis 2021

0 à 10

L'échelle de gravité CVSS. À partir de 9.0, la faille est dite critique

30 jours

La période couverte par un score EPSS : la probabilité estimée de tentatives d'exploitation dans les 30 prochains jours

2 Comment ça marche

Le scan n'attaque jamais votre site et ne tente aucune exploitation. Il compare simplement un numéro de version à des avis publics, en trois étapes.

Détecter

Lire le produit et la version dans la réponse HTTP. Un en-tête vaut plus qu'une déduction tirée du code de la page, et le rapport indique la source utilisée.

Rechercher

Récupérer les CVE enregistrées pour ce produit, puis écarter celles qui visent un autre produit et celles dont la plage de versions exclut la vôtre.

Enrichir

Ajouter le score CVSS, la probabilité EPSS et la présence ou non dans le catalogue KEV de la CISA, pour trier selon le risque réel.

Pas de version affichée, pas de recherche

Si le bloc indique « No software version was disclosed in the response », le scan n'avait rien à comparer : un avis dit « les versions 1.4 à 1.9 sont touchées », et un simple Server: nginx ne peut pas être placé dans cette plage. Ce n'est pas un certificat de bonne santé. La question ne pouvait simplement pas être posée de l'extérieur, et la réponse se trouve dans votre propre suivi des mises à jour. Même chose pour « Lookup: incomplete » : la base de vulnérabilités n'a pas répondu pour tous les produits, la liste est donc inachevée.

3 Analyse détaillée

Comment une version est rapprochée des CVE

Une CVE (Common Vulnerabilities and Exposures) est l'identifiant public d'une faille, par exemple CVE-2016-0746. Son avis précise le produit concerné et, le plus souvent, une plage de versions. Sous chaque produit, le rapport affiche une ligne de ce type :

nginx 1.9.0  (from header; 23 not attributed to this product, 17 ruled out by version)

Ce qui a été écarté

« Not attributed to this product » : des CVE qui citent le nom mais concernent autre chose (un plugin, un paquet de distribution, un autre éditeur). « Ruled out by version » : de vraies CVE du produit, mais hors de votre version. Les deux chiffres sont affichés pour qu'une liste courte se lise comme filtrée, et non comme « il n'existe rien ».

in range ou undetermined

in range : l'avis donne une plage et votre version est dedans. undetermined : l'avis ne contient aucune plage exploitable par le scanner, la CVE n'a donc pas pu être écartée non plus. Commencez par les entrées « in range ».

Des candidates, pas des failles confirmées

Beaucoup de CVE ne s'appliquent que si un module ou une fonction précise est activé (une option HTTP/2, un résolveur, un module MP4). La liste dit que cette version peut être touchée. Lisez chaque résumé et vérifiez si la partie concernée est utilisée sur votre serveur. Chaque identifiant renvoie à sa fiche complète sur vuln.mlab.sh.

CVSS, EPSS et KEV : trois questions différentes

CVSS : à quel point ce serait grave ?

Une note de 0 à 10 qui décrit la faille elle-même : accessible par le réseau ou non, besoin d'un compte ou non, impact sur les données et la disponibilité. Elle ne dit rien de son exploitation réelle. La pastille « Highest CVSS » donne la note la plus haute de la liste.

EPSS : quelle chance qu'elle soit utilisée ?

L'Exploit Prediction Scoring System, tenu par le FIRST, estime la probabilité d'une activité d'exploitation dans les 30 prochains jours, affichée en pourcentage. La plupart des CVE ont un score très bas. Un EPSS élevé sur une CVE « in range » est un signal fort, même si le CVSS n'est que moyen.

KEV : est-elle déjà utilisée ?

Le catalogue Known Exploited Vulnerabilities, tenu par l'agence américaine CISA, recense les CVE pour lesquelles des attaques réelles sont documentées. Ce n'est pas une prévision : quelqu'un l'exploite en ce moment. Une étiquette KEV, ou la pastille rouge « Known exploited » en haut du bloc, passe avant toute note.

Les entrées KEV d'abord

Les agences fédérales américaines doivent corriger les entrées KEV dans un délai imposé, et cette règle est un bon modèle pour tout le monde. Des outils d'exploitation existent déjà pour ces CVE, et des scans à l'échelle d'Internet les cherchent en permanence. Un serveur exposé avec une version touchée a toutes les chances d'être repéré.

Corriger, puis chercher une compromission

Si une entrée KEV est « in range » et que la fonction vulnérable est utilisée, mettez à jour en premier. Examinez ensuite les journaux et les comptes du serveur à la recherche d'une intrusion passée : la mise à jour ferme la porte, elle ne fait pas sortir quelqu'un qui serait déjà entré.

Impossible de mettre à jour aujourd'hui ?

Désactivez le module concerné, restreignez l'accès au service (VPN, liste d'IP autorisées) ou appliquez le contournement documenté par l'éditeur en attendant la mise à jour.

Comment prioriser la liste

KEV et « in range » : à traiter aujourd'hui.

EPSS élevé, ou CVSS de 9.0 et plus accessible sans authentification : planifiez la mise à jour dans la semaine.

Le reste « in range » : à intégrer à la prochaine mise à jour régulière. Passer à une version maintenue règle souvent des dizaines d'entrées d'un coup.

Undetermined : lisez le résumé, vérifiez si la fonction concernée est utilisée chez vous, et passez à la suite sinon.

Une version assez ancienne pour cumuler beaucoup de CVE n'est souvent plus du tout maintenue par l'éditeur. Dans ce cas, la vraie correction est la montée de version, pas l'examen CVE par CVE.

Faux positifs : les correctifs rétroportés

Les distributions Linux comme Debian, Ubuntu ou Red Hat Enterprise Linux gardent le même numéro de version amont pendant toute la vie d'une version et appliquent les correctifs de sécurité par-dessus (on parle de « backport »). Un serveur peut afficher Apache/2.4.6 et être parfaitement à jour, parce que le paquet de la distribution contient les correctifs. Le scan ne voit que le numéro, il liste donc des CVE peut-être déjà corrigées. Vérifiez le paquet installé :

# Debian / Ubuntu : la CVE figure-t-elle dans le changelog du paquet ?
apt changelog nginx | grep CVE-2016-0746

# Red Hat / Rocky / Alma
rpm -q --changelog httpd | grep CVE-

Le suivi de sécurité (security tracker) de votre distribution indique aussi, CVE par CVE, quelle version du paquet l'a corrigée. Si c'est corrigé, notez-le et passez à la suite.

Arrêter d'annoncer sa version

Une fois à jour, rien ne justifie de publier votre version exacte :

# nginx
server_tokens off;

# Apache
ServerTokens Prod
ServerSignature Off

# PHP (php.ini) : supprime X-Powered-By
expose_php = Off

Vous retirez ainsi un indice de ciblage facile, et c'est une bonne pratique (voir en-têtes de sécurité HTTP). Mais cela ne corrige rien : un serveur vulnérable dont la version est masquée reste vulnérable, et le prochain scan n'a simplement plus rien à rechercher. D'abord mettre à jour, ensuite masquer.

Vérifiez votre domaine sur mlab.sh

Un scan de domaine relève les versions logicielles que votre site laisse voir, les compare aux avis publics et associe à chaque CVE son score CVSS, son EPSS et son statut KEV.

Scanner votre domaine sur mlab.sh

4 Red Flags

Une entrée KEV marquée « in range »

Cette faille est exploitée en ce moment et votre version est touchée. Vérifiez que la fonction est utilisée, puis corrigez ou atténuez aujourd'hui.

Une version en retard de plusieurs années

Des dizaines de CVE « in range » signifient souvent que le produit n'est plus mis à jour du tout. Prévoyez une montée vers une branche maintenue.

« Lookup: incomplete » pris pour un résultat propre

La base de vulnérabilités n'a pas répondu pour tous les produits. Relancez un scan plus tard avant de conclure quoi que ce soit.

Masquer la version au lieu de mettre à jour

Le scan se tait, la faille reste. Les attaquants tentent souvent l'exploitation sans même regarder la version.

Tout classer « rétroporté » sans vérifier

Les backports expliquent beaucoup de faux positifs, pas tous. Vérifiez le changelog ou le suivi de la distribution pour chaque entrée « in range » qui compte.

Propulsé par mlab.sh

Modules connexes

Comprendre la configuration TLS

Versions de protocole, suites de chiffrement et validité du certificat : lire un résultat de scan TLS et corriger une configuration faible.

Votre surface d'attaque : les sous-domaines

Ce que l'énumération de sous-domaines révèle à un attaquant, et comment réduire la surface : hôtes oubliés, préprod, interfaces d'admin.

Les en-têtes de sécurité HTTP

HSTS, CSP, X-Frame-Options, attributs de cookies : ce que bloque chaque en-tête, ce que signifie son absence dans un scan, et une configuration de départ sûre.