Identify and minimize production risk of Log4Shell

Log4Shell, a zero-day vulnerability affecting the popular Apache package was made public on December 9, 2021. The National Vulnerability Database (NVD) knows the Log4j vulnerabilities as CVE-2021-44228. It results in remote code execution (RCE) by submitting a specially composed request. This means that an attacker with control over a string that gets passed to the log4j 2 logger can trick the application into requesting a resource from a server under the attacker’s control, then load it, and then execute it. In summary, the Log4Shell vulnerability allows an attacker to instruct the vulnerable system to download, and subsequently execute, a malicious command.

As organizations work to find the usage of this library in their applications, they should focus on three criteria to prioritize the fix in their environment:

1. Public Internet Exposure – Are the Java processes using these libraries directly accessible from the internet?
2. Sensitive Data Access – Do the vulnerable Java processes access critical databases or file systems in the environment?
3. Application List – Which applications use these libraries?

Public Internet Exposure

Given that this vulnerability allows a malicious attacker to execute any command on a vulnerable Java process, it’s crucial to prioritize fixing it in Java processes that are accessible directly from a browser, mobile device, or application programming interface (or API) call.

For Java processes that are not directly accessible to the outside world, or internal-only processes, the risk is lower. So, while the goal is to fix this vulnerability in all Java processes, publicly exposed processes are most critical. We have already seen this approach be successful with customers that use Dynatrace Application Security to identify publicly exposed Java processes that are running in production, where the risk is highest.

The screenshot below confirms that Dynatrace Application Security detected the Log4j 2 vulnerability in the monitored deployment, and filters on public-facing internet connectivity (as depicted in the blue box).

As depicted below, a closer look at this detected vulnerability shows more context and details of the exposed services. In addition, the image puts everything in context, detailing the entire process, from the web application to the database (discussed in the next section). OwnerResource (highlighted) is the service running on the JVM loading the vulnerable log4j 2 library.

Sensitive Data Access

Stealing sensitive data, including data in a file system or a database, is a key objective of attacking an application. Java processes with public-facing internet exposures are an easy target for this type of abuse. To prevent the leakage of sensitive data, patching these Java processes is the top priority. Moreover, it is paramount for expeditious analysis to quickly identify the sensitive data assets that these vulnerable Java processes use.

The screenshot below shows sensitive data assets are within reach of the vulnerable Java processes.

An overview of the databases used by the vulnerable Java processes are highlighted in the following screenshot.

For better prioritization, the CVSS standard allows refining the base score with environmental factors, such as public internet exposure and sensitive data access. To make that step much easier and effective, automatic calculations, like the Davis Security Score, can be used.

The examples below show two vulnerabilities with an initial critical risk. Environmental score adjustments that transparently describe the actual risk in a deployment enable responding teams to stay focused on the most critical occurrences in their environments.

Application List

Myriad applications within an organization are likely vulnerable to Log4Shell. Identifying all vulnerable applications quickly will allow application owners not only to identify vulnerable, critical applications but also to identify applications that, while not critical, are nonetheless exposed to the internet. Recently, many Dynatrace customers took this approach after they successfully identified vulnerable applications.

The following screenshot shows what web applications are connected to the vulnerability.

In other words, as depicted below, a live topology model, such as the Smartscape, allows for identifying all affected web applications through simply traversing the graph from the JVM which loaded the vulnerable library.

Conclusion

For many organizations around the world, time is of the essence to mitigate the Log4Shell vulnerability in the Apache log4j 2 library. The best approach to remedy this issue is to prioritize the Java processes that are exposed to public networks and can reveal sensitive data to malicious attackers.

Related resources

• Blog – What is Log4Shell? The Log4Shell vulnerability explained (and what to do about it)
• Webinar – Identify and minimize production risk of Log4Shell
• Resource center – Detect and remediate Log4Shell with Dynatrace
• Security alert – Log4j vulnerability (Log4Shell)