Patch Now: Kubernetes RCE Flaw Allows Full Takeover of Windows Nodes

Attackers can remotely execute code with system privileges by exploiting a vulnerability in the source code of the open source container management system.

Kubernetes logo in blue on a white background on a mobile device screen
Source: Dennizn via Alamy Stock Photo

A security bug in the widely used Kubernetes container-management system allows attackers to remotely execute code with System privileges on Windows endpoints, potentially leading to full takeover of all Windows nodes within a Kubernetes cluster.

Akamai security researcher Tomer Peled discovered the flaw, which is tracked as CVE-2023-5528 and has a CVSS score of 7.2. Exploitation lies in manipulating Kubernetes volumes, a feature aimed at supporting the sharing of data between pods on a cluster, or storing it persistently outside of a pod's lifecycle, he explained in a blog post published March 13.

As an attack vector, attackers would need to create pods and persistent volumes on Windows nodes, which would allow them to escalate to admin privileges on those nodes, according to a GitHub listing for the flaw.

"It is very easy to exploit this vulnerability because an attacker would only need to modify a parameter and apply 3 YAML files to gain RCE over the Windows endpoints," Peled tells Dark Reading. The Kubernetes framework "uses YAML files for basically everything," he wrote in the post.

Kubernetes clusters are only affected if they are using an in-tree storage plugin for Windows; however, "there are many different volume types developers can use," creating different attack scenarios, Peled observed in the post.

Default installations of Kubernetes earlier than version 1.28.4 running both on-prem deployments and Azure Kubernetes Service are vulnerable. The Kubernetes team has been alerted of the flaw and there is a patch available for remediation, which is highly recommended.

"Since the issue lies within the source code, this threat will remain active and exploitation of it will likely increase — this is why we strongly advise patching your cluster even if it doesn't have any Windows nodes," Peled wrote.

Following the Flaws

Peled discovered the flaw after an investigation of another vulnerability that shared the same root cause: insecure function call and lack of user input sanitization in Kubernetes. That flaw was CVE-2023-3676, a command injection vulnerability that could be exploited by applying a malicious YAML file onto the cluster. The discovery of this vulnerability led to the discovery of two others that also are caused by the lack of sanitization of the subPath parameter in YAML files, which creates pods with volumes and opens up an opportunity for a malicious code injection.

"At the tail end of that research, we noticed a potential place in the code that looked like it could lead to another command injection vulnerability," which ultimately became CVE-2023-5528, Peled explained.

"After several tries, we managed to achieve a similar outcome: executing commands as the kubelet service (SYSTEM privileges)," he wrote.

Exploitation and Patching

The proof of concept that the researchers executed focused on local volumes, one of the volume types within Kubernetes. While creating a pod that includes a local volume, the kubelet service will eventually reach a function with a cmd line call to "exec.command," creating a symlink between the location of the volume on the node and the location inside the pod.

Like many terminals, Windows' Command Prompt (cmd) allows for the execution of two or more commands one right after the other, as well as multiple commands in the same command line. "The fact that we can control one of the parameters in the cmd execution means that we can use command injection," Peled explained.

There are prerequisites to achieving this on local volumes, including the need to specify or create a persistentVolume, among others. However, once that volume is created, "a user can ask for storage space using a persistentVolumeClaim," he wrote. "This is where the injection can be placed."

The patch created for the flaw removes the opportunity for injection by deleting the cmd call, and replacing it with a native GO function that will perform the same operation to create the symlink. "Now, the GO 'os' library will only perform a symlink operation, as was intended initially," he explained.

Is Your System Vulnerable?

Kubernetes has emerged as one of the most widely used open source systems for containers; however, it also has become a prime target for threat actors due to its vast potential for exploitation and access to organizational data. Moreover, oftentimes Kubernetes configuration itself creates a vulnerable installation, providing a broad attack surface for threat actors.

"Kubernetes is a very complex and robust tool," Peled says. "On the one hand its robustness allows users to tailor their experience to their organization's needs, but on the other hand it makes it very hard to secure every aspect of it from both a developer or user standpoint."

Indeed, the discovery of CVE-2023-5528 and its related flaws highlights for enterprises deploying Kubernetes "how crucial it is to verify Kubernetes configuration YAMLs, since input sanitization is lacking in several code areas in Kubernetes itself and its sidecar projects," Peled wrote.

Following best practices such as role-based access control (RBAC) and making sure clusters are up to date also "should mitigate a large portion of known threats," he tells Dark Reading.

An enterprise environment running Kubernetes is vulnerable to exploit of the flaw only if a version of the system is earlier than 1.28.4 and the system is running Windows nodes. If this is the case, Akamai provided a command for administrators to run to determine if the system should be patched. If so, the patching should be prioritized.  

"If your Kubernetes cluster doesn't have any Windows nodes, you don't have to rush to patch this specific vulnerability," Peled noted. "But it's important to patch it anyway when you have the time."

If immediate patching is not an option, Akamai also is providing an Open Policy Agent (OPA) rule to help detect and block this kind of behavior. OPA is an open source agent that allows users to receive data on traffic going in and out of nodes and take policy-based actions on the received data.

About the Author(s)

Elizabeth Montalbano, Contributing Writer

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights