The Log4j Vulnerability: A Guide

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 recently exploited by Iran-sponsored APTs to compromise a federal network.

Log4Shell 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.

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.

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.