Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
log4j-log4shell-playground — Un terrain de jeu pour explorer les atténuations de la vulnérabilité Log4Shell (CVE-2021-44228) | Kitploit
Outils/GitHubGitHub/rgl/log4j-log4shell-playground
Analyse des VulnérabilitésExploitationExploitation d'Applications WebTests d'IntrusionApprentissage et ÉducationLabs et Pratique
GitHubrgl/log4j-log4shell-playground

log4j-log4shell-playground

Un terrain de jeu pour explorer les atténuations de la vulnérabilité Log4Shell (CVE-2021-44228)

Voir le dépôt
1il y a 4 ansPas encore vérifié

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

À propos

Un terrain de jeu pour explorer les atténuations de la vulnérabilité critique log4j (alias Log4Shell) (CVE-2021-44228).

Ce problème particulier réside dans la fonctionnalité JndiLookup et la capacité de log4j à interpréter TOUS les arguments d'un appel de journalisation.

Je m'attendrais à ce qu'il n'interprète que le message de format (le premier argument d'un appel de journalisation), par exemple, le Hello {} dans log.info("Hello {}", "${jndi:ldap://127.0.0.1:8081}"), mais il les interprète tous.

Les atténuations empêcheront log4j de déclencher les recherches jndi, mais elles autorisent toujours d'autres recherches comme ${java:version}.

NB : Depuis log4j 2.16.0 (LOG4J2-3211; diff), le message de format n'est plus interprété.

Cette vulnérabilité peut être déclenchée à distance lorsque l'application cible journalise des données fournies par l'utilisateur, par exemple, à partir de ces en-têtes HTTP courants :

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

    Construire :

    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
    

    Essayez une version vulnérable de 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
    

    Essayez de supprimer la classe JndiLookup de l'atténuation du classpath :

    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
    

    Essayez l'atténuation par variable d'environnement :

    NB Depuis le 2021-12-15 (aux alentours de la date de sortie de log4j 2.16.0 / CVE-2021-45046), ce n'est plus recommandé.

    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
    

    Essayez une version non vulnérable de 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
    

    Essayez grype pour voir s'il détecte la vulnérabilité :

    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:.
    

    Essayez trivy pour voir s'il détecte la vulnérabilité :

    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 .
    

    Références

    • 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
    Télécharger l’outil