Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
Tools/GitHubGitHub/chandanshastri/log4j_vulnerability_demo
SchwachstellenanalyseExploitationWebsicherheitLernen & BildungLog-Analyse
GitHubchandanshastri/log4j_vulnerability_demo

Log4j_Vulnerability_Demo

Ein einfaches Programm zur Demonstration, wie die Log4j-Schwachstelle ausgenutzt werden kann ( CVE-2021-44228 )

Repository anzeigen
3vor 4 JahrenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

Log4j_Vulnerability_Demo

Ein einfaches Programm zur Demonstration, wie die Log4j-Schwachstelle ausgenutzt werden kann ( CVE-2021-44228 )

Ausführen der Demo :

Um das Programm zu starten, führen Sie einfach start.sh ( auf UNIX-Systemen ) oder start.bat unter Windows aus.

Die Benutzereingabe wird gelesen und mithilfe des Log4j-Frameworks in der Konsole protokolliert.

Standardmäßig liefern die vom Log4j-Framework generierten Protokollmeldungen keine Server-nicht-erreichbar- bzw. Host-nicht-gefunden-Fehler für die JNDI-Ersetzungen. ( Und ich vermute, das ist auch ein Hauptgrund, warum diese Schwachstelle heimlich ausgenutzt werden kann )

Versuchen Sie auch, Subdomains zu verwenden, wie ${jndi:ldap://test29.google.com/blah} ; manchmal wartet der JNDI-Aufruf auf die Antwort des entfernten Servers, und deshalb sieht es so aus, als ob das Programm hängt, während es im Hintergrund tatsächlich einen Verbindungsversuch unternommen hat. Wenn Sie Subdomains verwenden, die nicht existieren, wird der JNDI-Aufruf nach einem Verbindungsversuch schnell beendet und das Programm läuft weiter.

Ich empfehle Ihnen, das Programm in einer Shell auszuführen und parallel dazu in einer anderen Shell den Befehl " tcpdump -i any | grep google " auszuführen und dann Eingaben an das Programm zu übergeben, um zu sehen, ob das Programm einen Verbindungsversuch unternommen hat.

Log4j-Ersetzungen in Aktion :

image

Versuch von Remote-Verbindungen:

image

image

Einige Beispieleingaben :

testing ( Normaler String )

Beispiele, die mehr als nur eine Protokollmeldung sein können :

${env:USER} ( UNIX )

${env:USERNAME} ( Windows )

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

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

--

Überwachung :

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

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

--

Entfernen der JndiLookup-Klasse zur Abschwächung der Schwachstelle :

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

Dadurch wird die JndiLookup.class aus dem Log4j-Core-Jar gelöscht.

Führen Sie das gleiche Programm nach dem obigen Schritt aus; das Programm sollte keine Verbindungsversuche / JNDI-Ersetzungen mehr unternehmen.

--

Eine weitere Möglichkeit, JNDI-Lookups zu deaktivieren

export LOG4J_FORMAT_MSG_NO_LOOKUPS=true

Diese Umgebungsvariable deaktiviert die JNDI-Lookups für die aktuelle Sitzung.
Tool herunterladen