## https://sploitus.com/exploit?id=5CEF4882-D1D5-5861-944F-34E8868BF986
## Log4J-CVE-Detect
This repository contains a set of YARA rules for detecting versions of log4j which are
vulnerable to CVE-2021-44228, CVE-2021-45046, and / or CVE-2021-45105 by looking for a
number of features which appear in affected versions.
This tool works recursively on binary files such as Docker images, system packages,
filesystem images, and even installation media. See the "How does it work?" section for
a full list of supported file formats.
* CVE-2021-44228
* Looks for the signature of a `JndiManager` constructor (< 2.15.0).
* CVE-2021-45046
* Looks for `Interpolator` classes which do not import `JndiManager` (< 2.16.0).
* CVE-2021-45105
* Looks for `AbstractConfiguration` classes which do not import `ConfigurationStrSubstitutor` (< 2.17.0).
Although there is a number of resources available for detecting insecure use of log4j
using CodeQL or Semgrep, there have not yet been any resources made available for
detection of potentially vulnerable log4j versions inside of binary artifacts.
This presents a challenge for organisations running enterprise applications which were
not developed internally, or where the source code is not immediately available to teams
performing the initial triage.
As this vulnerability is likely to turn up in various "unexpected" places, this tooling
intends to assist in detecting vulnerable versions of log4j inside of compiled
artifacts, which can then be manually reviewed to determine exploitability.
### Caveats
Obfuscated code will result in false negatives, where a potentially vulnerable widget is
unable to be detected due to the use of obfuscation.
### Running it
To run this tool clone this repository and follow the following steps. This assumes that
Docker and jq are installed.
1. Add binaries which need to be checked into the `artifacts/` folder
2. Run quickstart.sh (`./quickstart.sh`)
Alternatively, the run can be customised using the following command:
```
docker run \
--rm \
--mount type=bind,source=$(pwd)/artifacts,target=/mnt/stacs/input \
--mount type=bind,source=$(pwd)/rules,target=/mnt/stacs/rules \
stacscan/stacs:latest \
--rule-pack "/mnt/stacs/rules/vulnerability.json" \
"/mnt/stacs/input"
```
If you only wish to look for CVE-2021-44228, the following command can be used:
```
docker run \
--rm \
--mount type=bind,source=$(pwd)/artifacts,target=/mnt/stacs/input \
--mount type=bind,source=$(pwd)/rules,target=/mnt/stacs/rules \
stacscan/stacs:latest \
--rule-pack "/mnt/stacs/rules/CVE-2021-44228.json" \
"/mnt/stacs/input"
```
If you only wish to look for CVE-2021-45046, the following command can be used:
```
docker run \
--rm \
--mount type=bind,source=$(pwd)/artifacts,target=/mnt/stacs/input \
--mount type=bind,source=$(pwd)/rules,target=/mnt/stacs/rules \
stacscan/stacs:latest \
--rule-pack "/mnt/stacs/rules/CVE-2021-45046.json" \
"/mnt/stacs/input"
```
If you only wish to look for CVE-2021-45105, the following command can be used:
```
docker run \
--rm \
--mount type=bind,source=$(pwd)/artifacts,target=/mnt/stacs/input \
--mount type=bind,source=$(pwd)/rules,target=/mnt/stacs/rules \
stacscan/stacs:latest \
--rule-pack "/mnt/stacs/rules/CVE-2021-45105.json" \
"/mnt/stacs/input"
```
This tool can also be run without Docker. Please see the [STACS](https://github.com/stacscan/stacs)
installation instructions for how to install STACS without Docker.
### What about Docker?
To scan a Docker image it first needs to be exported to the artifacts directory for
scanning. This can be done using the following command:
```bash
IMAGE="alpine:latest"
NAME="alpine_latest"
docker export $(docker create ${IMAGE}) -o artifacts/${NAME}.tar
```
Alternatively, a running container can be exported using just:
```bash
# Replace CONTAINER_ID with the correct container identifier.
CONTAINER_ID="c29209118f9a"
NAME="widget_example"
docker export ${CONTAINER_ID} -o artifacts/${NAME}.tar
```
### I got a finding! What do I do?
You'll need to investigate the use of `log4j` in the application to understand if the
product is vulnerable. If this is not possible, due to lack of access to source code or
otherwise, you should check whether the vendor has published any advisories on the
matter.
**There is no guarantee that the inclusion of a vulnerable version of log4j means that
the product is vulnerable!**
If you cannot find any advisories, you should contact the vendor to ask them about the
impact of this vulnerability on the product.
Also consult the mitigations [published by the log4j project](http://mail-archives.apache.org/mod_mbox/www-announce/202112.mbox/%3CD88D40C5-8884-470E-8FA3-3B6D6899A7B0@apache.org%3E). Alternatively, and preferably,
upgrade to an unaffected version of log4j.
### How does it work?
Although not designed for this purpose, this tool uses the [STACS](https://github.com/stacscan/stacs)
engine for bulk binary decomposition and analysis.
> STACS is a YARA powered static credential scanner which suports binary file formats,
> analysis of nested archives, composable rulesets and ignore lists, and SARIF
> reporting.
As an example, this tool can analyse a tarball which contains an exported Docker image,
which contains a JAR somewhere on the filesystem which is affected by this
vulnerability.
It can also analyse nested `tar`, `jar`, `war`, `ear`, `zip`, `apk`, `bz2`, `tgz`,
`xz`, `rpm`, `iso`, etc.
### I found a false positive / negative
Please open a Github issue describing the issue, and linking to the affected binary
artifact - where possible.
Pull requests to adjust to the rulesets would also be greatly appreciated!
### Validation
See the `validation/` directory for a set of log files from validation of this ruleset.