Vulnérabilités zero-day : est-il vraiment pertinent de les rendre publiques ?

Avec la récente découverte de la faille Log4Shell, été rendue publique avant qu’un patch soit officiellement disponible, une question revient : est-il bien raisonnable de dévoiler publiquement des zero-day ?

C’est en tout cas ce que se demande Alex Haynes sur Helpnet Security, qui consacre un nouvel article au sujet.

Une question récurrente

En décembre, Log4Shell a provoqué un mini-séisme dans le monde de l’informatique : une faille dans un logiciel open-source très populaire, facile à exploiter par n’importe qui et pour laquelle des preuves de concept ont été publiées avant qu’un patch soit validé et disponible officiellement. Si les bénévoles en charge du projet avaient été prévenus en amont de l’existence de la faille par un chercheur d’Alibaba Cloud, un autre chercheur a décidé de publier sur Twitter une preuve de concept avant que le patch soit déployé pour tous les utilisateurs. Une fois l’utilisation de la vulnérabilité popularisée par les joueurs de Minecraft et reprise par les médias, une course contre la montre s’est enclenchée pour les différents acteurs du secteur qui utilisaient Log4j d’une façon ou d’une autre au sein de leurs produits et logiciels.

Désormais se pose la question suivante : était-ce bien raisonnable de publier une preuve de concept avant qu’un patch soit déployé pour tout le monde ? Une question qui fait débat depuis des années dans le monde de la sécurité et déjà mise sur le devant de la scène en 2016 lorsque Google avait dévoilé publiquement une zero-day présente dans les produits Microsoft, seulement quelques jours après avoir prévenu l’entreprise et sans que celle-ci puisse sortir un patch à temps. À l’époque, les ingénieurs de Google avaient justifié leur décision par le fait que c'était leur règle dans le cas d’une zero-day déjà exploitée. Ce à quoi Microsoft avait répliqué que l’exploitation était minimale et ciblée avant que la faille soit rendue publique et qu'il n'était pas donc pas nécessaire de la dévoiler aux yeux du plus grand nombre.

Dévoiler une faille avant un patch ne profiterait qu'aux attaquants

Une étude sur le sujet publiée par Kenna Security et soulignée par Alex Haynes donne raison à Microsoft. En mai 2021, Kenna Security et Cyentia Institute se sont alliés pour conduire une étude cherchant à déterminer si dévoiler des vulnérabilités avant qu’un patch soit disponible permettait de développer des correctifs pour ces failles plus rapidement ou si cette façon de faire profitait majoritairement aux attaquants. Cette étude conclut que dévoiler une vulnérabilité avant qu’un patch soit disponible donne aux attaquants environ 98 jours d’avance sur les défenseurs et que ces vulnérabilités sont exploitées 15 fois plus que les autres, ce nombre montant à 30 fois plus si la faille permet de l’exécution de code à distance. Au contraire, peu de preuves ont été trouvées pour soutenir l’argument contraire, disant que dévoiler ces failles pousserait les entreprises à les corriger plus rapidement.

Dans un cas parfait de découverte d’une faille, les chercheurs à l'origine de la trouvaille préviennent l’entreprise qui possède le logiciel ou le site web dans lequel elle est présente, les deux parties se mettent d’accord sur une durée pour la sortie d’un patch et à quel moment il est possible d’en parler publiquement. Généralement, tout cela se fait dans les 90 jours, même si des exceptions sont possibles au cas par cas selon la faille.

Une faille est une « zero-day » quand aucun patch n'existe pour la corriger, car le fournisseur n'a pas connaissance de son existence avant son exploitation ou sa publication. Il a donc « zéro jour » pour la corriger. Les zero-day sont rares et convoitées : il existe tout un marché légal de ventes de ces failles à divers organismes gouvernementaux et militaires. Si un groupe en découvre une et souhaite l’exploiter plutôt que prévenir l’entreprise, cette exploitation est généralement minimale et ciblée pour éviter que la vulnérabilité soit découverte et patchée. Dans ce genre de cas, la faille n'est généralement pas une menace pour le grand public. Dès qu’une faille zero-day devient publique, il y a deux possibilités : soit elle perd de son intérêt puisqu’elle va être patchée, soit elle est facile à exploiter et sévère, comme Log4Shell, et devient par conséquent une menace globale très dangereuse et exploitée massivement par plusieurs groupes très rapidement, avant que toutes les personnes concernées aient pu la combler.

Un point de vue à nuancer

C’est pourquoi il est considéré par une partie de la profession que dévoiler une faille publiquement avant la sortie d’un correctif est peu éthique. Mais des exemples récents nous ont montré que des nuances existent sur le sujet et que parfois, des chercheurs décident de rendre des failles publiques pour différentes raisons.

Ces derniers mois par exemple, plusieurs professionnels ont décidé de dévoiler publiquement des vulnérabilités non patchées dans les produits Apple, pour protester contre la politique de l’entreprise sur les bugs bounties et le correctif de vulnérabilités. Certains dénonçaient des paiements bas, d’autres rapportaient être totalement ignorés par l’entreprise ou considéraient que leur découverte n’était pas assez prise au sérieux et tentaient de cette manière de forcer la main de la société pour l’obliger à sortir un patch. Il y a aussi des cas d’entreprises hostiles aux chercheurs qui les approchent et ces derniers peuvent donc décider de rendre leurs découvertes publiques pour les obliger à réagir tout en sachant qu’aucun dialogue n’est possible.

Dans le cas de Log4Shell, la publication d’une preuve de concept avant la sortie d’un patch définitif semble donc tomber dans la catégorie de la divulgation irresponsable, ce que le chercheur a probablement réalisé trop tard en choisissant de supprimer son tweet. Nul doute cependant qu’à chaque fois qu’elle sera soulevée, cette question continuera de diviser la communauté.

Source : Helpnet Security