rgl/log4j-log4shell-playgroundEin Spielplatz zum Experimentieren mit den Gegenmaßnahmen für die Log4Shell-Sicherheitslücke (CVE-2021-44228)
Eine Spielwiese zum Herumprobieren an den Gegenmaßnahmen für die kritische log4j-Schwachstelle (auch bekannt als Log4Shell) (CVE-2021-44228).
Dieses spezielle Problem liegt in der JndiLookup-Funktion und der Fähigkeit von log4j, ALLE Argumente eines Logging-Aufrufs zu interpretieren.
Ich würde erwarten, dass nur die Format-Nachricht interpretiert wird (das erste Argument eines Logging-Aufrufs), z. B. das Hello {} in log.info("Hello {}", "${jndi:ldap://127.0.0.1:8081}"), aber es interpretiert alle.
Die Gegenmaßnahmen verhindern, dass log4j die jndi-Lookups auslöst, erlauben aber weiterhin andere Lookups wie ${java:version}.
Hinweis: Seit log4j 2.16.0 (LOG4J2-3211; diff) wird die Format-Nachricht nicht mehr interpretiert.
Diese Schwachstelle kann remote ausgelöst werden, wenn die Zielanwendung beliebige vom Benutzer bereitgestellte Daten protokolliert, zum Beispiel aus diesen gängigen HTTP-Headern:
AcceptCookieLocationOriginRefererUser-AgentX-Api-VersionX-Forwarded-ForX-Forwarded-HostX-Requested-WithErstellen:
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
Probieren Sie eine verwundbare log4j-Version aus:
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
Probieren Sie die Gegenmaßnahme aus, bei der die JndiLookup-Klasse aus dem Klassenpfad entfernt wird:
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
Probieren Sie die Gegenmaßnahme über die Umgebungsvariable aus:
Hinweis: Seit 2021-12-15 (ungefähr dem Veröffentlichungsdatum von log4j 2.16.0 / CVE-2021-45046) wird dies nicht mehr empfohlen.
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
Probieren Sie eine nicht verwundbare log4j-Version aus:
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
Probieren Sie grype aus, um zu sehen, ob es die Schwachstelle erkennt:
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:.
Probieren Sie trivy aus, um zu sehen, ob es die Schwachstelle erkennt:
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 .