Peu avant le week-end, les premières alertes (notamment Mojang éditeur de Minecraft) ont été lancées sur une faille critique dans Apache Log4j, une bibliothèque de log dont se servent des millions d’applications Java. Cette vulnérabilité est connue sous le nom de CVE-2021-44228 et a été publiée le 9 décembre. Rapidement, les développeurs ont publié un correctif avec la version 2.15.0 de la librairie.

L’exploit Log4Shell

La faille découverte, peut conduire à l’exécution de code à distance sur les serveurs servant aux applications vulnérables et elle ne nécessite aucune authentification. La sévérité de la brèche est maximale 10 sur l’échelle CVSS. Le CERT-FR a résumé la situation en expliquant « cette vulnérabilité permet à un attaquant de provoquer une exécution de code arbitraire à distance s'il a la capacité de soumettre une donnée à une application qui utilise la bibliothèque log4j pour journaliser l'évènement. Cette attaque peut être réalisée sans être authentifié, par exemple en tirant parti d'une page d'authentification qui journalise les erreurs d'authentification ». Depuis log4j 2.15.0, ce comportement a été désactivé par défaut.

Cela signifie que si un utilisateur peut générer une requête spécifique et qu’elle est enregistrée par Log4j, la faille pourrait être exploitée. Comme la plupart des applications sont conçues pour accepter les requêtes de l’utilisateur de différentes manières, l’exploitation de la vulnérabilité apparaît triviale.

La brèche a été découverte en premier lieu par l’équipe de sécurité du cloud d’Alibaba et en particulier Chen Zhaojun en novembre dernier. D’après les commentaires des développeurs dans le système de suivi des bugs, la publication d’une version corrigée de Log4j aurait été retardée, car les chercheurs ont trouvé un moyen de contourner le correctif initialement proposé, nécessitant un travail et un examen supplémentaire.

Un impact durable

La vulnérabilité n'affecte pas seulement les applications et services basés sur Java qui se servent directement de la librairie, mais aussi de nombreux autres composants Java et framework populaires qui en dépendent, notamment Apache Struts2, Solr, Druid, Flink, ElasticSearch, Kafka et bien d'autres. La communauté travaille encore à l’évaluation de la surface d’attaque, mais il est probable que l’onde de choc soit énorme en raison des dépendances complexes au sein de l’écosystème. Certains des composants touchés sont utilisés par des millions d’applications et de services en entreprise. Des services gérés par Apple (iCloud), Amazon, Twitter, Cloudflare, Steam, Tencent, Baidu et d'autres ont été signalés comme étant vulnérables. Cloudflare a créé des règles de détection dans son pare-feu d'application web pour bloquer les tentatives d'exploitation et a publié un avis. Le chercheur Florian Roth a également publié des règles de détection YARA. 

« Je m'attends à ce que cela traîne pendant un long moment », a déclaré Chris Wysopal, directeur technique Veracode, lors d'un webinaire sur la faille. « ll peut y avoir des applications sur lesquelles vous avez une bonne visibilité et que vous trouvez assez rapidement, mais il est difficile de trouver toutes vos applications Java. » Il ajoute, « l'autre défi est, bien sûr, les applications des fournisseurs qui sont écrites en Java. Vous savez, nous avons vu cela avec Heartbleed il y a de nombreuses années - qui a en quelque sorte donné le coup d'envoi de tout le risque lié aux tiers - que beaucoup d'applications de fournisseurs étaient écrites avec la bibliothèque SSL ouverte et que vous deviez attendre que votre fournisseur applique un correctif. La même chose pourrait se produire ici. De nombreux terminaux et logiciels intégrés utilisent Java, et je m'attends donc à ce que les gens demandent aux constructeurs et éditeurs quand ils seront corrigés. »

Une aubaine pour les pirates

Les attaquants scrutent déjà l'internet à la recherche d'applications et de services susceptibles d'être vulnérables à CVE-2021-44228 et le service de surveillance du trafic GreyNoise signale que le nombre de tentatives d'exploitation s'accélère. Des cybercriminels se servent de botnet comme Mirai ou Mushtik pour installer Log4jshell sur des terminaux vulnérable, explique Netlab360. D’autres l’utilisent pour diffuser des cryptomineurs. Le centre de threat intelligence de Microsoft a observé des placements de balises Cobalt Strike. Cet outil de pentest est souvent un vecteur d’attaque dans le cadre des ransomwares.

Il est probable que les entreprises vont être occupées pendant des mois à rechercher et à corriger les applications vulnérables à ce problème, ce qui souligne l'importance pour les éditeurs  de mettre en œuvre des nomenclatures logicielles. Malheureusement, le fait de ne pas patcher en temps voulu des failles activement exploitées peut conduire à des brèches majeures. Le piratage majeure d'Equifax en 2017 est le résultat de l'absence de correctifs pour une vulnérabilité Struts2 activement exploitée pendant deux mois dans une application destinée au public.

Des mesures d'atténuation

Dans certains cas, les exploits actuels peuvent ne pas fonctionner même si Log4j est vulnérable, par exemple si le système hôte utilise une version de Java supérieure à 6u212, 7u202, 8u192 ou 11.0.2. En effet, ces versions ont amélioré la protection du chargement de classe à distance JNDI (Java Naming and Directory Interface), qui est nécessaire pour que l'exploit fonctionne.

En outre, dans les versions de log4j supérieures à 2.10, le problème peut être atténué en définissant la propriété système formatMsgNoLookups sur true, en définissant le paramètre JVM -Dlog4j2.formatMsgNoLookups=true ou en supprimant la classe JndiLookup du classpath.

Cependant, la meilleure solution est de mettre à jour vers log4j 2.15.0 car quelqu'un pourrait trouver un chemin alternatif pour atteindre la vulnérabilité. Par ailleurs, plusieurs éditeurs et constructeurs ont annoncé des mises à jour pour corriger leurs services ou applications.