# LOG4SHELL-CVE-2021-44228-Validator

[![Basic test](](

[![Extended test](](

## About
This tool allows you to verify whether a simple Java web app is vulnerable to CVE-2021-44228 for a user provided version of Java and of Log4J2. You can also provide optionally a custom mitigation.
The simulation lab spun up by `` using docker-compose simulates exploiting the log4j vulnerability and gaining RCE on the vulnerable machine.

## The way it works

First of all, some docker images need to be built first. The `./` script should take care of that.

Ths simulation is done in the following way:
- First a simple Java web application is spun up on a container on port 8080. When this application receives GET calls on `/2021-44228-via-message` it always logs the User-Agent header field.
- A Fake LDAP server is spun up using this [](tool) on a separate container on port 1389. (This container will forward received requests to the Nginx server)
- A Nginx web server is spun up on port 8888, this container hosts the compiled .class file we want to run on our vulnerable app.
- A simple curl container is started, this one runs the `./` script which sends a payload to the vulnerable app.

## Instructions

- Make sure python, docker, docker-compose and maven are available locally.
- Build the marshalsec jar file by running: `cd marshalsec/ ;mvn clean package -DskipTests ;cd -`
- Run `./`
- Run `python  --java-version 8 --log4j-version 2.12.1`

## Usage examples

- Python wrapper help text:
~/workspace/CVE-2021-44228-playground$ python --help
usage: [-h] [--java-version JAVA_VERSION] --log4j-version LOG4J_VERSION [--no-cleanup] [--disable-trust-url] [--remove-jndi-lookup-class] [--disable-message-lookup] [--debug]


optional arguments:
  -h, --help            show this help message and exit
  --java-version JAVA_VERSION
                        version of java to be used
  --log4j-version LOG4J_VERSION
                        version of log4j to be used
  --no-cleanup          Don't delete used containers.
  --disable-trust-url   Disable the LDAP trustURLCodebase setting on the victim app
                        Remove the JNDI Lookup class from the log4j jar file
                        Disable the JNDI message lookup in the victim app's JVM
  --debug               Display all container's logs
                        By sending the payload to an HTTP handler which makes use of Custom logging with ThreadContext, attempt to bypass the no-message-lookup mitigation
## Available features:

This validator has been tested with several combinations of Java7/8 and different versions of Log4J2, for more examples please see the extended tests pipeline in the github actions tab.

For now, the following mitigations have been implemented:
- Disabling trustURLCodebase for LDAP by setting the propery 1com.sun.jndi.ldap.object.trustURLCodebase` to False.
- Removing JNDILookup.class file from the log4j jar file.
- Disabling message lookup by providing the following flag to the JVM: `-Dlog4j2.formatMsgNoLookups=True`

In addition to that, a new flag has been added to test an exploitation vector which can bypass disabling message lookups: `--exploit-via-thread-context`

## Disclaimer

This software has been created purely for the purposes of research and for the development of effective mitigation techniques, and is not intended to be used to attack systems except where explicitly authorized. Project maintainers are not responsible or liable for misuse of the software. Use responsibly.