Log4Shell Is the Biggest Threat Yet

The world is quaking since the disclosure of a zero-day vulnerability found in Apache's open-source library Log4j.

There are at least two reasons why this finding is a big deal. One is that Log4j is a logging tool used in potentially millions of Java-based applications. People normally use open-source libraries as software components because pre-written code is handier and faster than writing everything from scratch. Logging is a very important functionality to keep track of what happens in a given application. Log4j happens to be an extremely popular library to do that. However, lots of people may not even know they use it.

The other reason is that this actively exploited vulnerability enables attackers to trigger unexpected actions remotely. This known exploit is commonly referred to as remote code execution. As it poses a major security threat, this vulnerability, known as Log4Shell or CVE-2021-44228, has been rated critical with the highest possible CVSS score of 10.

Log4j2 versions up to and including 2.14.1 are vulnerable to Log4Shell. These versions have a lookup feature that is used for fetching resources, including accessing data and downloading stuff from websites or other Java-based applications. Since the beginning of this month, attackers have been exploiting this feature by logging a specially crafted string (i.e., a specific sequence of characters) into an interface that allows external input. When their malicious code is included in a log message, the attackers can get the application to execute various actions, like connecting to a remote server, performing data leakage or installing malware. For example, threat actors are recently exploiting Log4Shell to infect Windows devices with Dridex, a Trojan for stealing bank credentials. The attack chain is shown in Figure 1.

A myriad of well-known services is vulnerable to Log4Shell. To name a few: The security issue has been proven on the iCloud infrastructure by replacing an iPhone's name with the malicious string. It has also been discovered on Steam by only entering the malicious code in the search box. Even games are affected: Attackers could get their way in by typing the code in the chatbox in Minecraft Java Edition. The list goes on: Amazon Web Services, Okta, Cisco, etc.

This vulnerability asked for an urgent call to action. The Apache Software Foundation swiftly released Log4j version 2.15.0, where they disabled the message lookups feature by default. However, users of this version can still enable this feature in configuration. This gave way to another vulnerability, discovered on December 14. It is known as CVE-2021-45046 and is rated critical with a CVSS score of 9.

Version 2.15.0 still left paths where message lookups could occur. With the possibility to send the exploit code with the request, threat actors could leak information and execute code remotely in some environments and locally in all environments. So, Apache released version 2.16.0. Unfortunately, this version does not protect from uncontrolled recursion. That is, any attacker could make the application crash by entering malicious data that would cause excessive consumption of resources, such as allocated memory. This vulnerability, discovered on December 16, is known as CVE-2021-45105 and has a high severity rating with a CVSS of 7.5.

The risk of Denial of Service has already been addressed in the latest release, Log4j 2.17.0. For that, we have to thank Apache Software Foundation's efforts and security researchers that have worked inspecting every patch.

The global response to Log4Shell has been historical. Many organizations have already released their statements saying whether they are affected by it. Further, many vendors that use the open-source library have rushed to patch their products. Importantly, the US Cybersecurity & Infrastructure Security Agency (CISA) issued an emergency directive where it ordered federal agencies to update or apply mitigation measures (see Figure 1) by 5 p.m. EST on December 23.

Right now, identification and remediation are key. This may pose a problem for some. As we hinted in the beginning of this post, many organizations don't know they use programs with Log4j. This may be because they don't maintain inventories of their software's components and subcomponents. Additionally, the latest events may increase the activity of threat actors. As independent security researcher Chris Frohoff said, "What is almost certain is that for years people will be discovering the long tail of new vulnerable software as they think of new places to put exploit strings."

At Fluid Attacks we're prepared to overcome this challenge. Our clients using any of our Plans can immediately find out if they use Log4j in their software. On our platform, which makes vulnerability management smoother, they can look for the vulnerability type "011. Use of software with known vulnerabilities," under which any of Log4j's high to critical vulnerabilities should appear. What should people do then? Well, teams that have Log4j2 in their software should upgrade to version 2.17.0 or the latest version, should a newer version be released.

New vulnerabilities are being exploited daily. Want to learn how to be better prepared for these threats? Get a demo!