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 a 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:
- Are you vulnerable?
- Are you impacted?
- How to block the attack?
To answer to these questions, we will address 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 in your CI/CD pipeline, too.
Then the scan result is available in VMware Carbon Black Cloud console:
And the vulnerability Dashboard shows all images and workloads affected by the vulnerability CVE-2021-44228, and the new CVE-2021-45046.
Are your Kubernetes clusters impacted? How do you 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:
(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”.
(Figure 2: Kubernetes policy to block 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.
(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.
