Log4j explained: Everything you need to know

What is the Log4j exploit?

Log4j didn't get much attention until December 2021, when a series of critical vulnerabilities were publicly disclosed.

The Log4j exploit began as a single vulnerability, but it became a series of issues involving Log4j and the Java Naming and Directory Interface (JNDI) interface, which is the root cause of the exploit.

CVE-2021-44228

The initial vulnerability in Log4j is known as CVE-2021-44228. It was first reported to the Apache Software Foundation by Chen Zhaojun of Alibaba Cloud Security Team on Nov. 24, 2021. The Log4j development team had a fix for the issue by Dec. 6, but the project didn't publicly disclose the presence of a high-impact security flaw.

On Dec. 9, researchers at security firm LunaSec publicly disclosed a serious remote code execution vulnerability in Log4j via tweet. LunaSec dubbed the flaw Log4Shell, which is the name by which CVE-2021-44228 and its subsequent flaws have been commonly referred to in the media.

Others knew of the Log4j security issues prior to its public disclosure. Cloudflare CEO Matthew Prince reported that his firm uncovered evidence of the exploit on Dec. 1. Cisco reported it first spotted attacks against Log4j on Dec. 2.

CVE-2021-44228 is a remote code execution (RCE) flaw in multiple versions of the software, including Log4j2 2.0-beta9 through 2.15.0. It excluded security releases 2.12.1 and 2.13.0. The RCE flaw is due to the way Log4j interacts with JNDI without properly validating all requests. This means an attacker who gains access to logging messages could inject fraudulent messages that enable arbitrary code execution and exploitation of a vulnerable system. The NIST National Vulnerability Database has rated CVE-2021-44228 as a 10.0, its highest possible severity score on the Common Vulnerability Scoring System.

CVE-2021-45046

The Log4j Project released its initial patch for CVE-2021-44228 with Log4j 2.15.0 on Dec. 6. That patch was faulty and did not completely limit the risk of an attacker exploiting JNDI. The insufficient mitigation of the initial RCE flaw with the Log4j 2.15.0 update was identified as CVE-2021-45046.

CVE-2021-45046 was patched in a second update -- Log4j 2.16.0 -- which was publicly released Dec. 13. The Log4j 2.16.0 update disabled JNDI by default, so developers needed to explicitly enable it with the requisite permissions for it to run.

CVE-2021-41014

When the first Log4j vulnerability was reported, it was thought to only impact Log4j 2.x versions and not the older Log4j 1.x. It turns out that's not the case, as evidenced by the CVE-2021-41014 vulnerability reported Dec. 15.

While Log4j 1.x did not include direct support for JNDI by default, users could have used the JMSAppender object to execute JNDI requests. As Log4j 1.x reached its end of life in August 2015, there is no patch update for the flaw, and users are being directed to update to the latest Log4j 2.x version.

CVE-2021-45105

Log4j 2.17.0 was released Dec. 17 to fix yet another issue in the beleaguered open source logging framework. CVE-2021-45105 -- which is patched in Log4j 2.17.0 -- is a DoS vulnerability. It is triggered by a recursive lookup that could overwhelm a system. A recursive lookup occurs when multiple lookups on the same information are triggered and continue until a definitive answer is found.

CVE-2021-44832

While JNDI was supposed to be disabled by default in the Log4j 2.16.0 update, there were still some corner cases where there was risk. CVE-2021-44832 is a flaw in how Java Database Connectivity interfaces with JNDI in an insecure way that could enable an RCE. The CVE-2021-44832 flaw was patched by the Log4j Project in the Log4j 2.17.1 release that became generally available Dec. 27.

Businesses and systems affected

Attacks soared after the first vulnerability was publicly disclosed, as hackers attempted to exploit unpatched users. The effect of the Log4j vulnerabilities was widespread due to the logging library being embedded in many popular services and frameworks. Here are some of the products that were affected.

• Apache Struts. Log4j is part of the default configuration in the Apache Struts 2 application framework. Struts has had its own challenges with vulnerabilities in recent years, as it was identified as the root cause of the Equifax data breach in 2017. Struts itself is embedded in numerous enterprise applications, exposing many organizations to risks they might not know about.
• Apache Solr. Log4j is in Apache Solr by default, putting users of the search technology at potential risk until they update for the latest patched version.
• Apple iCloud services. These services were at risk from the Log4j issue, with Apple patching the issue on its end. Left unpatched, this could have enabled attackers to gain access to information about millions of users.
• Microsoft Minecraft. The Microsoft-owned Minecraft game -- which enables users to build an environment and collaborate with other gamers -- was found to be at risk on Dec. 10. An advisory and patch were issued the same day.
• VMware products. Multiple VMware products were identified to be at risk from the Log4j issues, including VMware Horizon, vCenter Server and vRealize Operations.

The above list represents a very small snapshot of the widespread effect. The U.S. government is currently tracking a lengthy list of software that is vulnerable to the Log4j issues.

U.S. government response to Log4j

From the earliest days of the incident, the U.S. government took a leading role in efforts to remediate the Log4j vulnerabilities.

The Cybersecurity and Infrastructure Security Agency (CISA) issued Emergency Directive 22-02 on Dec. 17, which directed U.S. federal government agencies to mitigate, patch or remove all applications and services affected by the Log4j exploits. CISA required federal agencies to report on affected applications by Dec. 28. CISA is expected to report on the status of the emergency directive and the effect of Log4j to the Secretary of the Department of Homeland Security by Feb. 15, 2022.

CISA isn't the only U.S government agency that issued directives related to Log4j. On Jan. 4, 2022, the Federal Trade Commission warned companies to mitigate the Log4j vulnerability or face negative consequences.

How to protect against Log4j exploit

The type of risk that the Log4j vulnerabilities expose organizations to can be found in other open source and proprietary code components that are embedded in applications. A key challenge is knowing what's at risk and then figuring out how to mitigate the risk. There are several steps organizations can take to mitigate against Log4j exploits.

• Implement a DevSecOps strategy. Some industry pundits are optimistic the Log4j incident will be a DevSecOps wake-up call to prevent organizations from being forced into a panicked race to remediate a flaw in production. Instead, processes would already be in place throughout the development and operational lifecycle of an application to identify issues and enable rapid rollout of fixes.
• Use network-based filtering. A key challenge many organizations face with Log4j is that they don't know they are at risk. Another challenge is that vendors that embed Log4j have not patched applications, leaving users at risk. One approach to solve for unknown risk from Log4j is using network-based filtering or web application firewall cloud services such as Cloudflare, Imperva or Akamai. This will block potential exploits before they can attack vulnerable applications.
• Scan applications to identify risk. For applications that organizations manage on their own, scanning for vulnerable instances of Log4j is recommended. There are multiple tools available from vendors and organizations that look for Log4j. Among the most popular are open source scanning tools from CERT-CC and CISA.
• Patch and repeat. Once an organization is aware of vulnerable applications that use Log4j, the best approach is to patch to the latest version of Log4j. This remediates all currently known and publicly disclosed vulnerabilities in Log4j.
• Monitor for malicious traffic. Log4j attacks have been ongoing since early Dec. 2021 and it's possible an organization could be exploited before they are able to remediate and patch. Organizations should use threat hunting techniques to help identify if they have been breached and make ongoing use of log and operations monitoring tools to look for suspicious traffic.