The Log4Shell Vulnerability

2023-11-26
5 minutes

Introduction

Log4Shell refers to a software weakness found in Apache Log4j 2, a widely used Java library used to log error messages in software applications. This vulnerability, identified as CVE-2021-44228, allows a malicious remote attacker to gain control over an internet-connected device running specific versions of Log4j 2.

A researcher from the Alibaba Cloud team reported the vulnerability on November 24, 2021, and Apache publicly disclosed it on December 9, 2021. This is a significant problem because it affects an extensive range of devices, numbering in the hundreds of millions.

This vulnerability can be abused by attackers through text messages to remotely manipulate a computer. Due to the ease with which it can be exploited, this vulnerability has been given the highest possible severity score(10/10).

Part 1: Understanding the Vulnerability

a. Log4Shell Mechanism

Log4j2 comes with a built-in feature called 'Message Lookup Substitution.' This functionality allows specific strings to be swapped, during the logging process, with dynamically generated strings.

The vulnerability arises from a feature called JNDI (Java Naming and Directory Interface) lookup, which allows Log4j configurations to reference external resources like LDAP servers, this feature allows a designated Java class to be retrieved from a remote location and deserialized, thus executing part of the class code. In this way, the attacker can obtain remote code execution on the application.

Here’s a schema which shows the attack flow of Log4shell using an LDAP server:

source

Step-by-step explication :

The attacker scans the Internet looking for exposed Log4j vulnerable applications.
The attacker sends the crafted log entry to the target application's log system via a web form or API request
When the target application logs the malicious entry, Apache Log4j 2 parses the log entry and processes it, If the Log4j version is vulnerable and the payload is successful, Log4j will query the remote LDAP server (or another resource specified in the payload).
The LDAP server will respond to the query with a malicious payload containing a malicious Java class.
The victim's server will download and execute the malicious payload, and the attacker will, for example, have a remote shell on the victim's server.

If you want to have deeper insights on the Log4shell attack, or even execute the attack yourself, the platform TryHackMe has a very good room called: ‘Solar, exploiting log4j’. In this room, you will find a more in-depth explanation on how and why the attack works including a detailed Proof of Concept. Using the TryHackMe AttackBox, you further can get hands-on experience by following the attack step-by-step before learning how to remediate the Log4shell vulnerability.

b. Potential Impacts

Log4shell has had a huge impact on organizations worldwide, this is because once the vulnerability has been exploited, it allows the attacker complete remote access and control over the device. A successful Log4shell attack may have multiple impacts on an organization, such as:

Data exfiltration: An event where an attacker can use a vulnerability to steal sensitive data from affected devices.
Financial consequences: According to the Atatus article 'Understanding Log4Shell: An Ultimate Guide to Protecting Your System,' remediating a single Log4Shell attack can result in substantial financial burdens, estimated at approximately $33,000, covering both direct and indirect expenses related to incident response and forensics.
System Compromise: This event can lead to the complete compromise of systems and networks, making them vulnerable to further attacks and exploitation.
Reputational damage: Public knowledge of a security breach or successful exploitation of a vulnerability can damage an organization’s reputation, leading to a loss of customer trust and, consequently, a drop in revenue.

Part 2: Reaction and Solutions

c. Community Response

The response from the community to the Log4Shell vulnerability has been swift and intense. Security experts, software developers and organizations around the world acted quickly to tackle the problem, recognizing its critical importance.

Indeed, the Log4shell vulnerability was considered extremely serious due to the ease with which an attacker can gain remote access on the victim’s host. So, security experts recognized the urgent need to assess their systems and take action to mitigate the risk and reduce the potential impact that the vulnerability can have, as we have seen previously.

There was also a widespread awareness of this vulnerability because security researchers and organizations shared a lot of information about the vulnerability through blogs, social media, and articles.

For example, some members of the cyber community have created a GitHub repository where they list affected components, apps and vendors

(https://github.com/authomize/log4j-log4shell-affected) to help people stay informed.

Collaboration was a key factor in defending against the Log4shell vulnerability. Security experts, researchers and vendors came together to identify affected systems, develop tools and patches as well as other mitigation actions to keep their systems secure from the Log4shell attack.

d. Detection & Mitigation

The first step is to detect hosts vulnerable to the Log4Shell attack in your environment. You need to determine where Log4j is used in your software applications and whether the versions in use are vulnerable.

For the detection, you can use YARA rules. These rules enable you to scan files, network traffic, and system logs for distinct patterns and signatures associated with Log4Shell exploitation attempts. By identifying these indicators, security teams can promptly detect potential Log4Shell attacks and take immediate action to mitigate them.

You can find a YARA rule that can be used to detect Log4shell exploitation attempt here.

If you have some potentially affected assets, you need to isolate them from the network and revise them thoroughly. According to cisa.gov these are all the steps to follow:

Physically removing the asset from the network (e.g., unplug the network cable);
Moving the asset to a “jail VLAN” with heightened monitoring and security;
Blocking at the network layer (a switch or some other device);
Implementing a firewall (including web application firewall) with strict port control and logging; or
Restricting the asset’s communication, especially to the internet and the rest of the enterprise network.

All versions of the Log4j library up to and including 2.16.0 are vulnerable, so it is highly recommended to upgrade to version 2.17.0 or higher.

If you can’t update to a secure version immediately, you should replace the Log4j library with an alternative logging library. As we have seen before the JNDI is the vulnerable feature used by attackers, so alternatively you can disable the JNDI in your Log4j configuration by modifying your log4j2.xml or the log4j2.properties file just as shown below.

<Configuration>

<Properties>

<Property name="log4j2.formatMsgNoLookups">true</Property>

</Properties>

</Configuration>

To further mitigate the issue, you can also set up a Firewall rule to limit access to Log4j servers and services from untrusted networks. You can for example, whitelist specific IP addresses or IP ranges that are known and trusted to access Log4j services and block all attempts from unauthorized sources.

Furthermore, you can hunt for signs of compromise on your network, if you find any affected devices you must initiate an Incident Response procedure to mitigate the issue.

Conclusion

In conclusion, the Log4Shell vulnerability, also known as CVE-2021-44228, has emerged as a critical cybersecurity concern. A small flaw in the Apache Log4j 2 library ultimately allows attackers to remotely execute code on millions of potential devices. Due to the ease of its exploitation and the resulting severity rating of 10/10, the Log4j vulnerability demanded immediate attention.

We have seen that the vulnerability originates from Log4j's 'Message Lookup Substitution' and the Java Naming and Directory Interface (JNDI) functionalities, granting attackers the ability to exploit systems through text messages and execute remote code. This vulnerability can have serious consequences like financial loss, data breaches, system compromises, and reputation damage.

The cybersecurity community responded swiftly to the vulnerability, collaborating to assess risks, develop patches, and share information through articles amongst other sources.

Finally, we have seen detection and mitigation steps, like detecting and isolating vulnerable assets, applying updates/patches, disabling JNDI features, and implementing firewall rules to secure systems at risk against this vulnerability.

References

The author

Rayan Annabi
SOC Analyst L1 at Senthorus
Bachelor graduate in Internet and communicating systems