Find and Fix Log4j

Early in December 2021, a serious zero-day Remote Code Execution exploit was discovered in log4j-core. This component is the most popular Java logging framework. The log4j-core vulnerability (CVE-2021-44228, a.k.a. Log4Shell) affects a massive number of applications and businesses. Essentially any application that contains a vulnerable version of log4j-core is exploitable.

It has been determined that the fix for CVE-2021-44228 committed in v2.15 was insufficient in limiting nested message lookups in log4j. This resulted in CVE-2021-45046—a Security High vulnerability on v2.15. In addition, a Denial-of-Service (DoS) vulnerability (CVE-2021-45105) has been discovered in v2.16.  It is now recommended that all users upgrade to version 2.17.1 .


Select the Nexus solution you wish to use

Nexus Lifecycle (identify and fix the log4j-core vulnerability across applications)

Nexus Firewall (identify if log4j-core exists in your repository and prevent future downloads of vulnerable versions of log4j-core)

Nexus Repository (identify if log4j-core exists in your repository)

Nexus Lifecycle

The following information helps Nexus Lifecycle users find and fix log4j-core vulnerabilities. In addition, we've created a short video that walks you through this topic:

 

How do I know if my applications are affected by the log4shell vulnerability (CVE-2021-44228)?

Your Dashboard results will show the most recent violations.

The Dashboard is displayed by default when you log into Lifecycle. You can also access it by clicking the Dashboard icon on the left navbar:

Click the Filter button to adjust your results. For example, you can filter by the highest security threats within the desired time range.

Click Apply in the Filter menu to view your results:

Click the Export Violations Data button to save a CSV of the results:

If you scanned your application before the vulnerability was known, use the Component Search REST API to search for the component. The following curl will generate an output.txt file with all versions of log4j-core, including those that are not vulnerable.  A more complete demonstration can be found in the nexus-iq-api-scripts repo on the Sonatype Community Github. 

rm -rf output.txt; for i in {"build","stage-release","release","operate"}; do curl -u admin:admin123 -X GET "http://localhost:8070/api/v2/search/component?stageId=$i&componentIdentifier=%7B%22format%22%3A%22maven%22%2C%22coordinates%22%3A%7B%22groupId%22%3A%22org.apache.logging.log4j%22%2C%22artifactId%22%3A%22log4j-core%22%2C%22version%22%3A%22%2A%22%2C%22extension%22%3A%22%2A%22%2C%22classifier%22%3A%22%2A%22%7D%7D" >> output.txt; done

Note: Update the above with your credentials and IQ Server address.


The best practice for identifying log4j-core components in your application is to run a full, new scan. Avoid using re-evaluate in this situation. Clicking the Re-evaluate Report button on an existing report reapplies policies to the scan data, and the vulnerabilities do not change.

You will need to onboard your application to Lifecycle. Please see our Approaches to onboarding applications guide for help.

You can then run a scan via the CLI to get results.

The following example shows the command line for an Application ID Test123 and a URL of http://localhost:8070 . Replace <version> in the jar file path with your version of the CLI.

java -jar ./nexus-iq-cli-<version>.jar -i Test123 -s http://localhost:8070 -a username:password -t release sample-application.zip

Lifecycle Data Insights

Customers are now moving beyond the obvious dependency usage of Log4j and starting to scan entire portfolios of components looking for any traces of Log4j vulnerable components. Fortunately, the similar match fingerprints we already collect in a scan can be used along with our secondary expansion data to detect these embedded use cases.

To quickly help our customers in this scenario, we have released a new Data Insight that will highlight the presence of vulnerable Log4j classes contained within components. 


log4j-core is in my application. How do I fix it?

We recommend upgrading to a version of this component that is not vulnerable to this specific issue. The best option is to upgrade log4j-core to a newly released, non-vulnerable version immediately.

For Java 8 and later, upgrade to release 2.17.1

For Java 7, upgrade to release 2.12.4

For Java 6, upgrade to release 2.3.2

If this component is included as a bundled/transitive dependency of another component, there may not be an upgrade path. In this instance, we recommend contacting the maintainers who included the vulnerable package. Alternatively, we recommend investigating alternative components or potential mitigating control.

We strongly recommend upgrading to a non-vulnerable version of log4j-core. If that is not possible, Apache recommends using the following mitigating controls.

In any release other than 2.16.0, you may remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Reference: https://logging.apache.org/log4j/2.x/security.html

If this component is included as a bundled/transitive dependency of another component, there may not be an upgrade path. In this instance, we recommend contacting the maintainers who included the vulnerable package. Alternatively, we recommend investigating alternative components or potential mitigating control.


How do I protect my applications going forward?

The best practice is to turn on the Continuous Monitoring feature. Continuous Monitoring lets you use existing policies with notifications to constantly watch (once a day, based on your configuration) for new violations at a specific development stage (such as Release). Configure Continuous Monitoring in two steps: (1.) turn it on for an application or organization, and then (2.) turn it on at the policy level and set your notifications.

To turn on Continuous Monitoring for an application or organization:

  1. Select Organization & Policies icon from the left navigation bar:
  2. Select the organization or application whose policies you want to monitor.
  3. Under Continuous Monitoring, click the chevron next to Inherit from Root Organization (Do not monitor).
  4. In the Continuous Monitoring view, click the desired stage.
  5. Click Update to turn on Continuous Monitoring.

The next step is turning on Continuous Monitoring at the policy level. This lets you identify who should receive an email message when a violation of the current policy occurs.

To turn on Continuous Monitoring in a policy:

  1. In the Organization & Policy area, create a new policy or open an existing one for an organization or application.
  2. In the Policy editor, click the Notifications button to scroll to the Notifications section.
  3. Make sure the Notifications Recipient list contains the desired email address to use for policy violation notifications. If necessary, add a new recipient.
  4. For the desired email address, click Continuous Monitoring to select it.
  5. Click Update to save the policy.

For more information, please see our Notifications and Monitoring guide.

Nexus Lifecycle can be configured to send email notifications for events such as policy violation notifications. Email is a simple way to start getting notifications to the application security team, and eventually developers once they have been notified to expect them. 

This functionality requires an SMTP server, which is configured along with a number of other options in the Mail Configuration section of the config.yml file.

Email notifications from the IQ Server are automatically sent to recipients when a policy alert occurs. The email contains information about the application and violation and provides a link to the full results for further investigation.

For more information, please see our Notification Configuration help topic.

Nexus Firewall

The following information helps Nexus Firewall users identify if log4j-core exists in your repository and prevent future downloads of vulnerable versions of log4j-core.


Firewall can audit component downloads from a given proxy repository (Java, .NET, npm, Python). You can view a report that contains all components that have been previously downloaded to your Nexus Repository through that applicable proxy repository.

This report can be reviewed for any instances of log4j-core, and you can search for a particular log4j-core component. In addition, the Firewall results include Sonatype-curated vulnerability information—for this CVE and others—only available to Sonatype Firewall and Lifecycle customers.

If this component is found, it indicates it was previously downloaded into your Nexus Repository. As a result, the component is available to applications with privileges to access that proxy repository. To associate a component to a specific application, please visit Sonatype’s Nexus Vulnerability Scanner (NVS) a no-cost scan tool. If you have numerous applications to analyze, we recommend reaching out to Sonatype Sales to trial the Nexus Lifecycle solution.

 Nexus Firewall will not block the log4j-core component if it is already in your repository.


We recommend upgrading to a version of this component that is not vulnerable to this specific issue. The best option is to upgrade log4j-core to the newly released, non-vulnerable version immediately. This is currently version 2.17.1. However, given this is a fast-moving and fluid situation, there may be a newer version released as you are reading this guide. The fixed version for this issue was released by Apache and is available via Maven Central .


In addition to auditing component downloads, Nexus Firewall is designed to quarantine component download requests based on policy configuration. You can configure the policy to quarantine new component downloads for known vulnerable versions of any component based on any range of criticality.


Nexus Repository

The following information helps Nexus Repository users identify if log4j-core exists in your repository.


How do I determine if my organization is impacted by the latest vulnerability disclosure?

In an effort to help the global software community defend themselves against this threat, Sonatype is providing an experimental Log4j Visualizer to all Nexus Repository OSS and Pro users to provide greater visibility into Maven log4j component downloads impacted by CVE-2021-44228.

Note that the Log4j Visualizer only captures information about the log4j.core component in Maven and only identifies those impacted by CVE-2021-44228. It does not currently identify or track other log4j vulnerabilities.

Sonatype is providing this Log4j Visualizer for a limited time to all Nexus Repository OSS and Pro users due to the urgent threat that the log4j vulnerability poses to the global software community. Access and use of the Log4J Visualizer are governed by the terms of your agreement with Sonatype or, in the absence of such, these terms . We may update or remove this feature completely in future versions.

How should we remediate this issue?

To help mitigate the impact of any log4shell downloads, we have provided the following recommendations:

Short-Term Recommendations

  1. Encourage development teams to upgrade their log4j dependencies to a non-vulnerable version.
  2. Don’t delete vulnerable log4j versions from your repositories except as a last resort. Fixing critical problems can be harder when missing dependencies cause builds to break.
  3. Stay up to date on the latest Log4j developments.

Longer-Term Recommendations

  1. Consider reducing anonymous access to your repositories so that you can more easily understand who is consuming vulnerable dependencies.
  2. Block vulnerable open source components and malicious attacks from being downloaded into your repositories using Nexus Firewall.
  3. Reduce remediation time by using Nexus Lifecycle for continuous application monitoring. 


How do I determine if my organization is impacted by the latest vulnerability disclosure?

Repository Health Check (RHC) can audit component downloads from a given proxy repository. Users can view a report that contains all components, which have been previously downloaded to your Nexus Repository through that applicable proxy repository.

This report can be reviewed for any instances of log4j-core. Users can also search for a particular log4j-core component. In addition, the RHC report includes links to the associated CVE.

If this component is found, it indicates it was previously downloaded into your Nexus Repository. As a result, the component is available to applications with privileges to access that proxy repository. To associate a component to a specific application, please visit Sonatype’s Nexus Vulnerability Scanner (NVS) a no-cost scan tool. If you have numerous applications to analyze, we recommend reaching out to Sonatype Sales to trial the Nexus Lifecycle solution.

How should we remediate this issue?

We recommend upgrading to a version of this component that is not vulnerable to this specific issue. The best option is to upgrade log4j-core to the newly released, non-vulnerable version immediately. This is currently version 2.17.0. However, given this is a fast-moving and fluid situation, there may be a newer version released as you are reading this guide.   The fixed version for this issue was released by Apache and is available via Maven Central .

How can Repository Health Check (RHC) help with other known vulnerabilities?

Enabling RHC on all supported repository types provides insight into component downloads across your proxy repositories. In addition, the report includes trend analysis determined by month-to-month component downloads.


Additional Resources