Update: Prisma Cloud Addresses Log4Shell: CVE-2021-44228, CVE-2021-45046 Mitigations

This post is also available in: 日本語 (Japanese)

On December 9, 2021, a remote code execution vulnerability in the popular Java package Apache Log4j 2 was publicly disclosed. Since the abrupt release of the vulnerability, numerous exploits had been publicly shared and attackers made use of the opportunity to attack instances in the wild. The vulnerability had been dubbed “Log4Shell.”

Log4j is a logging framework designed to be used by any Java application. Due to its nature, it has been used in various Java programs from web servers to video games, all affected by this issue. We analysed this vulnerability and determined that it is of the highest severity possible, with a score of 10 in CVSS 3.1. The vulnerability was abruptly released, and the ease of exploitation and such a severe impact of remote code execution makes it an “ideal” vulnerability for mass exploitation by attackers. Due to the widespread use of log4j, the severity of the vulnerability and its ease of exploitation, the vulnerability had been compared to Shellshock which made a serious impact on internet security a few years ago.

We strongly recommend that users of this package upgrade it to the latest, fixed version, 2.16.0. To read more about the full details of vulnerability, its exploitation and risks please refer to our Unit 42 analysis.

The good news is that Prisma Cloud users can easily detect software components affected by this vulnerability. The Prisma Cloud Intelligence Stream (IS) automatically updates to include the vulnerability information from official vendor feeds. Prisma Cloud reflects any update or analysis by Linux distribution and application maintainers. This allows Prisma Cloud to accurately detect any affected images and hosts based on the most up-to-date information.

In addition, the Prisma Cloud research team also analyzed this vulnerability internally and published a Pre-Filled CVE for this issue. CVE-2021-44228 has blown up quickly, and some vendors are still analyzing it to determine affected versions and packages. The Intelligence Stream will continue to update as vendors release vulnerability information, but thanks to our analysis the vulnerability will be detected in all affected packages immediately.

Users can search for the CVE in Vulnerability Explorer where Defender agents are deployed.

The below screenshot is an example of container image details where CVE 2021-44228 is shown as Critical.

Update 1: On December 13, our research team determined that Log4j 1.x releases may be affected by a similar vulnerability. This vulnerability has been assigned CVE-2021-4104. Log4j 1.x is at end of life status since August 2015, and will not be fixed. The Intelligence Stream has been updated with this CVE and vulnerable 1.x instances are detected in Prisma Cloud.

Update 2: On December 14, it was discovered that the fix released in Log4j 2.15.0 was insufficient. CVE-2021-45046 was assigned for the new vulnerability discovered. Per our preliminary analysis, the impact of this vulnerability is Denial of Service (DoS) but not full remote code execution. The Intelligence Stream has been updated with a Pre-Filled CVE entry for CVE-2021-45046, and Prisma Cloud customers can detect this vulnerability. Previous mitigations suggested by configuring Log4J are not helpful in remediating this new vulnerability.

The risk can only be fully remediated by upgrading to Log4J 2.16.0.

Update 3: On December 15, a refined WAAS rule with improved coverage of obfuscated exploits had been released. WAAS users are encouraged to use the updated rule (also provided below).

Update 4: On December 18, a new vulnerability was discovered in Log4j through 2.16.0, assigned with CVE-2021-45105. Also it is not a variant of the original CVE-2021-44228, it has a similar attack vector, abusing attacker-controlled lookups in logged data. The impact of this vulnerability is Denial of Service (DoS). The Intelligence Stream has been updated with a Pre-Filled CVE entry for CVE-2021-45105, and Prisma Cloud customers can detect this vulnerability.

The risk can only be fully remediated by upgrading to Log4J 2.17.0, 2.12.3 (for Java 7) or 2.3.1 (for Java 6).

Another mitigation strategy suggested in the Log4j security notes is to change the configuration as follows:

• In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).
• Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.

Update 5: On December 17, CVE-2021-45046 CVSS base score changed from 3.7 (low) to 9.10 (high). Additional exploits were found against the Log4j 2.15.0 release that could lead to information leaks, RCE (remote code execution), and LCE (local code execution) attacks. 

In addition to 2.16.0, also 2.12.2 (for Java 7) and 2.3.1 (for Java 6) remediates this issue.

Update 6: On December 28, a new vulnerability for log4j was discovered, and has been assigned with CVE-2021-44832. The impact of this vulnerability is Arbitrary Code Execution, however its severity is lower than Log4Shell, as a modification of the configuration is required.

The Intelligence Stream has been updated with a Pre-Filled CVE entry for CVE-2021-44832, and Prisma Cloud customers can detect this vulnerability. Upgrading to versions 2.17.1 (for Java 8 and later),  2.12.4 (for Java 7), or 2.3.2 (for Java 6) will mitigate this vulnerability.

Query Your Environment for Hosts With This Risk

Prisma Cloud’s RQL (Resource Query Language) provides a quick and easy way to query for resources impacted. In this case users can utilize the Prisma platform's capabilities to isolate assets with vulnerabilities and also prioritize it further by looking for internet exposed assets receiving traffic. 

Know the hosts in your cloud that has the specific vulnerability CVE-2021-44228:

config from cloud.resource where finding.type = 'Host Vulnerability' AND protection.finding.name = 'CVE-2021-44228'

Know the Internet exposed hosts that are receiving traffic in your cloud and have the specific vulnerability CVE-2021-44228:

network from vpc.flow_record where bytes > 0 AND source.resource IN ( resource where finding.type IN ( 'Host Vulnerability' ) AND finding.source IN ( 'Prisma Cloud' ) AND finding.name IN ('CVE-2021-44228') ) AND destination.publicnetwork IN ('Internet IPs', 'Suspicious IPs')

Runtime Protection for Containers

Protecting running containerized applications is a core requirement for defense-in-depth against Log4Shell. Prisma Cloud automatically builds runtime models of your images and uses this information to let you create runtime policies that prevent anomalous processes from being deployed and run.

The runtime policy for a vulnerable image is shown below with the Processes and File System tabs highlighted.

With this policy in place, we can see that the download of an external object is blocked due to a violation of the runtime policy.

Web Application and API Security Protections

Not only does Prisma Cloud detect components affected by the vulnerability, but it can also detect and actively block exploitation attempts. Our researchers crafted a special rule that can catch exploitation attempts of this vulnerability. We tested this rule against known exploits and exploits used in the wild, and it was able to prevent these exploitation attempts.

Two virtual patches are available for Prisma Cloud Web Application and API Security (WAAS) Enterprise users and Compute users running the latest console version (21.08.525, Update 2). We recommend users enable these virtual patch on Prevent in their existing applications by opening them, navigating to custom rules, and selecting the virtual patches (Log4Shell - CVE-2021-45046, Log4Shell - CVE-2021-44228).

Users running older releases can create a custom rule for this rule by navigating to Defend > Custom rules > WAAS > Add rule.

Use the following syntax in the rule content:

req.path contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.header_names contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.header_values contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.query_param_names contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.query_param_values contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.body_param_values contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.body contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.cookie_names contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.cookie_values contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.http_method contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.http_scheme contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

or

req.http_version contains /(?i)(?:\$|\%24)\s*?(?:\{|\%7b)\s*?(jndi\s*?(?:\:|\%3a)|(?:\$|\%24)\s*?(?:\{|\%7b)[\s\S]*?(?:\}|\%7d)|[jndi]*?(?:\$|\%24)(?:\{|\%7d)(?:(?:lower:|upper:)|(?:.*?:)*?(?:-[jndi]?|(?:\}|\%7d))))/

The first and only true remedy to this vulnerability is updating all vulnerable instances. However, attackers will continue to deliver exploit payloads even long after the issue is fixed, and WAAS can help detect and monitor these attackers and drop their connections.

Identity-Based Microsegmentation to Restrict Network Access

Preventing network access to unknown or untrusted resources, such as a malicious LDAP server, is critical for protecting against Log4Shell. Microsegmentation can enforce least-privileged network access on workloads to deny outbound requests to unauthorized destinations.

With Prisma Cloud Enterprise Edition, users enforce Identity-Based Microsegmentation policy where Enforcer agents are deployed.

In the screenshots below, you can see a microsegmentation policy in place that allows traffic from the Internet to the frontend pod, but it only allows this same pod to initiate connections with the backend resources over the port tcp/80. Other traffic is implicitly denied.

By policy, the attacker is able to reach the vulnerable container from the internet; however, the attack is prevented because the pod is not authorized to communicate with the malicious LDAP server.

And we can view the same flow data in more detail to understand what happened and why.

Summary

Log4Shell is one of the most severe vulnerabilities published in recent years. Log4j 2 is commonly used in Java applications and exploitation of the issue is straightforward. Therefore, we estimate its impact will continue to be seen long after its discovery, as vulnerable instances will continue to be open to the wild. Security teams need to take action to discover all vulnerable instances and patch this vulnerability as soon as possible.

Prisma Cloud can help in detecting all vulnerable instances in your deployments. Prisma Cloud may also be configured to fully prevent running any images or hosts vulnerable to this issue.

A complete proof-of-concept of Prisma Cloud protections for Log4J exploits, including runtime and WAAS protections, can be found below: