As Kubernetes has become a widely popular and critical infrastructure component in the modern software stack for small to large organizations, it has also become more susceptible to attacks. Developers typically use a Kubernetes deployment with other cloud-native components to make a working system. Unfortunately, a more complex infrastructure with more components increases the surface and scope vulnerable to attacks. 

Figure 1: Trend of Kubernetes vulnerabilities (Source: cve.mitre.org).

In Red Hat’s 2022 State of Kubernetes Security report, over the course of the previous year, 93% of those surveyed reported at least one incident impacting a Kubernetes environment. Out of the total security incidents reported by participants, 53% were due to misconfigurations and 38% were due to the exploitation of vulnerabilities. The trend shows an increase in vulnerabilities mainly due to an increasing attack surface area and complexity in vulnerability management. Understandably, this is a worry for the industry. 

In this article, we discuss Kubernetes vulnerabilities and what we can learn from them. To formally understand what constitutes a vulnerability, let’s look into the standard definition from NIST SP 800-53 standard: “A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system(s) security policy.” 

Where to Look for Kubernetes Vulnerabilities

There are various trusted data sources responsible for identifying, collecting and publishing vulnerabilities in the public domain. The main ones are the National Vulnerability Database (NVD), CVE database, GitHub security advisories, Exploit-DB, vendor notifications and official project announcements. 

Here is the list of sources for Kubernetes vulnerabilities:

Classification of Vulnerabilities Relevant to Kubernetes

​​Denial of Service

This vulnerability occurs when legitimate users or clients are unable to access the service or system due to the actions of a malicious threat actor. For example, let’s say someone is querying your Kubernetes API server concurrently with numerous requests; the API server might then become unresponsive to other legitimate requests.

Privilege Escalation 

Certain system weaknesses allow an attacker to gain unauthorized access inside the security perimeter. In Kubernetes, container escape is a common weakness and, when exploited, a hacker can gain access to the host with elevated privileges. 

Bypass Vulnerabilities

This is a broader term for a type of vulnerability that includes authentication bypass, execution code bypass, permission bypass, etc.

Buffer Overflows

Often, a buffer overflow can happen due to bugs in the code such as poor handling of out-of-bounds memory buffers. It allows malicious actors to access the memory of other co-hosted processes and leak unwanted information.

Arbitrary Code Execution

Here, an attacker exploits a flaw in the code and uses it to execute arbitrary malignant code, often to gain elevated access, network access or control of the host system.

Directory or File Traversal

With this vulnerability, a hacker can take advantage of a weakness in the code to traverse arbitrary files and directories on the host system or network.

Vulnerabilities Seen in 2022 

CVE-2022-0811 – Container Escape Vulnerability in CRI-O Runtime (cr8escape)

This vulnerability in CRI-O, a container runtime used by Kubernetes, was disclosed by CrowdStrike security researchers earlier this year with a CVE score of 9.0 (critical). It lets a malicious actor with access create a pod in a Kubernetes cluster to set arbitrary kernel parameters on the host by abusing the kernel.core_pattern parameter. This vulnerability allows hackers to escape from the Kubernetes container and gain root access to the host, potentially enabling them to deploy malware, exfiltrate data and achieve lateral movement in the cluster. 

Ways to Prevent

  • Use policies to block unsafe access to kernel resources, such as Pod Security Admission Controllers, which have replaced Pod Security Policies from Kubernetes 1.25. You can also use third-party admission controllers like this one from Kyverno. 
  • Regularly scan and audit the cluster and patch vulnerabilities as soon as patches are released. 

CVE-2022-1708 – Node DOS by Way of Memory Exhaustion Through execSync Request

This is a vulnerability in the CRI-O container runtime that causes memory or disk space exhaustion on the node, thus impacting system availability. It was given a CVE score of 7.5 (high). Whoever has access to Kubernetes API can invoke execSync, which runs a command or gets the log from the container synchronously. If the output of the command is very large, it may fill up the memory or disk and cause unavailability of the node or other co-hosted services.

CVE-2022-31030 is also similar to CVE-2022-1708, but CVE-2022-31030 is due to the containerd container runtime instead of CRI-O. 

Ways to Prevent

  • Use the principle of least privilege to reduce the risk of attack. If you don’t give a privilege to run the “exec” command on the pod or give minimal privileges to the service account used by the applications interacting with the Kubernetes API server, an attacker won’t be able to exploit the vulnerability.
  • Implement patches as soon as they are released. 

CVE-2022-29165 – ArgoCD Authentication Bypass

This critical vulnerability with the highest score of 10.0 created panic for users of ArgoCD, a popular GitOps continuous delivery tool that is used to deploy applications on Kubernetes clusters. The vulnerability allows unauthenticated users to gain anonymous access, enabling them to impersonate any other user, including admins, by sending a specifically crafted JSON Web Token (JWT). 

The exploitation was easy, as the attacker didn’t need an account in ArgoCD. By default, ArgoCD service accounts get a cluster-admin role, thus giving the attacker full access to the Kubernetes cluster.

Ways to Prevent

  • Disable anonymous access to ArgoCD.
  • Follow the principle of least privilege for application service accounts.
  • Keep critical component endpoints behind a secure perimeter to which only trusted people are granted access.

CVE-2022-24348 – A Zero-Day Critical Vulnerability in ArgoCD

Another critical vulnerability in the ArgoCD project was discovered at the start of the year. This one, if exploited, can leak sensitive information such as application credentials, API keys and secrets from other applications. This zero-day vulnerability lets malicious actors bypass the directory traversal checks and gain access to other confidential information stored in ArgoCD. We previously discussed this vulnerability in detail. 

Ways to Prevent

  • Have a continuous scanning solution in place to detect vulnerabilities.
  • Implement patches as soon as they are released.

CVE-2022-23648 – Arbitrary Host File Access in Containerd

This vulnerability is found in containerd versions 1.6.1, 1.5.10 and 1.14.12 and allows attackers to read the arbitrary host file. Thus, an attacker can read confidential files such as kubelet private keys and can access the Kubernetes API server/etcd database to exfiltrate information.

Ways to Prevent

  • Have a continuous scanning solution in place to detect vulnerabilities.
  • Implement patches as soon as they are released.

CVE-2022-0185 – Linux Kernel Container Escape

A heap-based buffer overflow flaw in the File Context API in Linux can lead to out-of-bounds writes. A malicious actor with local access can then cause a denial of service attack or run arbitrary code on the host. To detect this vulnerability exposure in Kubernetes, you would need to find the pods with CAP_SYS_ADMIN capabilities. Learn more about CVE-2022-0185 here. 

Ways to Prevent

  • Limit the container capabilities in Kubernetes deployments. 
  • Deploy a matured detection tool that can quickly discover you are exposed and alert you to mitigate the risk.

Key Takeaways

Below are some of the key takeaways from the vulnerabilities discussed. 

Container escape is one of the most frequently exploited vulnerabilities in Kubernetes. Implementing security profiles such as AppArmor and SELinux, as well as pod security standards in your Kubernetes deployment can reduce exposure to attacks. You can also look into some guidance on how to secure a Kubernetes deployment.

Follow the principle of least privilege when assigning roles and privileges to your service accounts and users. This reduces the chance of an attacker getting excessive privileges on the cluster even if they have infiltrated it. 

Use the defense-in-depth technique to make it tougher for malicious actors to achieve lateral movement and exfiltrate data.

It is advisable to take frequent and continuous scans of your K8s manifest files, code repositories and clusters to find vulnerabilities. There are open source solutions that have controls to detect critical vulnerabilities.

Establish a process to update the software packages on your Kubernetes clusters regularly. After disclosure of vulnerabilities, attackers try to exploit targets that are not patched almost immediately. One such example was the Log4j vulnerability which was exploited 840,000 times in the first 72 hours.

Use container sandbox projects such as gVisor that can strengthen container boundaries and protect against container escape and privilege escalation by providing strong isolation in a multi-tenant system. 

Summary 

It is not always possible to completely avoid a vulnerability due to software bugs and unidentified weaknesses in the code that have passed through the testing and review process. 

But follow best practices to secure the platform and the software deployed on it can reduce the impact. We can also be more proactive in applying fixes by setting robust continuous deployment processes to patch vulnerabilities and using tools, including open source Kubernetes security platforms, to align with best practices. 

This CVE roundup was prepared by the research team at ARMO. 

References