Find and fix the Log4Shell exploit fast with Snyk
Ariel Ornstein
December 13, 2021
0 mins readEditor's note (28 Dec 2021 at 7:35 p.m. GMT): The Log4j team released a new security update that found 2.17.0 to be vulnerable to remote code execution, identified by CVE-2021-44832. We recommend upgrading to the latest version, which at this time is 2.17.1. Read more here.
Editor's note (18 Dec 2021 at 6:55 p.m. GMT): The Log4j situation is rapidly changing and we are updating our blogs as new information becomes available. It is recommended you upgrade to version 2.17.1 or later. This version contains security fixes for two remote code execution vulnerabilities, fixed in 2.15.0 (CVE-2021-44228) and 2.16.0 (CVE-2021-45046) and the latest DoS vulnerability fixed in 2.17.1 (CVE-2021-45105). Read more here.
Even if you tried VERY hard to enjoy a quiet weekend, chances are that this plan was interrupted at least once by the new Log4Shell zero-day vulnerability that was disclosed on Friday (December 10, 2021).
The new vulnerability was found in the open source Java library log4j-core which is a component of one of the most popular Java logging frameworks, Log4J. It was assigned CVE-2021-44228, categorized as Critical with a CVSS score of 10, and with a mature exploit level as there has been clear evidence of it being exploited in the wild.
All versions starting at 2.0-beta9 up to 2.14.1 are impacted by the new vulnerability, which is fixed in the latest version (2.16.0) that was released on the same day as the disclosure.
Snyk quickly added the new vulnerability to the Snyk Intel Vulnerability Database for customers, partners, and the community at large, to use for scanning their JVM applications and containers and for applying an urgent fix to this vulnerability using Snyk Open Source and Snyk Container.
How Snyk can help you find and fix Log4Shell
One of the first questions most people will ask is: What is my level of exposure to this vulnerability?
Using Snyk helps you answer this question by showing you if you’re using the vulnerable versions of the package and where they’re being used. Snyk also helps you fix them across your entire SDLC.
We’re going to show you how to use Snyk to find out if you’re vulnerable to Log4Shell, either at coding time, through our SCM integrations, or by being alerted about it through our continuous monitoring service. We’ll also show you how to use our reporting service and API to do this at scale.
Snyk CLI command for unmanaged, undeclared code: snyk log4shell
Snyk CLI has a new command designed to do one thing: find traces of the Log4j library affected by the Log4Shell vulnerability. snyk log4shell tests your built Java project and finds traces of the vulnerable library even if it is not declared in the manifest files. Learn about snyk log4shell and how to use it in your projects.
Finding the Log4shell vulnerability at coding time
In order to find the vulnerability as quickly as possible, developers can use our IDE plugins and our CLI, which are free to get started with. The scan results will include all vulnerabilities found by Snyk, and for each vulnerability, how it was introduced in the application (either as a direct or indirect dependency) with clear instructions on how to fix them.
The Snyk CLI (be sure you’re using the latest version, v1.792.0) displays a special warning message to ensure the vulnerability, if identified, is given extra visibility (for instructions on installing and updating the Snyk CLI, please refer to our docs):
Scanning for log4j-core added as a jar
If you are not using a package manager (e.g. Maven), Snyk can detect the vulnerability in jar files too. To do this, simply run the snyk test --scan-all-unmanaged command in order to scan all the jars in the current folder (works with the snyk monitor command as well, for continuous monitoring of the project).
Testing your projects for Log4j vulnerabilities with Snyk’s SCM integrations
In few clicks, you can import all your projects that Snyk supports, test them for open source vulnerabilities, and get immediate insights into them including what vulnerabilities you have, including how they were introduced and how to fix them:
Snyk provides a wealth of information about the vulnerabilities identified, which is critical for understanding how to fix the vulnerability and how to prioritize vulnerabilities based on which require more immediate attention than others.
Snyk’s Priority Score is calculated based on a list of various signals, such as whether the vulnerability has an exploit in the wild, whether there is a fix available, or even whether it's trending on Twitter. This score can then be used to quickly sift through the list of vulnerabilities and prioritize fixes accordingly. In the case of Log4Shell, the Priority Score is understandably high, as explained upon hovering over the score.
The project’s dependency tree helps you understand exactly how a vulnerability was introduced into an application, whether directly or as an indirect dependency:
Continuous monitoring to prevent future cases of Log4j vulnerabilities
If you’d already imported your projects before the new vulnerability was disclosed, your project was automatically tested as part of our daily test cycle (unless the default configuration was changed). If you have our notifications enabled, you should have received a notification already letting you know whether the vulnerability has been found in one of your projects.
Automatic log4shell fix PR/MR
If your repository was already monitored by Snyk before the new vulnerability was disclosed, Snyk has already automatically triggered a fix pull/merge request that upgrades log4j-core to a non-vulnerable version.
If this is a new import or you didn’t enable automatic fix PRs, you can create the fix PR manually from the project page
Detecting and fixing Log4Shell in all your business’s services
If you’re a customer with access to our API and reporting service, these are great ways to help you get a picture of where the log4j-core dependency is being used across all of your monitored open source projects.
Using Snyk’s reporting to find projects that use log4j-core
You can use Snyk’s bill of materials (found in the dependencies tab of your group and org level reports) to search for where log4j-core is used. Open up the Dependencies filter and start typing the dependency name (log4j-core), and select it to refine the results to just this package. If you don’t see any results, that would indicate that you don’t have this dependency in the projects you’re monitoring with Snyk.
If you do find the dependency, you’ll be able to see exactly where it’s being used. Click on the Projects link, and a list of all the projects that use log4j-core as a dependency will be shown. You can then click on the project itself, where you’ll find fix instructions, and if there is an upgrade path, this will allow you to open a fix pull/merge request.
Using Snyk’s API to find projects that use log4j-core
You can also use our API to find where you’re using the log4j-core dependency. Our Dependencies by organization endpoint lets you list all used dependencies and get back results on where they are used. There are multiple filters such as language (a relevant one would be Java in this case), severity, and more, that you can use to narrow down the results you will get. Use our List all organizations in a group endpoint if you have a group with multiple organizations and want to loop through all of them.
As part of the response, you’ll see a list of all projects containing the relevant package. From here, you can either use the UI to look into the projects and fix the vulnerabilities or get fix instructions using other APIs.
Let Snyk help you!
Starting with Snyk is free, quick and easy. Join us today and we’ll help you find where you’re using the vulnerable log4j-core package (and more), and help you easily fix them so you can get back to your weekend!
Get started in capture the flag
Learn how to solve capture the flag challenges by watching our virtual 101 workshop on demand.