The Log4j vulnerability and its potential impacts

There are also a few other factors adding up to the perfect storm.

1. The log4j library is used by a large number of software for logging events. This makes a large number of organizations vulnerable.

2. Logging is used in many different applications and situations. Thus, the attack can be initiated in many ways. 

3. It is very easy to exploit. It just takes a simple string in a request or a message that will be logged in order to initiate the attack. It works every time, it does not require the user to click on links or misconfigure the system, and it does not require access to any internal systems.

First detection 

Though the vulnerability, denoted CVE-2021-44228, was first disclosed on December 9, there are reports that it has been exploited at least since December 1. However, once disclosed, attacks increased dramatically.

The vulnerability took advantage of the Java Naming and Directory Interface (JNDI) and LDAP requests through this interface. Using JNDI, it was possible to make an LDAP request to retrieve and execute a malicious file which would then be executed on the system.

Impacts of the second vulnerability

The fix is to update to the patched 2.15.0 version, which was released already on the morning of December 10. This version removed the possibility to perform the remote code execution attack. This was achieved by restricting the LDAP lookups to localhost by default. 

Still, it was soon realized that there was still an opportunity to perform a Denial-of-Service attack on certain configurations that used the 2.15.0 version. This was reported as CVE-2021-45046 on December 14. Following the disclosure of this vulnerability, a new version of the library was released, 2.16.0. This new version will disable JNDI functionality by default so that it can not be used in an attack.

Debricked’s fix recommendations

This new vulnerability is nowhere close to being as significant as the original vulnerability. First, it only applies to certain configurations, and second, it “only” allows a DOS-attack to be mounted on the vulnerable systems. Still, we think that there are reasons to immediately patch systems with the 2.16.0 version of log4j. 

The new vulnerability should not be treated as any other low-impact vulnerability. The attention given to the original vulnerability has really put log4j on the map of libraries to keep an eye on. Exploits developed for CVE-2021-44228 can easily be modified to also exploit the new CVE-2021-45046. 

In conclusion, we think that this vulnerability might also see more exploit attempts than similar vulnerabilities since log4j has the attention of the world right now.

A great way to sleep a bit better at night is using Debricked. You’ll be alerted when a new vulnerability is introduced (if you’ve set up automation rules for it) and get advice on how to fix it. Fewer nightmares about exploits, more time to focus on other things. Create a free account here.

Update Dec 18: It has been shown that the protection offered by 2.15.0 does not restrict the CVE-2021-45046 vulnerability to only a DoS attack. As analysis of the vulnerabilities and log4j are evolving, it seems that more severe impact in the form of DNS exfiltration and remote code execution is possible. Apache subsequently changed the CVSS score from 3.7 to 9.0 for this vulnerability. Due to this, upgrading from 2.15.0 is essential. 

Moreover, the 2.16.0 version that disables JNDI altogether has been shown to be vulnerable to yet another attack, that due to infinite recursion can lead to a DoS attack. This vulnerability is identified as CVE-2021-45105 and has been patched in the 2.17.0 release on Dec 18. Anyone that uses Debricked can rest assured that we have you covered. Our tool will both identify and help remediate all these vulnerabilities as soon as they are discovered and published.

Update Dec 28: Yet another vulnerability has been found. It affects the previous 2.17.0 version, and also previous versions and has the identifier CVE-2021-44832. As with the original attack, there is a possibility for remote code execution. However, for the attack to be successful, the adversary must be able to modify the logging configuration file. Thus, it is not as severe as the original attack. Debricked has identified and provided the remediation to update to the 2.17.1 version of the library.