Critical Vulnerability in Apache Log4j 2 (CVE-2021-44228)

A critical, high severity vulnerability (CVSS v3.0 10/10 rating) in the Apache Log4j open source Java logging library was disclosed Thursday, December 9 on the foundation’s github page. On Wednesday, Dec 15 a new vulnerability CVE-2021-45046 was published and patched, according to this article. This was the result of an incomplete initial patch of CVE-2021-44228 which could be bypassed. On Dec 18 a third vulnerability CVE-2021-45105 was reported and is patched in v2.17.0. Enterprises are advised to immediately assess the likelihood of being affected by this vulnerability and, if potentially affected, to operate under an ‘assumed breach’ mentality to assess logs and review unusual network activity especially egress connections.

[Update 12/20/2021 8:15 am PT] A third Log4j vulnerability has been discovered and patched, CVE-2021-45105, which can result in denial of service (DoS) attacks. This has been rated a high CVSS of 7.5 and is patched in v2.17.0. The NeuVector CVE database to detect all 3 vulnerabilities is v 2.531 and higher.

[Update 12/15/2021 7:00 am PT] A new Log4j 2 vulnerability CVE-2021-45046 has been discovered and patched.

[Update 12/13/2021 9:00 am PT] Added instructions for blocking this vulnerability with Admission Control rules.

[Update 12/13/2021 7:30 am PT] See this post for the SUSE/Rancher statement on this CVE.

[Update 12/12/2021 4:00 pm PT] This post is updated to include scan instructions in NeuVector to detect this CVE. Please update to the latest CVE database from NeuVector v2.531 or later to scan for this CVE.

Synopsis:

• The Log4shell vulnerability CVE-2021-44228 and CVE-2021-45046 allows for unauthenticated remote code execution (RCE) in the Apache Log4j 2 library which is present in many enterprise applications.  CVE-2021-45105 allows for denial of service attacks.
• Scan your container images and running containers immediately with NeuVector to determine if Log4j present as a component. If it is detected as a vulnerable version, immediately update the image to use Log4j 2.17.0 (not 2.16.0 or 2.15.0) and redeploy the containers.
• For Log4j releases >=2.10 this vulnerability can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
• Zero trust egress controls are the most effective way to prevent exploitation in running containers. Make sure aggressive egress controls are in place with Protect mode (blocking) enabled in NeuVector for any containers with external access or with this CVE detected. In addition, NeuVector may also detect new suspicious processes associated with a RCE.
• Additional protections should be considered in NeuVector:
  • Add an Admission Control rule to block any deployments of images with CVE-2021-44228
  • Implement WAF like detection rules using the DPI function in DLP to detect and/or block attempted incoming exploits
  • Implement Protect mode for any containers with potential exposure to ensure:
    • No egress/external connections are in the Allow list, or
    • External connections are explicitly allowed to specific DNS hostnames, IP addresses, and for only required application protocol(s)
• The NeuVector container security platform software and its containers itself are not vulnerable to this exploit.

CVE-2021-44228 Background

This vulnerability was discovered by Chen Zhaojun of  the Alibaba Cloud Security Team and impacts Apache Log4j 2 versions 2.0 to 2.14.1. There are reports from Log4j maintainers that the 1.x series may also vulnerable to this issue when using the JMS Appender class. Log4j 2, a logging service, is widely used in many enterprise applications and is present, as a dependency, in many services, including cloud services.

Because of the widespread use and distribution of the Log4j library in enterprise java software, and the relative ease of how this vulnerability can be exploited, it is expected that the risk to enterprises is very high for potential exploitation. This is likely to be the most critical vulnerability since the ShellShock and Heartbleed vulnerabilities.

Vulnerability in the JNDILookup plugin

According the NVD description for this vulnerability:

“Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.”

Please see this post by CloudFlare or this post by Fastly for more detailed explanations of the exploit.

Scan Images Using NeuVector for Log4j Modules

NeuVector will scan images and running containers for the vulnerability. In order to report the CVE presence, please make sure you have updated the CVE database to the latest version by updating the scanner container(s) running. All 3 vulnerabilities have been added to the NeuVector CVE database as of v2.531. It will be reported on container images that are using the vulnerability log4j jar file of version between 2.0 and 2.16.x. 

To test this scanning detection  you can use NeuVector to scan the vulnerable image sample: elastic/logstash:7.13.3. For example, this screen shot shows the detection:

In addition, you can review image scans to determine if log4j appears in the component list (Modules) in Assets -> Registries for each image. If reviewing the scan results manually, it will look something like this:
{“version”: “2.14.0”, “source”: “jar”, “name”:”org.apache.logging.log4j.log4j”}

Use the version retrieved to identify if you are using a vulnerable log4j version. If it is detected as a vulnerable version, immediately update the image to use Log4j 2.17.0 (not 2.16.0 or 2.15.0) and redeploy the containers.

Zero Trust Security Controls

Modern container and Kubernetes cloud deployments are based on a declarative model, where in the security context this means that the allowed behavior of a container can be declared. This enables only trusted network connections, processes and file activity to occur for each specified deployment (workload). This ‘zero-trust’ model ensures that only allowed activity occurs, and everything else is untrusted, and can be alerted or blocked.

The NeuVector container security platform is based on zero-trust controls for network, process and file activity, and when properly configured can protect against RCE, external connections, suspicious processes such as remote shells etc.

Egress control is a critical security measure, especially in Kubernetes, to prevent ‘phone home’ connections, connections to command and control servers, and the resulting download of malicious code. With zero-trust network rules, all allowed network connections must be declared and explicitly authorized, whether they are east-west (internal) or ingress/egress. Additional protections in NeuVector allow restrictions of egress traffic by limiting destinations to known trusted DNS names, IP addresses, and using specific application protocols (using Layer7 network security).

Using NeuVector Admission Control to Block CVE-2021-44228 (etc.) Deployments

Add an admission control rule to block any deployment with this vulnerability detected in the image scan, like this:

“CVE names contains any in {CVE-2021-44228} or {CVE-2021-45046} or {CVE-2021-45105}”

Attempted deployments will result in blocking in Protect mode and notification in Monitor mode, which will look like this in the Notifications -> Risk Reports event log:

Be sure to require that all images be scanned by NeuVector in order to prevent vulnerable deployments. This can be done with an additional Admission Control rule that requires all images to be scanned.

Using NeuVector Deep Packet Inspection WAF Rules to Detect Exploits

Using Deep Packet Inspection (DPI) for container network traffic, NeuVector able to inspect network connection attempts and payloads for malicious traffic. This capability