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

Explorar

1. Inicie um listener netcat:

2. Acione o exploit:

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

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

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:

3. Reforçar a JVM:

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