log4shell

December 14, 2021 Chuck Davis

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

Image from Swiss Government Computer Emergency Response Team https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/

Attack: The JNDI string is passed to Log4j for logging
Defense: Disable or patch Log4j

Stage 3

Attack: Log4j interpolates the string and queries the malicious LDAP server
Defense: Disable JNDI lookups

Stage 4

Attack: The LDAP server responds with directory information that contains the malicious Java class
Defense: None

Stage 5

Attack: Java deserializes (or downloads) the malicious Java class and executes it
Defense: Disable remote codebases

For a more in-depth dive, this Naked Security blog provides a great technical walk-through of the the exploit and how to mitigate a vulnerable system.

This is the type of vulnerability that will take months or years to effectively mitigate across the Internet. To stay informed and follow the latest developments, you can reference the CISA Log4j Guide or review the additional references at the end of this blog.

If you are testing systems to see if they are vulnerable, Huntress Labs created a Log4Shell vulnerability testing page. This won’t execute code but still be sure you have permission to test your target system.

Call for SBOM

The past four days have been very busy for IT Security and IT teams around the world. Part of the problem with responding quickly is that most organizations have a poor inventory of the systems and software that exist in their enterprise. Even organizations who are good at keeping inventory will likely struggle to manage this vulnerability because so many of the products and services that we use are made up of a combination of open source and proprietary software but vendors tend not to reveal the code that they use. If vendors were required to share a Software Bill of Materials (SBOM), then organizations would be able to take a quick inventory of the software that runs in, and supports, their enterprise and make quick risk assessments to determine what is vulnerable and how to mitigate the risks.

While SBOMs are not widely available and used today, there are efforts to move in this direction. Earlier this year, President Biden signed an executive order that called for the U.S. government to publish minimum elements for an SBOM. You can learn more about this effort from the National Telecommunications and Information Administration’s (NTIA) SBOM site. Additionally, CISA is hosting a 2-day webinar called SBOM-A-RAMA on December 15th and 16th, 2021.

References:

Change Log

December 28,2021 Added CVE-2021-44832
December 22, 2021: Added link to CISA log4j scanning tool
December 20, 2021: Added CISA Log4j Affected Product Database
December 18, 2021: Added information about CVE-2021-45105 and link to The Hacker News article covering the CVE
December 17, 2021: Added link to the check-log4j script
December 16, 2021 - Added information about CVE-2021-450446, added links to BleepingComputer and SecuirtyWeek
December 15, 2021 - Added Log4Shell Repo link and Huntress Labs Log4Shell testing page