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_Vulnerability_Demo — Un programme simple pour démontrer comment la vulnérabilité Log4j peut être exploitée ( CVE-2021-44228 ) | Kitploit
Outils/GitHubGitHub/chandanshastri/log4j_vulnerability_demo
Analyse des VulnérabilitésExploitationSécurité WebApprentissage et ÉducationAnalyse de Journaux
GitHubchandanshastri/log4j_vulnerability_demo

Log4j_Vulnerability_Demo

Un programme simple pour démontrer comment la vulnérabilité Log4j peut être exploitée ( CVE-2021-44228 )

Voir le dépôt
3il 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

Démo de la vulnérabilité Log4j

Un programme simple pour démontrer comment la vulnérabilité Log4j peut être exploitée ( CVE-2021-44228 )

Exécution de la démo :

Pour démarrer le programme, exécutez simplement start.sh ( sur les systèmes UNIX ) ou start.bat sur Windows.

La saisie de l'utilisateur sera lue et journalisée dans la console à l'aide du framework Log4j.

Par défaut, les messages de journalisation générés par la bibliothèque Log4j ne fournissent aucune erreur de serveur injoignable / hôte introuvable pour les substitutions JNDI. ( Et je suppose que c'est aussi une raison majeure pour laquelle cette vulnérabilité peut être exploitée discrètement )

Essayez également d'utiliser des sous-domaines, comme ${jndi:ldap://test29.google.com/blah} , parfois l'appel JNDI attendra la réponse du serveur distant et c'est pourquoi le programme semble bloqué alors qu'il a en réalité effectué une tentative de connexion en arrière-plan. Si vous utilisez des sous-domaines qui n'existent pas, l'appel JNDI se terminera rapidement après avoir effectué une tentative de connexion et le programme continuera.

Je vous recommande d'exécuter le programme dans un terminal, et d'exécuter la commande " tcpdump -i any | grep google " dans un autre terminal en parallèle, puis de fournir des entrées au programme pour voir si le programme a effectué une tentative de connexion.

Substitutions Log4j en action :

image

Tentatives de connexions distantes :

image

image

Quelques exemples de saisie :

testing ( Chaîne normale )

Exemples qui peuvent être plus qu'un simple message de journal :

${env:USER} ( UNIX )

${env:USERNAME} ( Windows )

${jndi:ldap://test.java.net}

${jndi:ldap://localhost:12000}

--

Surveillance :

tcpdump -i any | grep -i "java.net"

ncat -k -vv -c "echo hi" -l 12000

--

Suppression de la classe JndiLookup pour atténuer la vulnérabilité :

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Cela supprimera JndiLookup.class du jar principal Log4j.

Exécutez le même programme après l'étape ci-dessus, le programme ne devrait effectuer aucune tentative de connexion / substitution JNDI.

--

Une autre façon de désactiver les recherches JNDI

export LOG4J_FORMAT_MSG_NO_LOOKUPS=true

Cette variable d'environnement désactivera les recherches JNDI pour la session en cours.
Télécharger l’outil