December 16, 2021

Protect your Kubernetes clusters against Log4shell

A zero-day vulnerability in the Apache Software Foundation Log4j component ((CVE-2021-44228 & CVE-2021-45046), known as Log4j or Log4Shell, is actively being targeted in the wild. It has been assigned the highest “critical” severity rating with a risk score of 10 (the maximum). Log4j is a module used in the development of many Java/J2EE applications. In this post, we will focus solely on Kubernetes security and how to detect and mitigate affected container images. 

CVE-2021-44228 Log4shell - Log4j 

image-20211216142405-4

A zero-day vulnerability in the Apache Software Foundation Log4j component ((CVE-2021-44228 & CVE-2021-45046), known as Log4j or Log4Shell, is actively being targeted in the wild. It has been assigned the highest “critical” severity rating with a risk score of 10 (the maximum). Log4j is a module used in the development of many Java/J2EE applications.

In a previous blog post, we covered protecting applications running on bare metal or in a traditional VM for endpoints, workloads, and networks. In this post, we will focus solely on Kubernetes security and how to detect and mitigate affected container images. 

How can you protect your organization?   

VMware Carbon Black Container enables enterprise-grade container security at the speed of DevSecOps by providing continuous visibility, security, and compliance for containerized applications from development to production—in any on-premises or public cloud environment. This solution provides security teams with visibility and the ability to enforce compliance while integrating seamlessly into existing DevSecOps processes to avoid adding operational complexity. With VMware, organizations can reduce risk, maintain compliance, and simplify security for Kubernetes environments at scale. This single pane of glass gives complete visibility into the security posture across Kubernetes clusters and namespaces, including:

•    Visibility into Kubernetes clusters and workload inventory
•    A combined view of all vulnerabilities, misconfigurations, and rules violations
•    Workload configuration risk reporting and governance
•    A consolidated risk score aggregated for all workload attributes to prioritize remediation

How can you protect your Kubernetes clusters from Log4Shell? 

If you want to protect your Kubernetes cluster, you must consider different axes of protection, detection, and response: 

  1. Are you vulnerable? 

  1. Are you impacted? 

  1. How to block the attack? 

To answer these questions, we will address them from a VMware Security lens.   

Using Carbon Black Container to check for container vulnerabilities 

Developers can manually scan for vulnerability in container images, but this command-line tool can be integrated into your CI/CD pipeline, too.

image-20211217150528-1

Then the scan result is available in the VMware Carbon Black Cloud console: 

image-20211217150535-2

And the vulnerability Dashboard shows all images and workloads affected by the vulnerability CVE-2021-44228 and the new CVE-2021-45046.

image-20211217150546-3

Are your Kubernetes clusters impacted? How to find out. 

To exploit these vulnerabilities an attacker must get an application that uses log4j to log a specific, crafted attack string that causes log4j to connect to a malicious LDAP server. It will then download, load, and run a malicious Java class, giving attackers access to your environment. The network map, part of the latest versions of VMware Carbon Black Cloud Container, is very useful in visualizing and auditing these types of ingress and egress connections:

image-20211217150603-4

Figure 1: Network Egress visibility 

How to block the vulnerability from your production applications 

To increase your operational confidence and ensure that your Kubernetes clusters are on the latest patch, mitigating the Log4Shell vulnerability, with VMware Carbon Black Container, you should configure your policy to block the deployment of ‘images not scanned’ and ‘images with critical vulnerabilities”.

image-20211217150615-5

Figure 2: Kubernetes policy to block the deployment of images with critical vulnerabilities 

You can then use micro-segmentation to block the download of the attack payload. 

If you have not created firewall rules “inside” your Kubernetes cluster, you can leverage the Network Map provided by VMware Carbon Black to create micro-segmentation rules, for example using NSX and Antrea. 

image-20211217150627-6

Figure 3: Network connections in a Kubernetes namespace 

Stay Up to Date on Log4Shell VMware News 

This post covers how you can use VMware Carbon Black Cloud Container to protect your containerized workloads. To also stay up to date on protecting your infrastructure please visit the VMware Security Advisory itself, VMSA-2021-0028, and subscribe to the VMSA mailing list for updates and future notices.

Follow all VMware Carbon Black threat research on the Log4Shell vulnerability in the Carbon Black User Exchange.

Filter Tags

Container Blog

Stephane List

Read More from the Author

Staff Technical Marketing Architect, VMware Security Stéphane has over twenty years’ experience in opensource. He has worked in both development and sales role in France for large companies and startups. He has participated in the development of many different Linux project from mobile phone to firewalls. Now with 10 years’ experience in security, he is architect at VMware Carbon Black for Linux and containers security.