Vulnérabilités logicielles : comprendre les failles zero-day

Un correctif qui sort un mardi après-midi, une note de version de trois lignes, et dans les heures qui suivent, une vague de serveurs compromis chez des clients qui n'avaient rien demandé. Voilà à quoi ressemble une faille zero-day vue depuis un poste de travail, pas depuis une définition de manuel. Et c'est précisément le problème : la plupart des explications qu'on trouve en ligne s'arrêtent à la définition et ratent tout ce qui compte.

Une faille zero-day, c'est quoi exactement ?

La réponse tient en une phrase : c'est une vulnérabilité informatique qui n'a fait l'objet d'aucune publication ou qui n'a aucun correctif connu. Tant que ce correctif n'existe pas, aucune protection palliative ni définitive ne peut être déployée. C'est ce qui la distingue d'une faille ordinaire, pour laquelle un éditeur a déjà publié un avis et un patch plus ou moins propre.

Le mot mérite qu'on s'y arrête, parce qu'il est mal compris. "Zero-day" ne dit rien de la dangerosité. Une faille inconnue peut être bénigne comme catastrophique. Le terme signifie seulement que la faille est inédite : à l'instant zéro, elle est encore inconnue du grand public. Sa gravité réelle dépend de deux choses séparées : l'ampleur des dégâts qu'on peut occasionner, et l'existence d'un exploit, c'est-à-dire d'une technique concrète permettant d'en tirer parti.

Vulnérabilité, exploit, attaque : trois choses différentes

On mélange tout le temps ces trois niveaux, et ça brouille la conversation. Reprenons proprement :

• La vulnérabilité est le défaut dans le logiciel. Elle existe même si personne ne l'a trouvée.
• L'exploit est l'outil ou la méthode qui l'active pour provoquer un comportement non prévu.
• L'attaque zero-day est le moment où quelqu'un utilise cet exploit sur une cible réelle, avant que le correctif n'existe.

Vous pouvez avoir une faille sans exploit connu. Vous pouvez avoir un exploit qui dort dans un tiroir pendant des mois. Et vous pouvez avoir une attaque qui frappe avant même que l'éditeur ait compris ce qui se passe. Trois états distincts, trois niveaux d'exposition.

Le cycle de vie d'une zero-day, étape par étape

Ce que les définitions ne montrent jamais, c'est le temps. Une zero-day n'est pas un événement, c'est un processus — découvrez le ci-dessous.

De la découverte au correctif

1. Quelqu'un trouve la faille. Cette personne peut être un chercheur en sécurité, un attaquant, ou un courtier qui achète et revend de l'information.
2. Selon qui l'a trouvée, soit elle est signalée à l'éditeur, soit elle est gardée secrète pour être exploitée ou vendue au plus offrant.
3. L'éditeur accuse réception, tente de reproduire le problème, puis développe un correctif. C'est souvent l'étape la plus longue, parce qu'il faut corriger sans casser le produit.
4. La faille est divulguée publiquement — souvent après un délai convenu entre le chercheur et l'éditeur. Google Project Zero travaille par exemple avec une politique de 90 jours avant divulgation, une pratique qui pousse les éditeurs à réagir vite.
5. Le patch sort, les entreprises l'appliquent... plus ou moins rapidement. Et pendant tout ce temps, la fenêtre d'exposition est restée ouverte.

Le problème, ce ne sont pas les étapes. C'est le décalage entre elles. Entre la découverte et la sortie du patch, il peut s'écouler des semaines. Entre la sortie du patch et son déploiement réel dans une entreprise, parfois des mois. Un correctif publié n'est pas un correctif appliqué.

Pourquoi ça déraille dans les organisations

Je l'ai vu trop souvent. Un éditeur publie un correctif critique un vendredi. Le service informatique prévoit de l'appliquer "la semaine prochaine", parce qu'il faut tester, parce que le patch peut casser une application métier, parce que personne n'est disponible le week-end. Et c'est précisément dans cette fenêtre que l'attaque arrive. Le même jour où vous patchez, quelqu'un teste encore si la faille est ouverte chez vous.

Le marché invisible des zero-days

Il existe une économie parallèle autour des failles inconnues, et elle est beaucoup plus structurée qu'on l'imagine. D'un côté, les programmes de bug bounty : l'éditeur paie le chercheur pour qu'il signale la faille discrètement. De l'autre, des courtiers qui achètent la même information pour la revendre, parfois à des gouvernements, parfois à des entreprises de surveillance.

Combien vaut une faille ?

La valeur dépend de la cible. Une faille dans un navigateur grand public ne vaut pas le même prix qu'une faille dans un système mobile ou dans la couche de communication d'un téléphone. Les courtiers du marché gris et noir ajustent leurs offres selon la difficulté, la portée et la discrétion requise. Des cas comme Pegasus ou les campagnes autour de ProxyLogon ont montré à quel point ces outils peuvent être utilisés à grande échelle.

Ce qui me frappe, ce n'est pas l'existence de ce marché. C'est son calme. Personne n'y crie. Les transactions se font par des canaux privés, avec des contrats et des clauses de confidentialité. Pendant ce temps, l'entreprise victime découvre le problème seulement quand son système est déjà compromis.

Bug bounty ou marché gris : la même faille, deux destins

Une même faille peut finir aux mains d'un éditeur qui la corrige, ou d'un acheteur qui la garde pour plus tard. La différence se joue rarement sur la morale du chercheur. Elle se joue sur le prix, le délai et la relation de confiance qu'il entretient avec l'éditeur concerné.

Critère	Programme de bug bounty	Marché gris / noir
Qui paie	L'éditeur du logiciel	Un courtier, un état, un acteur privé
Délai de paiement	Variable, encadré par le programme	Souvent rapide, parfois négocié
Usage de la faille	Correction	Exploitation ou revente
Publicité	Le chercheur peut être crédité	Confidentialité totale

Comment se défendre quand la faille est encore inconnue

Aucun outil ne détecte ce que personne ne connaît encore. C'est la vérité inconfortable de la sécurité informatique, et elle ne changera pas demain. Ce qu'on peut faire, en revanche, c'est réduire la surface d'exposition et augmenter le coût pour l'attaquant.

EDR, XDR, sandboxing : ce qu'ils font vraiment

Ces outils ne détectent pas la faille. Ils détectent le comportement anormal qui suit son exploitation. Un processus qui ouvre un fichier auquel il ne devrait pas toucher, une connexion sortante vers une adresse inhabituelle, un script qui se réveille à 3 heures du matin sans raison. La détection comportementale est aujourd'hui la seule couche qui tient à peu près la route face à une zero-day, parce qu'elle ne repose pas sur la connaissance préalable de l'attaque.

Ce qui marche vraiment dans une organisation

• Inventorier ce que vous exposez sur Internet, et couper tout ce qui ne sert pas.
• Cloisonner les environnements critiques pour qu'une compromission reste locale.
• Mettre en place un processus de patch qui n'attend pas le vendredi suivant.
• Surveiller les comportements, pas seulement les signatures.
• Accepter que le risque zéro n'existe pas, et prioriser en fonction.

La vérité, c'est que la plupart des entreprises ne sont pas attaquées par une zero-day exotique. Elles sont attaquées par une faille connue depuis deux ans, jamais corrigée. La zero-day fascine, mais la négligence tue bien plus souvent.

Ce que des cas réels nous ont appris

Stuxnet a montré qu'une opération peut viser des systèmes industriels très spécifiques et rester invisible des années. WannaCry, bâti sur une technique d'exploitation qui avait circulé, a paralysé des hôpitaux et des entreprises en quelques heures. Log4Shell a exposé une bibliothèque utilisée partout dans le monde. ProxyLogon a touché les serveurs de messagerie. Et Pegasus a transformé un téléphone en outil de surveillance personnel, sans que la cible s'en rende compte.

Ces cas partagent une chose : la faille était là, discrète, jusqu'au jour où elle ne l'a plus été. Et le temps entre la découverte et la correction a été décisif. Pour Log4Shell, la fenêtre a été extrêmement courte côté éditeur et beaucoup plus longue côté entreprises. Pour WannaCry, le correctif existait déjà avant que la vague ne frappe — mais il n'avait pas été appliqué partout.

Les questions qu'on me pose souvent

Faille zero-day c'est quoi, en une phrase ?

Une vulnérabilité informatique sans publication ni correctif connu. Tant qu'aucune mise à jour n'existe, aucune protection — palliative ou définitive — n'est disponible pour la corriger. C'est la définition la plus courte et la plus utile à retenir.

Une zero-day est-elle forcément plus grave qu'une autre faille ?

Non. Le terme qualifie l'antériorité, pas la gravité. Une faille inédite peut être mineure, une faille ancienne peut être dévastatrice. Ce qui change avec une zero-day, c'est qu'aucun correctif n'est disponible au moment où elle est exploitée. Ça n'en fait pas automatiquement la pire chose au monde.

Pourquoi entend-on toujours parler de faille zero-day Microsoft ?

Parce que Windows et les produits Microsoft sont utilisés partout, ce qui en fait une cible à fort rendement pour les attaquants. Une faille dans ces logiciels touche potentiellement des millions de machines en même temps. C'est le même principe que pour Chrome ou les systèmes mobiles : plus la base installée est large, plus la faille a de valeur.

Peut-on détecter une zero-day avant qu'elle ne frappe ?

Pas par la connaissance de la faille, non. On peut en revanche détecter son exploitation via des comportements anormaux. C'est tout l'intérêt des outils de détection comportementale, qui repèrent l'activité suspecte plutôt que la signature d'un logiciel malveillant connu.

Ce qui me dérange le plus, au fond, ce n'est pas que ces failles existent. C'est la tranquillité avec laquelle tout le monde continue de fonctionner en sachant que la prochaine est déjà là, quelque part, en attente. Le correctif viendra. La question, c'est quand — et ce que vous aurez perdu entre-temps.