Log4j_Vulnerability_Demo

A simple program to demonstrate how Log4j vulnerability can be exploited ( CVE-2021-44228 )

Running the Demo :

To start the program, simply run the start.sh ( on UNIX systems ) or start.bat on Windows.

User input will be read and logged to console using the Log4j framework.

By default, the logging messages generated by the Log4j library do not provide any server unreachable / host not found errors for the JNDI substitutions. ( And I guess that's also a major reason why this vulnerability can be exploited with stealth )

Also try to use subdomains, like ${jndi:ldap://test29.google.com/blah} , sometimes the JNDI call will wait for the response from the remote server and that's why program looks like its stuck while it has actually made a connection attempt in the background. If you use subdomains which don't exist, JNDI call will quickly terminate after making a connection attempt and the program will continue.

I recommend you to run the program in one shell, and run the " tcpdump -i any | grep google " command on another shell in parallel and then provide inputs to the program to see whether the program has made a connection attempt.

Log4j substitutions in action :

Attempting Remote Connections:

Some sample inputs :

testing ( Normal String )

Examples which can be more than just a log message :

${env:USER} ( UNIX )

${env:USERNAME} ( Windows )

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

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

--

Monitoring :

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

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

--

Removing the JndiLookup Class to mitigate the vulnerability :

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

This will delete the JndiLookup.class from the Log4j core Jar.

Run the same program after the above step, the program shouldn't make any connection attempts / JNDI substitutions.

--

Another way of disabling JNDI Lookups

export LOG4J_FORMAT_MSG_NO_LOOKUPS=true

This environment variable will disable the JNDI lookups for the current session.