FlawOpen

flawopen.com/Incidents/log4shell-jndi-injection-december-2021

● Apache Software Foundation · CVE-2021-44228 · December 2021 · CVSS 10.0 · Critical
FlawOpen Security Research

Log4Shell (CVE-2021-44228): Cause and Fix

CVE-2021-44228 let logged data trigger Log4j 2 lookups and JNDI class loading. Update Log4j and inventory every embedded copy.[1], [2], [4]

💡 Plain English Explainer (ELI5)

An office has a clerk whose only job is to write down what visitors say. Someone discovers that if a visitor speaks a particular phrase, the clerk stops writing, goes to an address named in the phrase, collects a sealed envelope from a stranger and follows the instructions inside. The clerk was only ever supposed to write things down.[1]

Core Concepts & Subsystem Terms

Message lookups
A Log4j 2 feature that replaced ${...} expressions inside log messages with values at logging time. Before 2.15.0 this also applied to data inside the message, not just the configured pattern.[1]
JNDI
Java Naming and Directory Interface, an API for looking up objects in directory services such as LDAP. A JNDI lookup to a remote server could return a class for the JVM to load.[1]
Expression injection (CWE-917)
Untrusted data reaches an evaluator of expressions, so text supplied as data is executed as an instruction.[1]
Transitive dependency
A library your application includes only because another library depends on it. Many Log4Shell exposures came from copies of Log4j nobody had listed.[4]
Software bill of materials (SBOM)
A machine-readable list of every component and version inside a build, which lets you answer 'where do we run Log4j 2.14?' quickly.[4], [3]

Framework mappings

Incident Timeline

2021-11-24

Chen Zhaojun of Alibaba Cloud Security reports the flaw privately to Apache.[1]

2021-12-09

The flaw becomes public; Log4j 2.15.0 is released and mass scanning begins within hours.[1], [4]

2021-12-17

CISA issues Emergency Directive 22-02 requiring US federal agencies to find and mitigate Log4j.[3]

2021-12-28

Log4j 2.17.1 fixes CVE-2021-44832, the last of three follow-up CVEs after 2.15.0 (CVE-2021-45046 and CVE-2021-45105).[1]

Step-by-Step Attack Flow

Step 1

Attacker text reaches a log call

Any value an application logs, such as a username, a header or a search term, can carry a lookup expression chosen by the attacker.[1]

Step 2

Log4j evaluates the expression

Vulnerable versions process lookups inside logged data, so the expression is resolved instead of being written as plain text.[1], [2]

Step 3

JNDI reaches out

A JNDI lookup makes the server connect to a directory service named in the expression, often on the attacker's infrastructure.[1], [4]

Step 4

Remote code runs

The remote directory can point the JVM at a class to load, which then runs with the application's privileges. Where outbound connections were blocked, this step failed.[1], [2]

Source Code: Flaw vs. Secure Implementation

Illustrative Maven configuration. Importing log4j-bom makes every Log4j module, including copies pulled in by other libraries, resolve to one current version. The enforcer rule then fails the build if any log4j-core older than 2.17.1 is still reachable, including transitively, so a new dependency cannot quietly reintroduce the vulnerable code. Upgrading is the actual fix; blocking outbound LDAP and RMI from application servers is the defence in depth that broke exploitation even where patching lagged.

UNPATCHED FLAW
<!-- pom.xml: a direct dependency pinned to a vulnerable release -->
<dependencies>
  <dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.14.1</version>
  </dependency>
</dependencies>
<!-- Nothing stops another library from pulling in an older log4j-core transitively. -->
HARDENED SECURE PATCH
<!-- pom.xml: one version for every Log4j module, and a build that fails on old ones -->
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-bom</artifactId>
      <version>2.24.3</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-enforcer-plugin</artifactId>
      <version>3.5.0</version>
      <executions>
        <execution>
          <id>ban-vulnerable-log4j</id>
          <goals><goal>enforce</goal></goals>
          <configuration>
            <rules>
              <bannedDependencies>
                <searchTransitive>true</searchTransitive>
                <excludes>
                  <exclude>org.apache.logging.log4j:log4j-core:[2.0-beta9,2.17.1)</exclude>
                </excludes>
              </bannedDependencies>
            </rules>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

Engineering & System Hardening Checklist

Sources