Faille zero-day : le vrai délai avant exploitation de vos
équipements exposés

Le nom dit tout : zero-day, zéro jour. Zéro jour laissé à l'éditeur pour corriger, parce que la faille est déjà exploitée quand elle sort au grand jour. Ce n'est pas une vulnérabilité obscure de plus dans une liste. C'est une porte grande ouverte sur un équipement que vous exposez peut-être en ce moment, sans correctif à déployer et sans savoir que vous êtes concerné.

La question qui compte n'est donc pas si une CVE critique va toucher votre VPN SSL, votre serveur de messagerie ou votre passerelle applicative. C'est de savoir, le jour où elle tombe, combien de temps vous avez avant qu'un attaquant ne la retourne contre vous, et si vous êtes seulement capable de dire ce que vous exposez. Pour répondre au premier point, on ne va pas citer une étude au doigt mouillé : on va parcourir le catalogue public des failles activement exploitées et mesurer.

Une faille zero-day, c'est zéro jour pour se préparer

Posons le vocabulaire, parce qu'on mélange souvent trois choses. Une faille zero-day est une vulnérabilité exploitée avant qu'un correctif n'existe. Le terme désigne aussi bien la faille que l'exploit qui en tire parti, le fameux 0day du jargon. À l'instant où l'éditeur publie un patch, la même faille devient techniquement une n-day : le correctif existe, mais tant que vous ne l'avez pas appliqué, elle reste exploitable chez vous. Un attaquant ne fait pas la différence. Pour lui, une n-day non déployée vaut une zero-day, avec en prime le mode d'emploi que la publication du patch lui a offert.

C'est le paradoxe des équipements de bord. Le jour de la divulgation, la pression maximale n'est pas sur ceux qui n'ont pas encore de correctif, elle est sur ceux qui l'ont mais qui mettront des semaines à le déployer sur un concentrateur VPN en production. La faille zero-day fait la une ; l'exploitation de masse, elle, se joue dans la fenêtre n-day : les jours et semaines qui suivent le patch, quand le code de l'exploit se diffuse et que les parcs n'ont pas bougé. C'est exactement le terrain de la gestion des vulnérabilités, et le point aveugle du patch management sur les actifs exposés.

Le vrai délai entre divulgation et exploitation

Pour chiffrer ce délai sans inventer, on prend le catalogue CISA KEV (le CSV public), on isole les vulnérabilités des quatre familles d'équipements de bord qui concentrent l'attention des attaquants, Fortinet, Ivanti, Citrix NetScaler et Microsoft Exchange, inscrites entre 2024 et 2026, puis on récupère pour chacune sa date de publication dans la base NVD. L'écart entre les deux dates, c'est le temps qui sépare la divulgation de la confirmation publique d'exploitation.

Le calcul porte sur 54 CVE. Le résultat est brutal : l'écart médian est de 6 jours. Seize de ces 54 failles ont été confirmées comme activement exploitées le jour de leur publication, voire avant, ce qui est la définition même du zero-day. Trente sur 54 l'ont été en moins d'une semaine. Par famille, la médiane tient à quelques jours : 3 jours pour Ivanti, 4,5 jours pour Fortinet, 7 jours pour Citrix. Autrement dit, sur ces équipements, la fenêtre entre le moment où le monde apprend l'existence de la faille et le moment où elle est confirmée sous exploitation ne se compte pas en mois. Elle se compte en jours, parfois en heures.

  exploitation      DIVULGATION       course au patch      patch
  silencieuse       CVE + avis        parc = cible         disponible
  (jour -N)         (jour 0)          (jour 0..+P)         (jour +P)
      |                 |                   |                  |
      +--- zero-day ----+------- n-day non deploye -----------+---->
                        |
                        +---> confirmation exploitation (KEV)
                              mediane : +6 jours  (Ivanti +3 / Fortinet +4,5 / Citrix +7)

Une réserve d'honnêteté sur la méthode : la date d'inscription au KEV n'est pas la date de première exploitation, c'est celle où la CISA la confirme publiquement. Le chiffre de 6 jours est donc un plafond prudent, pas un plancher. Et les rares très gros écarts (d'anciennes failles re-cataloguées des années après leur publication) tirent la moyenne vers le haut ; c'est précisément pour ça qu'on raisonne sur la médiane, qui reste à 6 jours et décrit bien le cas courant. Le cas Exchange, avec seulement quatre entrées récentes portant sur de vieilles CVE, est trop maigre pour une médiane par famille : on le traite à part, sur son incident fondateur.

Quatre zero-days d'équipements exposés, datés

Les statistiques parlent mieux avec des noms. Voici quatre CVE réelles, une par famille, avec leur date de publication NVD et leur date d'inscription au catalogue KEV. Toutes portent l'indicateur d'usage par des campagnes de rançongiciel, et toutes visent une interface exposée en frontal, avant authentification.

La faille FortiOS et celle d'Ivanti Connect Secure racontent la même histoire, à un an d'écart : divulgation et confirmation d'exploitation le même jour. Le zero-day dans sa forme pure. Une écriture hors limites sur le service SSL-VPN de FortiOS, un débordement de pile sur le concentrateur Ivanti, dans les deux cas une exécution de code à distance sans le moindre identifiant, avec un score CVSS proche du maximum. Quand l'avis de sécurité sort, l'attaque est déjà en cours dans la nature.

Le cas NetScaler, surnommé CitrixBleed 2, est différent et instructif. Le score paraît plus modeste (7,5) parce qu'il ne s'agit que d'une lecture mémoire hors limites, pas d'une exécution de code. Mais cette lecture fuit des jetons de session valides : de quoi rejouer une session authentifiée sans mot de passe, sans second facteur, sur une passerelle d'accès distant. Le CVSS sous-estime l'impact réel, et c'est un rappel utile que la lecture du score CVSS seule ne dit ni si vous êtes exposé, ni ce qu'un attaquant en fait vraiment. Vingt-trois jours ont séparé la publication de la confirmation d'exploitation. Vingt-trois jours pour recueillir des sessions.

Enfin, ProxyLogon, l'incident Exchange fondateur. La date d'inscription au KEV (novembre 2021) ne veut rien dire ici, parce que le catalogue lui-même n'existait pas avant : c'est une entrée rétroactive. Ce qui compte, c'est la chronologie réelle. La faille SSRF a été exploitée comme zero-day dès le début de 2021 ; Microsoft a publié un correctif en urgence, hors cycle, le 2 mars 2021 ; et dans les jours qui ont suivi la publication, l'exploitation est passée de quelques opérateurs ciblés à un balayage massif d'Internet, tant que des serveurs Exchange restaient non patchés. Le schéma que toutes les autres répètent : petite exploitation silencieuse, divulgation, puis ruée sur le parc n-day.

La fenêtre avant le patch : ce qui marche vraiment

Face à une zero-day, la première réaction, patcher, est parfois impossible (pas de correctif) et toujours insuffisante à elle seule (il faut le déployer, le tester, redémarrer un équipement de production). Alors on se rabat sur ce qui reste, dans l'ordre :

• Savoir ce qu'on expose : la seule action qui garde de la valeur avant même qu'un correctif existe. Sans inventaire des services joignables depuis Internet et de leurs versions, vous découvrez votre exposition en lisant un article de presse, ou pire, dans les journaux d'un attaquant.
• Appliquer les contournements de l'éditeur : désactiver le composant vulnérable, filtrer un chemin d'URL, couper une fonctionnalité. Utile, à condition de savoir sur quels équipements l'appliquer, ce qui ramène au point précédent.
• Restreindre l'accès aux interfaces d'administration : un portail d'admin de VPN ou de pare-feu exposé à Internet entier est une invitation. Derrière une liste d'IP autorisées ou un accès conditionnel, la même faille perd l'essentiel de sa portée.
• Surveiller les signes de compromission : une fois la faille connue, les indicateurs le sont aussi. Encore faut-il savoir quels équipements surveiller en priorité, donc, encore, connaître son exposition.

Tout revient au même prérequis. Les mesures d'urgence supposent qu'on sache où les appliquer. Le jour où une CVE FortiOS ou NetScaler tombe, l'organisation qui tient un inventaire à jour de sa surface exposée lit une liste d'actifs concernés en quelques minutes. Celle qui ne l'a pas lance une chasse au trésor pendant que la fenêtre se referme. C'est toute la logique de la gestion de surface d'attaque externe.

Ce que verrait un module de surveillance de surface d'attaque

Décrivons le mécanisme, sans scanner quoi que ce soit qui ne nous appartienne pas. Des moteurs de cartographie d'Internet comme Shodan ou Censys collectent en continu les bannières des services exposés : la réponse qu'un serveur renvoie quand on ouvre une connexion. Un portail VPN SSL, une interface NetScaler, un serveur Exchange annoncent presque toujours leur produit et, souvent, leur version, dans un en-tête HTTP, un certificat TLS, une page de connexion ou une réponse d'erreur caractéristique. C'est de l'information passive, publiée par l'équipement lui-même à qui veut l'écouter.

Un module de surveillance de surface d'attaque reconstruit cet inventaire du point de vue de l'attaquant, à partir de vos domaines, puis recoupe chaque bannière et chaque version avec les CVE connues. Le jour où une nouvelle faille tombe sur FortiOS, le travail est déjà fait : la version vulnérable est dans l'inventaire ou elle ne l'est pas.

La corrélation par bannière et version a ses limites, et il faut les dire. Elle repère l'exposition probable, pas la preuve d'une faille exploitable : une version peut être rétroportée sans changer de numéro affiché, un contournement peut déjà être en place, une bannière peut être maquillée. C'est un signal de priorisation, pas un verdict de compromission. Pour transformer ce signal en certitude, il faut aller confirmer l'exploitabilité, ce que fait un pentest automatisé non intrusif côté outil, ou un pentest web en boîte noire quand l'enjeu justifie une main humaine. Mais avant tout cela, il faut la liste. Et cette liste, il faut la tenir avant que la faille ne tombe, parce qu'après, il est déjà tard.

À retenir

• Zero-day = zéro jour pour se préparer. La faille est exploitée avant tout correctif. Dès que le patch existe et n'est pas déployé, elle devient une n-day, aussi dangereuse en pratique.
• Le délai réel se compte en jours. Sur 54 CVE d'équipements de bord au catalogue CISA KEV (2024 à 2026), écart médian divulgation vers confirmation d'exploitation : 6 jours. Seize confirmées le jour même ou avant.
• Les équipements exposés sont la cible n°1. VPN SSL, passerelles, serveurs de messagerie : frontaux, avant authentification, un accès direct au réseau une fois compromis.
• Avant le patch, savoir ce qu'on expose est le seul levier durable. Contournements, restriction d'accès et surveillance supposent tous de connaître ses actifs exposés et leurs versions.
• La corrélation bannière vers CVE priorise, elle ne prouve pas. Elle signale une exposition probable ; la confirmation d'exploitabilité demande un test dédié.

Une faille zero-day n'attend pas que vous soyez prêt. La seule chose qui se prépare à l'avance, c'est la connaissance de votre propre surface exposée : quels services, quelles versions, joignables depuis où. C'est ce que la surveillance de surface d'attaque externe tient à jour en continu, prête à recouper la prochaine CVE le jour où elle tombe. Si vous voulez savoir ce qu'un attaquant voit de vous avant lui, parlons-en.

Questions fréquentes sur les failles zero-day