Qu'est-ce qu'une vulnérabilité zero-day ?

Vulnérabilité, exploit et attaque zero-day

Ces trois termes sont souvent employés indifféremment, mais ils décrivent des choses différentes :

• Vulnérabilité zero-day : la faille elle-même, inconnue de l'éditeur ou sans correction.
• Exploit zero-day : le code ou la technique qui tire parti de la faille.
• Attaque zero-day : l'exploit utilisé contre de vraies cibles.

Dès que l'éditeur livre une correction, la faille cesse d'être une zero-day et devient une vulnérabilité connue, souvent appelée n-day. Une deuxième course commence alors : les attaquants étudient le correctif et recherchent les systèmes qui ne l'ont pas appliqué. Une vulnérabilité connue et non corrigée peut donc causer autant de dégâts que la zero-day d'origine.

Les zero-days dans vos dépendances

L'essentiel du code d'une application moderne provient de paquets open source, et la plupart d'entre eux sont des dépendances transitives : amenées par d'autres paquets plutôt que choisies par votre équipe. Une zero-day dans l'un d'eux est une zero-day dans votre produit.

Log4Shell (CVE-2021-44228) en est l'exemple le plus connu. Divulguée en décembre 2021, elle permettait à un attaquant qui contrôlait un message journalisé d'exécuter du code arbitraire via Apache Log4j 2, et elle a obtenu le score CVSS maximal de 10,0. Pour la plupart des équipes, le plus difficile n'était pas la correction, mais la question qui la précède : lesquelles de nos applications contiennent log4j-core, et dans quelles versions ? Log4j était généralement une dépendance d'une dépendance, et de nombreuses équipes ont passé des jours à le découvrir.

Les zero-days de la chaîne d'approvisionnement ne sont pas toujours des bugs. En mars 2024, Andres Freund a découvert une porte dérobée dans les versions 5.6.0 et 5.6.1 de xz (CVE-2024-3094) après avoir remarqué que les connexions SSH consommaient trop de CPU. Les releases malveillantes de paquets, une forme courante d'attaque de la chaîne d'approvisionnement, fonctionnent de la même façon : les premières équipes qui installent une version infectée, comme celles touchées par le ver npm Shai-Hulud, font face à une attaque qu'aucun avis ni aucun scanner ne connaît encore.

Comment réagir lorsqu'une zero-day touche une dépendance

1. Localisez-la. Listez chaque application, image et release qui contient le composant touché, y compris comme dépendance transitive. Cela exige une SBOM exacte pour chaque build. Un lockfile passe à côté des dépendances récupérées hors du gestionnaire de paquets, comme le code téléchargé par des scripts d'installation ou les couches du système d'exploitation d'une image de conteneur.
2. Déterminez la période d'exposition. Quels builds ont livré la version vulnérable, et depuis quand ? Vous saurez ainsi ce qu'il faut examiner et ce qu'il faut signaler.
3. Contenez-la. Appliquez la correction ou un contournement s'il en existe un, et empêchez les nouveaux builds de livrer la version vulnérable dès qu'elle a une CVE. Consultez la remédiation des CVE.
4. Recherchez toute exploitation. Cherchez des signes montrant que la faille a été utilisée contre vous pendant la période d'exposition, et renouvelez tous les secrets qu'elle a pu atteindre.

Sommes-nous touchés ? détaille les deux premières étapes.

Peut-on se défendre contre une zero-day que personne ne connaît ?

Pas avec des correctifs ni avec des scanners, car les deux supposent que la faille soit connue. Ce qui fonctionne avant la divulgation, c'est de limiter ce qu'un attaquant peut faire d'une faille qu'il découvre :

• Moindre privilège. Ne donnez à chaque système et à chaque job CI que les accès et secrets dont il a besoin.
• Contrôle du trafic sortant. Bloquez les connexions sortantes vers les hôtes dont un système n'a pas besoin, pour qu'un exploit qui s'exécute ne puisse pas envoyer de données à l'attaquant. Dans un build CI, c'est l'un des rares contrôles qui fonctionnent même si vous êtes la première victime d'un nouveau paquet malveillant. Consultez les politiques de trafic sortant pour GitHub Actions.
• Défense en profondeur. Superposez les contrôles pour qu'une seule faille n'ouvre pas toutes les portes.
• Des traces consultables plus tard. Lorsque la zero-day est divulguée, la rapidité de votre réponse dépend de votre connaissance de ce que vous avez construit et livré.

Comment CRACI aide

CRACI exécute vos jobs GitHub Actions sur ses propres runners et enregistre chaque build au moment où il se déroule :

• Les SBOM au build listent les paquets réellement récupérés par chaque job, y compris les dépendances cachées que les outils fondés sur les lockfiles ratent : vous pouvez répondre à la question « où se trouve-t-elle ? » à partir de ce qui a vraiment été construit. Consultez les SBOM au build.
• L'historique des builds montre chaque build passé et sa SBOM, ainsi que les builds qui contenaient une dépendance vulnérable, directe ou transitive : vous connaissez ainsi la période pendant laquelle vous étiez touchés.
• Les gates de politique peuvent bloquer un build qui contient une CVE précise, pour que les nouveaux builds ne livrent plus la version vulnérable.
• Une politique de trafic sortant avec refus par défaut bloque les connexions vers les hôtes dont le build n'a pas besoin, même pendant une attaque que personne n'a encore vue.

Vulnérabilités zero-day : questions fréquentes

Qu'est-ce qu'une vulnérabilité zero-day ?

Une faille de sécurité que des attaquants connaissent, ou exploitent déjà, avant que l'éditeur ou le mainteneur n'ait publié une correction. Le nom compte les jours dont les défenseurs ont disposé pour la corriger : zéro.

Quelle est la différence entre une vulnérabilité, un exploit et une attaque zero-day ?

La vulnérabilité est la faille. L'exploit est le code ou la technique qui en tire parti. L'attaque est l'exploit utilisé contre de vraies cibles.

Quand une zero-day cesse-t-elle d'être une zero-day ?

Lorsqu'une correction est disponible. À partir de là, c'est une vulnérabilité connue, parfois appelée n-day, et le risque se déplace vers les systèmes qui n'ont pas encore appliqué la correction.

Un scanner peut-il détecter une zero-day ?

Pas par simple recherche. Les scanners de vulnérabilités comparent les composants aux avis publiés, et une zero-day n'en a pas encore. Ce qu'un scanner ou une SBOM vous apporte, c'est l'inventaire dans lequel chercher dès que l'avis paraît.

Comment savoir si une zero-day touche mon logiciel ?

Recherchez le composant et les versions touchés dans un inventaire exact de ce que contient chaque build et chaque release, dépendances transitives comprises. Déterminez ensuite quelles releases l'ont livré et depuis quand, afin de connaître la période d'exposition.