The Log4j Vulnerability: A Guide

What Is the Log4j Vulnerability?

The Log4j vulnerability, also known as Log4Shell, is a severe critical remote code execution (RCE) vulnerability. It was publicly disclosed in late November 2021 and can impact any Java application that includes the Log4j library version 2.15 or earlier. Log4j is a popular open-source Java library maintained by the Apache Software Foundation. It is commonly used to build logging functionality into Java applications, including native desktop, web, mobile, and cloud applications.

Soon after cybersecurity researcher Chen Zhaojun discovered and privately disclosed Log4Shell, NIST published the vulnerability as CVE-2021-44228. Patched versions of Log4j—Log4j 2.15 and Log4j 2.16—were released to address Log4Shell. However, the vulnerability brought widespread attention to the Log4j source code resulting in more vulnerabilities being discovered and the subsequent release of Log4j 2.17.

Threat actors leveraging Log4Shell take advantage of how a feature in Log4J interprets specially formatted strings containing a Java Naming and Directory Interface (JNDI) resource URL. JNDI features allow attackers to connect to a remote LDAP server, fetch malicious code, and execute it on the victim host. Any unsanitized user input sent to Log4J could potentially trigger this exploit.

Log4Shell is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.

Who Is Affected by Log4Shell?

Due to Log4j’s popularity and the severity of the vulnerability, Log4Shell has a high potential to cause a significant negative impact on IT security for years to come. The number of applications implementing Log4J has been described as “countless;” the Apache Software Foundation stated that it could not estimate how impactful this vulnerability may be.

The exploit affects the host system of any application using Log4J 2.15 or earlier that does not correctly sanitize incoming data before it is logged. This vulnerability can affect native desktop, web, mobile, and closed Java applications developed internally and outsourced, commercial, or open-source applications from third-party vendors. 

How Bad is Log4Shell?

Log4Shell is a remote code execution (RCE) vulnerability allowing an attacker to perform actions on a system without having physical access. To make matters worse, Log4Shell allows RCE without user interaction, meaning the victim does not have to take action, such as clicking on a button or link to enable the attack. 

Log4Shell is also simple to exploit. An attacker doesn’t need a strong background in software engineering; even a novice attacker could take remote control of systems—including Internet of Things (IoT) devices, enterprise web servers, cloud applications, corporate workstations, and industrial control systems (ICS). These combined factors give Log4Shell the highest possible Common Vulnerability Severity Score (CVSS) of 10, classifying it as “severe.”

Malware delivered via Log4Shell could perform a wide range of malicious activity on a victim’s device, from stealing banking credentials to locking up systems and demanding a ransom to decrypt them to exfiltrating sensitive information such as personal, medical, or financial data.

Security researchers observed threat actors scanning the internet for vulnerable hosts within hours of the public disclosure. Since December 2021, widespread exploitation of Log4Shell has been identified by prominent security research firms and attributed to nation-state activity from threat actors in China, Iran, North Korea, and Turkey. 

The Cybersecurity and Infrastructure Security Agency (CISA) has created a leadership group within the Joint Cyber Defense Collaborative to address Log4Shell, and CVE-2021-44228 has been added to CISA’s catalog of known exploited vulnerabilities.

The key to identifying whether your organization is vulnerable to Log4J lies in discovering which applications are built with the Log4j component, assessing how those applications use Log4j, and remediating the vulnerability by updating the version of Log4j used in the application. 

However, most organizations also rely on third-party Java-based software applications, including native desktop, web, mobile, and cloud applications in their day-to-day operations—the Log4Shell vulnerability may be present in any of these. 

Identifying where an organization is vulnerable depends on reviewing all internally developed and third-party applications to confirm they have been patched against Log4Shell. An organization’s business operations may be impacted by proxy if a partner organization is compromised. Many major industrial and consumer firms have launched internal probes to determine whether their supply chain relies on Log4j and encourage partners and vendors to patch their software products promptly. Determining exposure requires determining if any applications across the entire supply chain are affected.

Fixing a deeply embedded security flaw can be a monumental task, even for organizations aware of the problem and well-equipped to manage enterprise software development. To assess internally developed Java applications, source code should be scanned for Log4J; if found, it should be inspected further to determine if any instances of the logging package are vulnerable to Log4Shell.

Complete mitigation depends on replacing vulnerable Log4J libraries with the latest version. The Apache Foundation issued official security updates for the Log4j library in December 2021. To protect applications, upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later). From Log4j 2.16, the JNDI protocol allowing RCE has been disabled by default.

Protecting against Log4Shell in third-party vendor software and within the supply chain requires verifying that vendors of Java-based software applications have updated their products accordingly and verifying that all upstream and downstream business partners are aware of the vulnerability and taking action to update their software.

FAQ

What is the Log4j vulnerability?

The Log4j vulnerability is a critical remote code execution vulnerability potentially impacting any Java applications that include the open-source Log4J 2 logging library. Unpatched, the vulnerability leaves systems and organizations exposed to cyberattacks and data theft.

What is Log4j?

Log4j is a popular open-source Java library maintained by the Apache Foundation to enable logging functionality in Java-based software, including native desktop, web, mobile, and cloud applications.

What is Log4Shell?

The Log4j vulnerability publicly disclosed in November 2021 is known as “Log4Shell” due to the potential for an attacker to achieve remote code execution (AKA “command shell”) on a target host. 

How do I fix the Log4j flaw?

Java source code for an application should be inspected for the use of vulnerable Log4J versions (< 2.16). To protect applications, vulnerable libraries should be replaced with a patched Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).

 CylanceOPTICS® provides on-device threat detection and remediation using artificial intelligence (AI) to prevent security incidents with root cause analysis, smart threat hunting, and automated detection and response capabilities. Our Endpoint Detection and Response (EDR) approach effectively eliminates response latency. It can be the difference between a minor security incident and a widespread, uncontrolled event.