darkarnium / Log4j-CVE-Detect

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 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:

IMAGE="alpine:latest"
NAME="alpine_latest"

docker export $(docker create ${IMAGE}) -o artifacts/${NAME}.tar

Alternatively, a running container can be exported using just:

# 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. 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 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.