Introduction
Cela fait un peu plus d'un an que la fameuse vulnérabilité log4j a été révélée publiquement, entraînant les équipes de sécurité dans une frénésie de correctifs à l'approche des fêtes de fin d'année. Cette vulnérabilité, baptisée Log4Shell, est une faille critique d'exécution de code à distance (RCE) dans la bibliothèque de journalisation Apache log4j. Elle permet à un acteur de menace d'envoyer une requête avec une charge utile qui, lorsqu'elle est enregistrée par une version vulnérable de log4j, entraîne l'exécution de code à distance sur l'hôte. De plus, la charge utile est exécutée avec des permissions au niveau de l'utilisateur qui exécute le service (une raison de plus pour éviter d'exécuter les services en tant que "root").
La vulnérabilité a reçu le score CVSS le plus élevé possible , à savoir 10, et les praticiens ont été invités à appliquer des correctifs et à mettre à jour les systèmes vulnérables immédiatement. L'omniprésence de la bibliothèque log4j, utilisée dans un grand nombre d'outils et de produits, a accentuéla gravité de la vulnérabilité elle-même.
Cette vulnérabilité a fait couler beaucoup d'encre depuis sa divulgation, y compris notre examen initial de la vulnérabilité. Nous présentons ici notre enquête sur l'évolution de la remédiation de Log4Shell au fil du temps.
Mesurer la réaction de l'Internet à Log4Shell
À l'adresse Censys, nous voulions mieux comprendre comment l'Internet dans son ensemble réagissait à cette vulnérabilité. Pour ce faire, nous avons identifié un sous-ensemble de logiciels visibles sur Censys dont nous pouvions discerner les versions et les associer à un état "vulnérable" ou "non vulnérable" à Log4Shell. Plus précisément, nous avons examiné les hôtes utilisant les logiciels Metabase, Neo4j, Solr, Pagerduty et Unifi. L'analyse suivante ne représente pas tous les appareils vulnérables à Log4Shell existants, mais plutôt ce que nous pouvons observer à partir de nos analyses passives des appareils faisant face à Internet.
Les conséquences immédiates
Vous reconnaîtrez peut-être ce graphique si vous avez lu notre rapport 2022 sur l'état de l'Internet (et si ce n'est pas le cas, vous pouvez en obtenir un exemplaire ici). Comme indiqué dans le rapport, les correctifs ont été appliqués rapidement après la divulgation, et nous avons constaté une baisse de 34 % des appareils utilisant des logiciels apparemment vulnérables à Log4Shell entre décembre 2021, date de la divulgation de la faille, et janvier 2022. Cependant, nous étions curieux de savoir combien de temps ce sentiment d'urgence allait durer.
Un an après
De décembre 2021 à décembre 2022, Censys a observé une diminution de 78 % des hôtes qui semblent exécuter un logiciel vulnérable à Log4Shell.
Si la tendance générale à la diminution des versions vulnérables est prometteuse, il est inquiétant de constater que plus de 23 000 hôtes visibles sur le site Censys semblent encore vulnérables. En décembre 2022, Wired souligne que des acteurs chinois et iraniens parrainés par l'État continuent d'exploiter ce CVE. Les tentatives d'exploitation ne se limitent probablement pas non plus aux acteurs parrainés par l'État. À l'heure où nous publions cet article, GreyNoise identifie 327 hôtes qui semblent rechercher activement la vulnérabilité log4j.
Vulnérabilité par système autonome et par pays
Lorsque l'on examine le top 10 des systèmes autonomes où log4j semble rester vulnérable en décembre 2022, il n'est pas surprenant de voir deux AS appartenant à Amazon en tête de liste, car ils sont l'un des plus grands propriétaires de biens immobiliers sur Internet en termes de nombre d'hôtes et de services. D'autres fournisseurs de cloud populaires, dont Digital Ocean, Microsoft, OVH, Google et Alibaba, figurent également en bonne place sur cette liste.
À l'instar des observations selon lesquelles Amazon possède un grand nombre de services susceptibles d'être vulnérables à Log4Shell, il n'est pas surprenant de voir les États-Unis en tête de la liste des pays où nous observons le plus de services susceptibles d'être vulnérables. Toutefois, si la répartition des pays où nous observons des versions vulnérables de Log4j reflétait la répartition des pays où nous observons le plus de services au niveau mondial, nous ne nous attendrions pas à voir le Brésil si près du sommet de cette liste.
Conclusion
Bien que la communauté de la sécurité se soit mobilisée il y a un an pour corriger la vulnérabilité log4j, surnommée "sans doute la vulnérabilité la plus grave de tous les temps", celle-ci continue d'être exploitée et reste un outil précieux dans la boîte à outils d'un acteur de la menace. Un nombre non négligeable d'hôtes restent vulnérables à l'exploitation. Le meilleur moment pour corriger log4j était il y a un an, mais si vous utilisez une version vulnérable, le deuxième meilleur moment est maintenant.
Censys Les clients de l'ASM ont accès aux risques pour les logiciels dont il est question dans ce billet.
