Si le titre de notre article vous a attiré, donc vous avez sans doute entendu parler du log4j ou log4shell, et vous demandez la signification de ses deux termes ainsi que leurs relations avec la technologie en général et l’informatique en terme spécifique. C’est pour cette raison que nous avons décidé d’aborder ce sujet, pour vous aider à comprendre cette faille.
Le monde d’informatique spécialement celui du développement d’application en Java tremble à cause du log4j ou Log4 Shell depuis le mois de décembre passé.
“La plus grande et la plus critique des vulnérabilités de la dernière décennie“ selon le président et CEO de Tenable Amit Yoran.
Venez ! découvrons ça ensemble.
Terminologie
Log4j est le nom qui est donné à la librairie qui était impactée. Tandis que log4Shell est le nom qui a été donné à la vulnérabilité.
Ce qu’il faut savoir à propos du (de la)vulnérabilité Log4j :
C’est une bibliothèque de journalisation programmée avec le langage Java, cette bibliothèque est mise à disposition aux utilisateurs par ‘Apache logging services’, généralement les applications Java utilisent log4j ; par exemple : Apache Struts, ElasticSearch, Redis, Kafka….
Pour information, la journalisation est une action qui permet de sauvegarder les opérations d’une application, si vous allez sur google.ca, le serveur google (Google) enregistre votre adresse IP, la requête et le nombre d’informations sur les fichiers journaux.
Toutes les vulnérabilités ont généralement un code (alerte) CVE (Common Vulnerabilities and Exposures) et un score CVSS (Common Vulnerability Scoring System).
Ils ont commencé à parler de cette vulnérabilité le 09/12/2021, donc la première alerte a été annoncée par Chen Zhaojun de Alibaba Cloud Security, certaines personnes ont dit que cette vulnérabilité existait avant cette date.
Nous avons vu précédemment que log4j est une bibliothèque qui va permettre de journaliser certaines actions, pour information une bibliothèque est un ensemble de fonctions qui sont mises à la disposition du développeur pour faciliter la création de certaines applications. Parfois les données journalisées ou les fichiers de Log proviennent d’une entrée utilisateur, cela veut dire que nous allons enregistrés ce que l’utilisateur va saisir sur l’application, et si les informations fournies par l’utilisateur contiennent certains caractères spéciaux, log4j va appeler une fonction Java Look Up a fin d’interpréter ses caractères spéciaux. Le problème qui se pose est qu’un pirate peut injecter des codes malveillants et forcer le serveur vulnérable à exécuter ce code.
Voici deux schémas qui peuvent bien expliquer ce que nous venons de dire :
01-sur le premier schéma, vous pouvez voir le fonctionnement d’un serveur qui utilise une application java, donc l’utilisateur va saisir sa requête, il veut par exemple accéder à la page Index. PHP, dans les informations qui sont renvoyés au serveur y’aurai également celles qui sont liées à l’indicateur web, c’est ce qu’on appelle agent utilisateur, agent qui va contenir le nom de l’indicateur et les informations sur la version, ensuite le serveur quand il reçoit les informations, il va appeler Log4J pour les enregistrer. C’est ce qu’on définit par les fichiers journaux, ce qui désigne un Fonctionnement normal.
02- Sur le deuxième schéma vous allez remarquer qu’un serveur qui est vulnérable le pirate va demander la page index.php et il va également saisir quelques données qui vont permettre d’exécuter du code à distance , là le pirate va injecter Du code à partir du $(jndi (Java Naming and Directory Interface), et vous allez voir qu’il a injecté une adresse d’un serveur LDAP (Lightweight Directory Access Protocol) suivi d’un script qui sera exécuté, quand le serveur vulnérable va recevoir cette information , il va faire appel à log4j qui est une version vulnérable et qui va donc faire appel à la fonction Jndi ( est un composant java qui permet d’interagir avec un serveur LDAP , un service DNS (Domain Name System) et plusieurs autres services) donc une fois que la méthode java look up Jndi va recevoir l’information qui se trouve dans le user(agent utilisateur) agent il va donc faire appel au serveur LDAP qui va exécuter un script-dangeureux.sh qui demande de pouvoir renvoyer certaines informations au serveur du pirate . C’est ce qu’on appelle un fonctionnement vulnérable.
Quels sont les composants impactés par la vulnérabilité log4shell?
Les versions de la librairie log4j qui sont impactées vont 2.0 à la 2.15, la 2.0 est sortie en 2012 et la 2.15 est sortie le mois de décembre 2021, donc les applications potentiellement impactées sont une grande partie des applications en java qui ont été développées ou mis à jour entre 2012 ou au mois de décembre 2021.
Comment se protéger de la vulnérabilité Log4shell?
Y’a plusieurs approches possibles, travaux à mener en parallèle qui apportent plus au moins de résultats.
Selon des architectes en sécurité informatique une des premieres choses à faire, c’est si vous avez des équipements de protection périmétrique de type Waf ou IPS, il faut absolument appliquer des signatures qui sont aujourd’hui disponibles, car l’attaque date du mois de décembre dernier, quel que soit la technologie que vous avez, appliquez en mode bloquant toute les signatures qui sont relatives à log4shell ou la cve2021-44228, qui va vous donner un premier niveau de protection.
NB : Avec un Waf (Web Application Firewall) vous protégez tout ce qui est du WEB.
Avec un IPS (Intrusion Prevention System), vous protégez, tout ce qui n’est pas chiffré.
Ou tout simplement, couper les accès internet de vos serveurs qui vont permettre d’empêcher un serveur qui serait potentiellement vulnérable de communiquer vers Internet.
D’après ce que nous avons lu et découvert dans cet article, nous pouvons maintenant comprendre la gravité de cette vulnérabilité sur les systèmes informatiques.
Références :
http://www-igm.univ-mlv.fr/~dr/XPOSE2005/lamps/log4j.php