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 response to a feature request in 2013, only recently have we observed widespread exploitation, with high profile organizations and applications finding themselves exposed. 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:
- Client-server web applications are public facing, think of any website or application with which you interact. Log4j is not limited to just these servers, either.
- Logging is ubiquitous in these applications. There are security, compliance, functional, and business reasons to log as much data as possible — from login attempts and chat logs, to information that allows organizations to create targeted advertising content.
- The exploit requires no pre-requisites and is simple. It can be exploited with a single request — e.g. a post in a chat log or name change of an iPhone — as long as the server is accessible and running a vulnerable version.
- Log4j is open source, meaning any developer can simply grab and integrate it into their program, and an attacker can easily review the source code.
- Log4j has a built-in feature which causes the logging module to reach out externally — pulling additional data onto the machine — granting attackers full control.
- The vulnerable server profile is ideal for granting attackers a foothold to move deeper into a network through techniques like worming.
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. Like an ant who discovered a sugar container and it’s so sweet it attracts the whole colony, as well as heavy scrutiny.
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.
Log4j Timeline
CVE stands for Common Vulnerabilities and Exposures. A vulnerability or exposure that exists in a system or software that can be exploited.
The original Log4j CVE-2021-44228 was announced on the December 10, 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. It is very noisy, but also an extremely quick path to expose vulnerable machines.
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. Good security means anticipating and catching the inevitable derivatives. Alert Logic have seen numerous evasions — in string and protocol — some of which have been documented in this blog and we continue to anticipate more.
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.
Log 4j: 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. We have discussed the vulnerabilities that the security community is currently aware of, however it is possible that there may be more being kept underground. Therefore, the safest patch is one that disables the vulnerable function entirely.
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.
Fortra’s Alert Logic will continue to remain vigilant and ensure that our customer base is covered, wherever Log4j takes us next.
