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-log4shell-playground — Um playground para explorar as mitigações da vulnerabilidade Log4Shell (CVE-2021-44228) | Kitploit
Ferramentas/GitHubGitHub/rgl/log4j-log4shell-playground
Análise de VulnerabilidadesExploraçãoExploração de Aplicações WebTestes de PenetraçãoAprendizado e EducaçãoLabs e Prática
GitHubrgl/log4j-log4shell-playground

log4j-log4shell-playground

Um playground para explorar as mitigações da vulnerabilidade Log4Shell (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

Sobre

Um playground para testar as mitigações da vulnerabilidade crítica log4j (também conhecido como Log4Shell) (CVE-2021-44228).

Este problema específico reside no recurso JndiLookup e na capacidade do log4j de interpretar TODOS os argumentos de uma chamada de registro (logging).

Eu esperaria que interpretasse apenas a mensagem de formato (o primeiro argumento de uma chamada de registro), por exemplo, o Hello {} em log.info("Hello {}", "${jndi:ldap://127.0.0.1:8081}"), mas ele interpreta todos.

As mitigações evitarão que o log4j acione as pesquisas jndi, mas ainda permitem outras pesquisas como ${java:version}.

NB: A partir do log4j 2.16.0 (LOG4J2-3211; diff) a mensagem de formato não é mais interpretada.

Esta vulnerabilidade pode ser acionada remotamente quando a aplicação alvo registra qualquer dado fornecido pelo usuário, por exemplo, a partir destes cabeçalhos HTTP comuns:

  • Accept
  • Cookie
  • Location
  • Origin
  • Referer
  • User-Agent
  • X-Api-Version
  • X-Forwarded-For
  • X-Forwarded-Host
  • X-Requested-With
  • Testar (Ubuntu 20.04)

    Compilar:

    root@kitploit:~
    sudo apt-get install -y openjdk-11-jdk-headless
    wget https://archive.apache.org/dist/logging/log4j/2.10.0/apache-log4j-2.10.0-bin.tar.gz
    wget https://archive.apache.org/dist/logging/log4j/2.16.0/apache-log4j-2.16.0-bin.tar.gz
    tar xf apache-log4j-2.10.0-bin.tar.gz
    tar xf apache-log4j-2.16.0-bin.tar.gz
    javac -Werror -cp apache-log4j-2.10.0-bin/log4j-api-2.10.0.jar Server.java
    

    Teste uma versão vulnerável do log4j:

    root@kitploit:~
    java \
        -cp apache-log4j-2.10.0-bin/log4j-api-2.10.0.jar:apache-log4j-2.10.0-bin/log4j-core-2.10.0.jar:. \
        Server
    curl -H 'X-Api-Version:${jndi:ldap://127.0.0.1:8081}' http://localhost:8080
    curl -H 'X-Api-Version:${java:version}' http://localhost:8080
    

    Teste remover a classe JndiLookup do classpath como mitigação:

    root@kitploit:~
    cp apache-log4j-2.10.0-bin/log4j-core-2.10.0.jar log4j-core-2.10.0-without-jndi-lookup.jar
    zip -q -d log4j-core-2.10.0-without-jndi-lookup.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
    java \
        -cp apache-log4j-2.10.0-bin/log4j-api-2.10.0.jar:log4j-core-2.10.0-without-jndi-lookup.jar:. \
        Server
    curl -H 'X-Api-Version:${jndi:ldap://127.0.0.1:8081}' http://localhost:8080
    curl -H 'X-Api-Version:${java:version}' http://localhost:8080
    

    Teste a mitigação de variável de ambiente:

    NB Desde 2021-12-15 (aproximadamente data de lançamento do log4j 2.16.0 / CVE-2021-45046) isso não é mais recomendado.

    root@kitploit:~
    LOG4J_FORMAT_MSG_NO_LOOKUPS=true \
        java \
        -cp apache-log4j-2.10.0-bin/log4j-api-2.10.0.jar:apache-log4j-2.10.0-bin/log4j-core-2.10.0.jar:. \
        Server
    curl -H 'X-Api-Version:${jndi:ldap://127.0.0.1:8081}' http://localhost:8080
    curl -H 'X-Api-Version:${java:version}' http://localhost:8080
    

    Teste uma versão não vulnerável do log4j:

    root@kitploit:~
    java \
        -cp apache-log4j-2.16.0-bin/log4j-api-2.16.0.jar:apache-log4j-2.16.0-bin/log4j-core-2.16.0.jar:. \
        Server
    curl -H 'X-Api-Version:${jndi:ldap://127.0.0.1:8081}' http://localhost:8080
    curl -H 'X-Api-Version:${java:version}' http://localhost:8080
    

    Teste o grype para verificar se ele detecta a vulnerabilidade:

    root@kitploit:~
    wget https://github.com/anchore/grype/releases/download/v0.27.2/grype_0.27.2_linux_amd64.tar.gz
    tar xf grype_0.27.2_linux_amd64.tar.gz grype
    ./grype dir:.
    

    Teste o trivy para verificar se ele detecta a vulnerabilidade:

    root@kitploit:~
    wget https://github.com/aquasecurity/trivy/releases/download/v0.21.2/trivy_0.21.2_Linux-64bit.tar.gz
    tar xf trivy_0.21.2_Linux-64bit.tar.gz trivy
    ./trivy fs --security-checks vuln .
    

    Referências

    • https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/
    • https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/
    • https://logging.apache.org/log4j/2.x/security.html
    • https://logging.apache.org/log4j/2.x/manual/lookups.html#JndiLookup
    Baixar ferramenta