Skip to content

Latest commit

 

History

History
71 lines (51 loc) · 4.25 KB

README.md

File metadata and controls

71 lines (51 loc) · 4.25 KB
Raw

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 Log4J. You can also [optionally] apply one of a view pre-defined mitigations. The simulation lab spun up by log4shell_validator.py uses docker-compose to simulate 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. The ./build_images.sh script should take care of that.

Ths attack 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. The code for this application is available under ./poc_template
  • A Fake LDAP server is spun up using marshalsec on a separate container on port 1389. (This container will forward received LDAP 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 ./exploit.sh 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 ./build-images.sh
  • Run python log4shell_validator.py --java-version 8 --log4j-version 2.12.1

Usage examples

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

log4j-vulnerability-tester

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-jndi-lookup-class
                        Remove the JNDI Lookup class from the log4j jar file
  --disable-message-lookup
                        Disable the JNDI message lookup in the victim app's JVM
  --debug               Display all container's logs
  --exploit-via-thread-context
                        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.