How to Find and Fix Log4j with Open Source and Enterprise Tools from Anchore

Updated 01/07/22. As new information about the Log4j vulnerability becomes available, we will update this blog with the latest information.

As the Log4j zero-day vulnerability continues to have widespread effects across nearly every industry and sector, it’s becoming increasingly evident that there is still a long remediation road ahead. With new vulnerabilities associated with Log4j continuing to emerge, it is imperative to find and remediate this Log4j vulnerability across all your applications to ensure the security of your software supply chains.

This blog provides step-by-step instructions for finding and fixing the Log4Shell vulnerability found in Log4j using Anchore open source solutions (Syft and Grype) and commercial solution (Anchore Enterprise).

Summary of the Known Log4j Vulnerabilities

Log4Shell was originally published on Dec 10, 2021 as a zero-day vulnerability found in Apache Log4j 2, a widely used Java library. The vulnerability enables a remote attacker to take control of a device on the internet if the device is running certain versions of Log4j 2. After the original vulnerability was reported and fixed, there have been subsequent vulnerabilities identified which have resulted in new patched versions. We will update this table for any further Log4j vulnerabilities or versions

Steps to Find Log4j Using Anchore Open Source Tools

Anchore provides two lightweight, command-line open source tools. Syft scans filesystems or container images to produce a comprehensive software bill of materials (SBOM). Grype identifies known vulnerabilities by scanning an SBOM generated by Syft or by scanning filesystems or container images directly.

In the context of Log4j, Syft-generated SBOMs enable you to find out if Log4j is present in a source code repository, a filesystem, or a container image. Grype can then be used to perform a vulnerability scan on that SBOM to determine if the detected versions of any given software package match any of the known Log4j vulnerabilities.

As the Log4j incident continues to evolve, both Syft and Grype are useful in identifying which Log4j versions you are running and determining the presence of any new Log4j vulnerabilities as they are announced.

The following examples provide step-by-step instructions for using Syft and Grype to locate and remediate Log4j.

Syft

Watch a video demonstration

Download Syft.

Example 1: Run syft to generate an SBOM and filter the results to identify any vulnerable versions of Log4j.

Command Example:

# syft dir://tmp/jarsinjars/ | grep log4j

Command Example:

# syft docker.io/dnurmi/testrepo:jarjar | grep log4j

Example 2: Run syft with the JSON output option to get more detailed information on the locations of the Log4j dependencies in your source code repositories and/or container images.

The example below shows the top-level ‘fireline.hpi’ package which contains a Log4j jar deeply embedded as shown by the ‘VirtualPath’ element of the JSON record.

Command Example:

# syft -o json docker.io/dnurmi/testrepo:jarjar

Example 3: Run syft and create a JSON file so you can save it as an SBOM artifact.

Command Example:

# syft -o json docker.io/dnurmi/testrepo:jarjar > log4j-sbom.json

Grype

Download Grype.

Example 4: Run grype on an SBOM produced by Syft and filter to find components that contain Log4j vulnerability IDs.

The example below filters for the ID GHSA-jfh8-c2jp-5v3q but you can also filter for any of the new CVEs affecting Log4j (see above for a list of vulnerability identifiers).

Command Example:

# grype docker.io/dnurmi/testrepo:jarjar | grep GHSA-jfh8-c2jp-5v3q

Steps to Find and Fix Log4j Using Anchore Enterprise

Watch a video demonstration.

Anchore Enterprise scans and performs a deep inspection of container images to identify the presence of Log4j and related vulnerabilities. However Anchore Enterprise also maintains a repository of SBOMs across applications and teams, so that users can query their entire SBOM catalog to search for any scanned images that include Log4j.

Anchore Enterprise users can leverage policy-based reporting and alert services to create automatic notifications when existing or new scans identify vulnerable versions of Log4j. The customizable policy engine can provide a “stop” signal your build systems and Anchore’s out-of-the-box policies also contain a rule blocking critical vulnerabilities such as those registered against Log4j from being deployed into production.

Using the Anchore Enterprise Runtime Inventory system, users can also quickly search for and detect instances of vulnerable Log4j software that is present in containers running in your Kubernetes deployments.

All Anchore Enterprise vulnerability detection features continuously update using the latest vulnerability data from a variety of public sources, and send notifications as the Log4j incident evolves, to keep teams abreast of newly discovered vulnerabilities and fix versions pertaining to Log4j software.

Instructions below are provided for the Anchore Enterprise command-line interface (CLI) and the user interface.

Scanning with Anchore CLI to Find Log4j

Watch a video demonstration. 
The Anchore CLI provides a command-line interface on top of the Anchore Enterprise REST API. The Anchore CLI is published as a Python package that can be installed from the Python PyPI package repository on any platform supporting PyPI. Anchore CLI users can manage and inspect images, policies, subscriptions, and registries.

Example 1: Run anchore-cli to scan container images, produce an SBOM, and use it to identify any vulnerable versions of Log4j, along with the location of any detected, installed Log4j packages.

Command Example:

# anchore-cli image content docker.io/dnurmi/testrep:jarjar java | grep log4j

Example 2: Run anchore-cli to search a specific container image for vulnerabilities matching vulnerability IDs.

The example below filters for CVE-2021-44228 but you can also filter for any of the new CVEs affecting Log4j (see above for a list of CVE identifiers).

Command Example:

# anchore-cli image vuln docker.io/dnurmi/testrepo:jarjar all | grep CVE-2021-44228

Example 3: Run

anchore-cli

to query all of the analyzed image SBOMs in your catalog for instances of vulnerable software matching particular vulnerability IDs.

The example below filters for ID GHSA-jfh8-c2jp-5v3q but you can also filter for any of the new CVEs affecting Log4j (see above for a list of CVE identifiers).

Command Example:

# anchore-cli query images-by-vulnerability --vulnerability-id GHSA-jfh8-c2jp-5v3q

Policy Enforcement and Reporting Using Anchore Enterprise

Example 1: In the Anchore Enterprise user interface navigate to View Reports -> Quick Report -> Images By Vulnerability to perform a query to retrieve all images with vulnerable software matching particular vulnerability IDs, such as CVE-2021-44228.

Example 2:  In Anchore Enterprise, navigate to Image Analysis > Select Image > Vulnerabilities Tab. Select View Images Affected on the left hand side of the screen. This will generate a report of all other images that share the specified CVE.

Example 3:  Ensure that the active policy has a rule that specifies a STOP action on any vulnerability marked with a severity level of Critical.

Finding Log4j in Running Containers Using Anchore Enterprise

Example 4: Use Anchore Enterprise’s Runtime Inventory to detect any container that is running in your Kubernetes cluster and includes a vulnerable version of Log4j. You will first need to install KAI (an agent that runs in your Kubernetes cluster) which can be downloaded here.

Once KAI is installed, select the Kubernetes tab in Anchore Enterprise and select Vulnerabilities.

Next query for the known vulnerability identifiers for Log4j such as CVE-2021-44228 or others listed above.

Any currently running images with the Log4j vulnerability will populate in the table below when you execute the query. From there, you can drill down on any impacted image, by selecting the Vulnerabilities tab within the impacted runtime image, and View Images Affected to identify other images that share the Log4j vulnerability.

Remediation Workflows Using Anchore Enterprise

Example: If Log4j is detected in any of your applications, you must begin the fix process. Anchore Enterprise users can trigger notifications and remediation workflows based on rules set through the policy engine. Tickets can be automatically created in Jira or GitHub, sent as emails, or posted to Slack or Microsoft Teams channels. These notifications provide not only the details of the Log4j version discovered or the policy rules that were violated but also include explicit instructions on what versions should be used to resolve the issue.

Contact Us

Anchore is continuing to monitor the Log4j incident as it evolves. If you need assistance or want to learn more about how Anchore can help, please contact us.