Your Log4shell Remediation Cookbook Using the JFrog Platform

UPDATED 1/14/2022: Added information on JFrog tool to patch Docker images in Artifactory repositories.

Last week, a researcher from the Alibaba Cloud Security Team dropped a zero-day remote code execution exploit on Twitter, targeting the extremely popular log4j logging framework for Java (specifically, the 2.x branch called Log4j2). The vulnerability was originally discovered and reported to Apache by the Alibaba cloud security team on November 24th. MITRE assigned CVE-2021-44228 to this vulnerability, which has since been dubbed Log4Shell by security researchers.

Since then, the vulnerability has been reported to be massively exploited in the wild, due to the fact that it is trivially exploitable (weaponized PoCs are available publicly). It is also extremely popular and got wide coverage on media and social networks.

For further in-depth technical information about the vulnerability, please see the blog post: Log4Shell 0-Day Vulnerability.

In this technical blog post, we will address the detection, blocking, and remediation options you can take to protect your organization using the JFrog platform:

Discover all usage of the log4j package by one of these methods

1. Use Artifactory search to find all repositories and namespaces with log4j library
2. Use Artifactory build-info (Software bill of materials – SBOM)
3. Use Xray watch to alert on usage of a vulnerable log4j package
4. Use Xray Ancestors to find affected resources
5. Use Xray API to find packages affected by this CVE
6. Use Xray reporting to trace all log4j packages
7. Use violations search in existing watches
8. Use JFrog security OSS scanning tool for source code and binaries

Block usage of log4j package

1. Use Xray policy to block the download of the vulnerable package
2. Configure “exclude patterns” on remote repositories

Fix the vulnerability in Artifactory repositories

1. Use JFrog Artifactory local repository prioritized resolution
2. Use JFrog OSS tool to patch Docker images

How To Discover all Usage of Vulnerable log4j Packages

Use Artifactory search to find all repositories and namespaces with log4j library

You can search for packages, artifacts, and builds in Artifactory to discover where these items are used across your repositories. Use the search bar in Artifactory to lookup the log4j packages that are cached in Artifactory remote repositories, as well as their locations in local repositories and builds.

Use Artifactory build-info (Software bill of materials – SBOM)

JFrog artifactory CLI and CI plugins can be utilized to store build-info, the metadata associated with a build in Artifactory.

When you follow JFrog best practices and store build info in your Artifactory instance, you can query Artifactory to list all the builds that use the log4j-core library as a dependency using the search of a checksum (each log4j package has a different checksum):

Note: You will need to perform a separate search for each vulnerable package using its checksum.

Using Xray watch to alert on usage of a vulnerable log4j package

You can detect all usage of vulnerable log4j libraries using JFrog Xray. This can be achieved by creating Xray policies and watches to alert you to specific vulnerabilities in your packages and builds. that would alert for all log4j packages:

1. Make sure all your Maven and Gradle repositories are flagged with “Xray index” enabled.
2. Create an Xray policy that defines a violation with a criteria of CVSS score of 10.
3. Create a watch, associate the policy that would alert the download of the vulnerable packages
   
4. Apply it to “all repositories” with a specific filter to include only log4j-core artifact names.
   
   

Use Xray Ancestors to find affected resources

Once you have identified a malicious artifact (in the example below it is log4j-core-2.14.1.jar) you can use the Ancestors tab in Xray to identify all the impacted artifacts within your organization.

Use the Xray API to find packages affected by this CVE

The following REST API command can be used for searching the CVE in identifying the affected artifacts.

curl -uadmin:Password1 -XPOST http://ARTIFACTORY_URL/xray/api/v1/component/searchByCves -H "Content-Type: application/json" -T search-cve.json

And the json file should consist of:

{
    "cves": [
        "CVE-2021-44228"
    ]
}

The output should be similar to the below, and you should be able to see the path for each package.

[{"cve_details":"CVE-2021-44228","components":[{"name":"org.apache.logging.log4j:log4j-core","package_type":"Maven","version":"2.13.3","link":"http://ARTIFACTORY_URL/ui/packages/gav:%2F%2Forg.apache.logging.log4j:log4j-core/2.13.3?activeTab=xrayData"}]}]

Use Xray reporting to trace all log4j packages

You can generate vulnerabilities reports to identify the impacted artifacts and corresponding remediation versions. 

Go to Security and compliance > Reports

Create a new report with the scope you would like to discover.

After selecting the concerned resources, add CVE-2021-44228 as criteria:

These criteria will help to generate a report in various formats, such as the following example:

You can later export to a PDF / CSV / JSON formats:

Use violations search in existing watches

1. Go to an already existing watch.
   
2. Filter on the specific CVE
   

Use the JFrog security OSS scanning tool for source code and binaries

The JFrog Security group has developed an OSS tool that can scan binaries and source code to trace whether a repository or binary is using vulnerable log4j calls or classes. The OSS tool is developed in Python and Java and is accessible at the following link: https://github.com/jfrog/log4j-tools

How to Block Use of Vulnerable log4j Packages

Use Xray policy to block the download of the vulnerable package

Use Xray to immediately detect and/or prevent all usage of vulnerable log4j libraries. This can be achieved by a policy that would alert or block log4j packages:

1. Make sure all your Maven and Gradle repositories are flagged with “Xray index” enabled.
2. Create an Xray policy to block download with a criteria of CVSS score 10.
   
   
3. Consider applying “block download” in case you want to block the download of the vulnerable packages.
4. Create a watch, associate the policy that would alert or block the download of the vulnerable packages.
   
5. Apply it to All Repositories with a specific filter.
   

Configure exclude patterns on remote repositories

You can configure an exclude rule to select against the library’s *jar file, to prevent it from being included. (See: https://jfrog.com/knowledge-base/how-to-use-include-exclude-patterns/) 

This is a fairly simple and straightforward process, selecting the pattern: ​​*/log4j-core-2.x.jar

This will result in developers being unable to access the base jar for their dependency resolution and is a good way to prevent the affected code from being used. As the affected builds are 2.0 to 2.14.1, an Artifactory administrator could add 14 exclude rules quickly to maximize safety while minimizing the amount of content being blocked for developers.

How To Fix the Problem

The best, and longest-term fix is for developers to update their source code to use the relevant fixed version of log4j and to produce a new build.

However, it’s also possible through the JFrog Platform to create interim builds that mitigate the log4j issue without waiting for source code updates:

Use JFrog Artifactory local repository prioritized resolution

When using virtual repositories (as a best practice), Artifactory will always resolve first from local repositories, then remote repositories, and only then will try to request artifacts from the remote resource.

This can be utilized to serve a patched package with the same version, which does not allow JNDI functionality. This modified version has the same code and version of the vulnerable package, but the JNDI class is removed from the package, allowing the builds to still resolve the “vulnerable package” without any change or update, but it would not contain the vulnerable code:

1. Create a local repository of Maven type, and configure it with priority resolution.
2. Upload the modified package to it with the same version as the vulnerable package (see below)
3. Link it to all virtual repositories

To create a modified version of a vulnerable log4j, remove the JndiLookup class from the classpath: 

“zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”

Note: In this solution, there are actually two identical versions of each log4j version – sanitized and vulnerable, but each with a different checksum. This is NOT a recommended practice and a situation that should be avoided.

Use JFrog OSS tool to patch Docker images

JFrog R&D has created a tool that automates patching of vulnerable Docker images. The tool will connect to an Artifactory repository, download the Docker images, patch them and will upload them back to Artifactory, while overriding the vulnerable container image. Using this method you will be able to use the same semantic version as the vulnerable container, which will ease the fixing cost because no configurations are needed to be changed.