Last Update: December 28, 2021

If you are reading this, you likely have heard about Log4Shell, the December, 2021 critical zero-day remote-code execution vulnerability, and subsequent vulnerabilities in the popular Log4j software library that is developed and maintained by the Apache Software Foundation. Apache has patched these vulnerabilities in version 2.17.1, however vendors who use this library will need to patch their affected systems. Amit Yoran, CEO of the cybersecurity firm Tenable, called it “the single biggest, most critical vulnerability of the last decade” – and possibly the biggest in the history of modern computing. In addition to the remote-code execution capabilities of this vulnerability, one of the reasons this is so critical, is that Log4j is being used in systems all over the Internet that will not be updated automatically.

According to Matthew Prince, the CEO of cybersecurity company, Cloudflare, the earliest evidence of exploitation was on December 1, 2021, which was 9 days before the vulnerability was publicly disclosed but since the disclosure, the flaw is being widely exploited in the wild.

Which Versions of log4j are vulnerable?

• Versions up to and including 2.0-beta9 to 2.14.0 are vulnerable to CVE-2021-44228 (CVSS 10)

• Versions up to and including 2.15.0 is vulnerable to CVE-2021-45046 (CVSS 9.0)

• Versions up to and including 2.16.0 is vulnerable to CVE-2021-45105 (CVSS 7.5)

• Versions up to and including 2.17.0 are vulnerable to CVE-2021-44832 (CVSS 6.6)

Version 2.15.0 was released to patch the vulnerability but according to the Apache Software Foundation, “…the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations” so they issued CVE-2021-45046 and released version 2.16.0.

Version 2.16.0 was originally rated as low severity CVSS 3.7 but this has been changed to a critical severity 9.0 score when it was shown that an attacker could abuse the vulnerability and execute code remotely.

Version 2.17.0 was released on Friday December 18 to patch a vulnerability in all previous versions of Log4j 2, which “…did not protect from uncontrolled recursion from self-referral lookups.” according to Apache.

Version 2.17.1 was released to patch a remote code execution vulnerability in all versions prior to and including 2.17.0. However, as of this writing, it seems that an attacker would need permission to modify the logging configuration file, so install this patch when you can.

NOTE: If you are running any version up to and including 2.16.0, upgrade to at least version 2.17.0 of Log4j as soon as possible and since you’re upgrading, you should probably just go right to 2.17.1.

As of the writing of this blog, there is no evidence that version 1 of Log4j is vulnerable to these CVEs, but running old, outdated software is not recommended so if you are using version 1, you should consider upgrading to at least version 2.17.0 of Log4j.

How The Attack Works and How to Defend Against It

In simple terms, an attacker can enter a specially crafted string into the input field of a java-hosted application that will be passed on to Log4j and executed, resulting in a system takeover.

It’s actually a little more complicated than that, so to show how this attack could be implemented, and prevented, here is a brief overview of a blog that was written by the Swiss Government Computer Emergency Response Team (CERT).

Stage 1

• Attack: An attacker inserts a JNDI lookup in the header field of an input that is likely to be logged

• Defense: Block with a Web Application Firewall (WAF)

Stage 2