Log4j: The Evolution of Vulnerabilities to CVE-2021-45046 and What to Expect in 2022

This blog was originally published by Alert Logic here.

Written by Josh Davies, Alert Logic.

Threat Overview

The internet has been alive with talk of Log4Shell (CVE-2021-44228), and for good reason.

While the bug appears to have been introduced in 2013, only recently have we observed widespread exploitation. The vulnerability lies within the Apache open source Log4j library, commonly copied and pasted by developers into their Java based applications.

Java is a massively popular programming language, with ~9 million Java programmers globally and is commonly used for client-server web applications. The Log4j vulnerability is concerning for several reasons:

1. Client-server web applications are public facing.
2. Data logging is ubiquitous in these applications.
3. The exploit requires no pre-requisites and can be exploited with a single request, as long as the server is accessible and running a vulnerable version.
4. Log4j is open source.
5. Log4j has a built-in feature which causes the logging module to reach out externally — pulling additional data onto the machine — and grant attackers full control.

The ubiquity, severe impact, and ease of exploitation has resulted in an enhanced focus on flaws within the Log4j logging module, and new attack strings and vulnerabilities are being discovered regularly.

Let us now explore the initial Log4Shell CVE-2021-44228 through to the more recent evolution of CVE-2021-45046 while digging into the issue of derivates and the significance of the new and distinct CVE.

Timeline

The original Log4j CVE-2021-44228 was announced on December 10th, 2021, and dubbed Log4Shell, which allows for remote code execution (RCE), without any pre-requisites such as authentication. The ease of which this can be exploited, and the impact if exploited, earned this CVE a 10/10 severity rating.

An initial proof of concept (PoC) was made public. The PoC string was simply copied by many, as attackers sent it to any publicly available machine, a technique commonly referred to as spray and pray.

For defenders, this is the easiest attack string to detect. It is known by both parties and a simple detection rule can capture/block these attempts.

Derivatives of the initial PoC string quickly appear. These are also referred to as evasions, as the attackers add to, or tweak the initial exploit code to bypass prevention and detection technologies.

This results in something that looks superficially different but causes the vulnerable system to behave in the same way.

Consider a simple block rule that caught the exact PoC string. This is enough for a vendor to say they have Log4j coverage, but the derivatives/evasions will not trigger this rule — exploiting the vulnerable machine. Therefore, security cannot be seen as a tick box exercise.

Another result of the widespread opportunity and focus of first Log4j vulnerability has been the discovery of a new and distinct vulnerability. With more attention on the Log4j library, security researchers have been inspecting the source code of this project with concerning results.

On December 14th, 2021, a second CVE relating involving Log4j was officially announced, CVE-2021-45046, which was initially believed to allow only for a denial of service (DoS) attack. The DoS attack sets a vulnerable machine off on an endless loop that uses up resources and can overwhelm the machine — preventing it for servicing usual requests.

When discovered, most users should have already upgraded Log4j to 2.15.0, as 2.15.0 was released to address the initial Log4Shell RCE vulnerability. 2.15.0 was intended to mitigate RCE by limiting external connections in a message lookup, therefore DoS was the most impactful product of the new exploit. The exploit was minor, so it was initially graded at 3.6/10 severity. However, it was recently discovered that you can bypass the mechanism the 2.15.0 patch put in place to limit external connections, meaning the new vulnerability also allows for full remote code execution. As a result, CVE-2021-45046 was upgraded to a 9/10 severity.

2.16 was then released to address the above issue but interestingly a new DoS has been found in 2.16.0, prompting the release of 2.17.0. This may not be the end of this story!

The Difference Between a Derivative and A New Vulnerability

While it is understandable to see how the new exploit could be interpreted as a derivative of the initial Log4Shell CVE-2021-44228, this new vulnerability was found in patch 2.15.0, the one intended to address CVE-2021-44228.

2.15.0 made it more difficult to trigger the malicious RCE, as additional steps are required to bypass the network host restrictions. This made it distinct enough to be considered a new vulnerability, as it required additional steps to exploit, and it targeted a newer version of Log4j. The extra step also explains why the newer vulnerability received a severity rating of 9 versus its predecessor’s maximum 10/10 rating.

How Does this Happen?

As discussed, derivatives are created to evade detection and prevention technologies.

New vulnerabilities are discovered through the increased focus on the code that allowed for the initial vulnerability, spurred on by severity of the exploit and ubiquity of the Log4j library. Widespread vulnerabilities bring all eyes onto the vulnerable product.

In a very short time span we have moved through patch 2.15.0, 2.16.0 to 2.17.0. Apache needed to move quickly to address the initial vulnerability and the need to move quickly can often cause mistakes.

At the very least, 2.16.0 was able to buy users of the library time as attackers had to adjust their previous techniques to bypass the new mitigations, even if they did not completely protect against exploitation.

Next Steps

It is strongly recommended that any instances of Log4j are updated to the latest stable version: 2.17.0, even if you have previously updated for 2.15.0 or 2.16.0 to mitigate against the new bypasses. We do not anticipate this is the end of the Log4j saga.

Even once patched, continuous monitoring of all critical assets is essential.

New derivatives and CVEs aside, we have already observed a land grab of vulnerable servers and it is entirely likely that attackers have imbedded dormant zombie code to allow them backdoor access even to patched servers.

Be vigilant. Attackers may be biding their time, waiting for the focus to shift elsewhere before carrying out their actions on objectives. Equally, those with unauthorized access may be seeking to join forces with post compromise specialists, such as ransomware-as-a-service actors who specialize in extorting ransoms from organizations.

There are many opportunities for defenders to identify compromise early and disrupt the attack sequence and limit the impact. While some of the techniques and derivatives discussed are new, there are still ways to identify novel attacks and attackers will usually need to rely on other, known techniques, before they can reach their ultimate goal.

About the Author

Josh Davies is a Product Manager at Alert Logic. Formerly a Security Analyst and Solutions Architect, Josh has tremendous experience working with mid-market and enterprise organizations; conducting incident response and threat hunting activities as an analyst before working with organizations to identify appropriate security solutions for challenges across cloud, on-premises and hybrid environments.