Category: Log4j

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

Posted on by Dan Nurmi

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

Vulnerability IDs Affected Package and Version  Patched Version  Date Published References
CVE-2021-44228,
GHSA-jfh8-c2jp-5v3q		 log4j-core 2.14 and earlier 2.15.0 (Java 8) 10 Dec 2021 NVD, GHSA
CVE-2021-45046,
GHSA-7rjr-3q55-vv33		 log4j-core 2.15 and earlier 2.16.0 (Java 8)
2.12.2 (Java 7)		 14 Dec 2021 NVD, GHSA
CVE-2021-45105,
GHSA-p6xc-xr62-6r2g		 log4j-core 2.16 and earlier 2.17.0 (Java 8)
2.12.3 (Java 7)
2.3.1 (Java 6)		 18 Dec 2021 NVD, GHSA
CVE-2021-44832,
GHSA-8489-44mv-ggj8		 Log4j-core 2.17.0 and earlier 2.17.1 (Java 8)
2.12.4 (Java 7)
2.3.2 (Java 6)		 28 Dec 2021 NVD, GHSA

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.

How to Detect and Remediate Log4J at Scale with Anchore Enterprise

Posted on by Neil Levine

Responding to Log4Shell, the Log4j zero-day that disrupted the lives of security teams around the globe, is not a one weekend or one week event. While organizations may have put in place immediate responses to try to prevent exploits, the problem won’t be resolved until all of the applications that use Log4j have been remediated. This will require a long term response that remediates the impacted applications while preventing any more vulnerable components from making it through to production or being delivered to customers.

Since the Log4shell vulnerability disclosure, we’ve seen a huge interest in our open source projects, Syft and Grype. These tools are simple yet powerful CLI utilities which help you generate a Software Bill of Materials (SBOM) for your software artifacts (Syft) so you can see if you are using Log4j and notify you if they are vulnerable (Grype). Our VP of Security, Josh Bressers, wrote an Infoworld article explaining how you can get going with them quickly.

Syft and Grype are very convenient for ephemeral, one time scans but with a fast moving situation and new versions of Log4j coming out quickly to address the vulnerability (we’ve already seen two), tracking, enforcing and managing the SBOMs and vulnerability data they generate can quickly become challenging. Anchore Enterprise provides users with a number of features that both help to reduce the pain of the current response frenzy and help you over the long haul get to a place where the vulnerability has been fully remediated.

Detecting Log4Shell at Scale

Applications containing Log4j may be going through your development pipeline, sitting in your registry, or actively running in Kubernetes. Anchore Enterprise customers already have all of this information about the possible locations of the vulnerable package in a single repository so they can easily search across their entire environments to assess the impact.

Anchore Enterprise customers already get a fully supported version of the functionality in Syft and Grype combined into a single tool called AnchoreCTL. Whether used on the command line on a desktop or integrated into your CI/CD pipelines, AnchoreCTL pushes all of the SBOM data to Anchore Enterprise centralized data store. Combined with data that Anchore Enterprise gathers from artifact registries or Kubernetes environments, all SBOM data is managed and accessible in a single place.

Not only does this allow security teams to detect whether vulnerable versions of Log4j are being used anywhere across their environments but also allows them to check when new versions of Log4j are being deployed and put into production by developers.

Many CEOs and Boards of Directors are demanding daily updates from the CISO and security teams on the business impact of the Log4j vulnerability and Anchore Enterprise’s reporting system is allowing security and response teams to accurately report on how vulnerable they are to the ongoing issue.

Using Policies for Enforcement at Scale

While identifying if and where you are vulnerable is the essential first step to triage the problem, customers quickly need to reduce risk. Anchore Enterprise contains a sophisticated policy engine that can provide a “stop” signal to the platforms in your development environment. By default, the out-of-the-box policies in Anchore Enterprise contain a rule disallowing critical CVEs so all customers already received necessary protections as soon as the issue was flagged in public databases on December 9, even if they had not yet crafted a specific response.

For users who are using AnchoreCTL to scan builds in their CI/CD systems, as soon as the policy rule about critical CVEs was triggered, build and deployment jobs would have been halted for affected software. Going further along the deployment process, users who had Anchore Enterprise connected to Anchore’s Kubernetes Admission Controller, would have also been unable to deploy vulnerable applications as a result of the policy rule.

Beyond the default policies provided by Anchore Enterprise, customizing more granular policy rules can help your organization to further pinpoint your efforts. For example, users may run very old versions of Log4j that are not vulnerable to the Log4Shell exploit. Users can easily add an access list rule in Anchore Enterprise to disallow the impacted versions (2.0 to 2.15) but allow others (versions lower than 2.0) to ensure the dragnet doesn’t catch more than it needs. As we have recently seen, an updated version of Log4j (2.15) was itself a concern. Some more advanced users create their own hot fix packages to avoid waiting for upstream security responses. Temporary policy rules can be created to enforce the presence of a specific hash for a custom-built package to ensure developers have used the internally created hot fix until the organization is comfortable using the upstream public package.

Beyond just looking at the version string, a number of mitigation strategies have emerged such as using environment variables to modify the behavior of the Log4j code. A policy rule can be added that ensures these variables are in place. Combined with a temporary allow-list entry for the version of Log4j you are using, this can be a more practical solution while you work on your upgrade strategy.

Using the Anchore Enterprise policy engine for multiple pipeline stages enables a defense-in-depth approach to ensure you are catching all entry points for vulnerable content. The single point of command and control for your security rules across any component found in an SBOM allows customers to adjust as new information comes to light.

Remediating Log4Shell At Scale

Finally, chances are you are detecting Log4j in multiple applications maintained by multiple development teams. To start the fix process, Anchore Enterprise users can trigger notifications and remediation workflows based on rules that are triggered from 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.

From Sprint to Marathon

The extensive use of Log4j and the severity of the exploit means security professionals and development teams are going to be dealing with the issue for many months to come. Getting immediate visibility into your risk using open source tools is the fastest way to get going. But as we get ready for the long haul, prepare for the next inevitable critical issue that surfaces. Perhaps you’ve already found some as you’ve addressed Log4j. Anchore Enterprise can get you ready for a quick and full assessment of the impact, immediate controls to prevent vulnerable versions from moving further toward production, and streamlined remediation processes. Please contact us if you want to know how we can help you get started on your SBOM journey.