In early December 2021, a critical remote code execution (RCE) vulnerability in Apache’s widely used Log4j Java library (CVE-2021-44228) was publicized. Shockwaves immediately rippled throughout the security community and beyond. Also known as Log4Shell, this zero-day vulnerability has impacted a wide swath of the Internet and many web applications. Successful exploitation of Log4j can allow a remote, unauthenticated attacker to take full control of a target system.
Log4j is a very common tool for sending text for storage into log files or databases. It is used in millions of applications and websites and affects nearly every organization all across the Internet. Log4j doesn’t just log plain strings; text strings formatted a certain way will be executed just like a line from a computer program allowing malicious actors to manipulate computers attached to the Internet. Cybercriminals can use this vulnerability to steal information, force unwanted actions or extort individuals or organizations.
The biggest concern is that it is easy to use the Log4j vulnerability for malicious purposes. The Log4j tool is designed to send whatever data is input into the right format, so if attackers know how to properly form their commands, which is not hard, they can take advantage of this vulnerability.
How to Detect Log4j
Most businesses do not have an accurate inventory of their systems and therefore cannot identify the extent of usage of the Log4j library. The most reliable check would be to run an extensive vulnerability scan on the IT infrastructure and identify the systems that use the vulnerable versions of the Log4j library.
SecurityShield from SureShield is an effective tool to detect the Log4j vulnerability.
The Series of Fixes from Apache
The good news is that the Apache Foundation has updated Log4j to address this gaping vulnerability. Every organization, large or small, in any industry, urgently needs to check for the presence of this vulnerability in their environment. When found, they must update affected systems to the latest patched version.
The first update — version 2.15.0 — was released on December 6, 2021. As exploitation ramped up in the wild, it became clear that the update did not fully remediate the issue in all use cases. (The National Vulnerability Database (NVD) codified this as CVE-2021-45046.)
On December 13, the Apache Foundation released version 2.16.0, which completely removed support for message lookup patterns, thus slamming the door on JNDI functionality.
However, Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups, which could lead to Denial-Of-Service attacks identified as CVE-2021-45105.
To address the DOS concerns, Apache released yet another update (version 2.17) to the Log4J libraries to ensure that recursive lookups do not cause services to fail through a distributed-denial-of-service attack. Unfortunately, backlogged development teams may not have the resources to update material sections of their codebase handling logging. It doesn’t matter because this vulnerability needs to be identified and remediated now.
SecurityShield from SureShield is an effective tool to guide Log4j vulnerability remediation efforts.