Log4j vulnerability: identifying and minimising production risk
Log4Shell, a zero-day vulnerability affecting the popular Apache package was made public on December 9, 2021. The National Vulnerability Database describes the vulnerability here.
It results, says Asad Ali, senior director, Global Center of Excellence at Dynatrace, 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 organisations work to find the usage of this library in their applications, they should focus on three criteria to prioritise the fix in their environment:
- Public Internet Exposure – Are the Java processes using these libraries directly accessible from the internet?
- Sensitive Data Access – Do the vulnerable Java processes access critical databases or file systems in the environment?
- 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 prioritise 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.
Sensitive data access
Asad Ali
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.
For better prioritisation, 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. 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 organisation 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.
In other words, 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 organisations 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 prioritise the Java processes that are exposed to public networks and can reveal sensitive data to malicious attackers.
Comment on this article below or via Twitter @IoTGN