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.
Readme
# CVE-2021-44228_scanner (modified) - Deprecated
Original Script and Repo: https://github.com/CERTCC/CVE-2021-44228_scanner
Modified by: Alex Pena
Applications that are vulnerable to the log4j [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) issue may be detectable by scanning jar, war, and ear files to search for the presence of `JndiLookup.class`.
Any file discovered is worth investigation to determine if the application using it is vulnerable. For any `JndiLookup.class` that is present, log4j commonly includes the version in the jar file name. For example, a hit on `log4j-core-2.14.1.jar` would be indicative of a vulnerable application. Alternatively, `log4j-core-2.16.jar` may also produce a hit because the JndiLookup code is still present in the 2.16 version of log4j, but it is disabled by default. See [VU#930724](https://www.kb.cert.org/vuls/id/930724) for more details.
Parameters
```
-Force Allow scanning of system and hidden files (The Force parameter doesn't override security restrictions)
-Verbose Extra scanning output and messages
```
Scan current directory
```
.\checkjndi.ps1
```
Scan ```test_folder``` directory, with extra output and scanning system/hidden files
```
.\checkjndi.ps1 -Force -Verbose c:\Users\alex\Desktop\test_folder
```
## Screenshots
For example, here is an invocation of the PowerShell version of the scanner:

Locations to scan can be piped into the script to have control of what is checked. For example, to scan a list of paths conatined in a the file `paths.txt`:
```
get-content .\paths.txt | .\checkjndi.ps1
```
## Interpreting results
Let's look at the first hit on our Windows scan execution:
```
C:\Users\unst0\Desktop\test_folder\apache-log4j-2.17.1-bin.zip contains apache-log4j-2.17.1-bin/log4j-core-2.17.1.jar contains org/apache/logging/log4j/core/lookup/JndiLookup.class ** BUT APPEARS TO BE PATCHED **
```
This jar file contains a 2.17 version of log4j, which is not vulnerable to CVE-2021-44228. This result is reported for information purposes, which shows that a vendor has patched their product.
Let's look at the second hit:
```
WARNING: C:\Users\unst0\Desktop\test_folder\ghidra_10.0.4_PUBLIC_20210928.zip contains ghidra_10.0.4_PUBLIC/Ghidra/Framework/Generic/lib/log4j-core-2.12.1.jar contains org/apache/logging/log4j/core/lookup/JndiLookup.class
```
Here we can see that Ghidra uses log4j version 2.12.1, and as such we should assume it to be vulnerable. And indeed, Ghidra versions before 10.1 are [vulnerable to CVE-2021-44228](https://github.com/NationalSecurityAgency/ghidra/releases/tag/Ghidra_10.1_build).
Let's look at the third hit:
```
WARNING: C:\Users\unst0\Desktop\test_folder\server.jar contains META-INF/libraries/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.jar contains org/apache/logging/log4j/core/lookup/JndiLookup.class
```
Here we can see that the minecraft server.jar file uses log4j version 2.14.1, and as such we should assume it to be vulnerable. And indeed, Minecraft: Java Edition server versions before 1.18.1 are [vulnerable to CVE-2021-44228](https://www.minecraft.net/sv-se/article/important-message--security-vulnerability-java-edition).
You should investigate any hits reported by either of these scripts, and confirm that either the log4j version is indeed the fixed 2.16 version, or reach out to your software vendor to obtain a fixed version of the software. Alternatively, [VU#930724](https://www.kb.cert.org/vuls/id/930724) has information about how `JndiLookup.class` can be removed from vulnerable jar files.
## Errors returned
The PowerShell version of the scanner has additional error reporting when files or directories cannot be investigated. In particular, any `Unable to scan` errors reporting `UnauthorizedAccessException` is indicative of a permission problem in accessing a directory and/or a file. Any `Unable to scan` errors reporting `InvalidDataException` is usually due to a corrupt archive.
File Snapshot
[4.0K] /data/pocs/9438dfe232aa77a1eacf15258c15664574e4e4ec
├── [ 10K] checkjndi.ps1
├── [364K] checkjndi_ps1.png
├── [1.2K] LICENSE.md
└── [4.0K] README.md
0 directories, 4 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 →