A security bug in the popular Kubernetes container management system allows attackers to remotely execute code with system privileges on Windows endpoints, potentially leading to the complete takeover of all Windows nodes within a system. Kubernetes clusters.
Akamai security researcher Tomer Peled discovered the flaw, which is tracked as CVE-2023-5528 and has a CVSS score of 7.2. The exploitation lies in the manipulation of Kubernetes volumes, a feature aimed at supporting sharing data between pods on a cluster or persistently storing it outside a pod’s lifecycle, he explained in a blog post published on March 13.
As an attack vector, attackers would need to create persistent pods and volumes on Windows nodes, which would allow them to gain administrator 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 change one parameter and apply 3 YAML files to achieve RCE on Windows endpoints,” Peled tells Dark Reading. The Kubernetes framework “uses YAML files for pretty much everything,” he wrote in the post.
Kubernetes clusters they are only affected if they use an in-tree storage plugin for Windows; however, “there are many different types of volumes that developers can use,” creating different attack scenarios, Peled noted in the post.
Default Kubernetes installations prior to version 1.28.4 running both on-premises deployments and Azure Kubernetes Service are vulnerable. The Kubernetes team has been alerted to the flaw and a patch is available to address it, which is highly recommended.
“Because the problem resides in the source code, this threat will remain active and exploitation will likely increase – which is why we strongly recommend patching the cluster even if it has no Windows nodes,” Peled wrote.
Following the defects
Peled discovered the flaw after an investigation into another vulnerability that shared the same root cause: insecure function call and lack of sanitization of user input in Kubernetes. That flaw was CVE-2023-3676, a command injection vulnerability that could be exploited by applying a malicious YAML file to the cluster. The discovery of this vulnerability led to the discovery of two other vulnerabilities, also caused by the lack of sanitization of the subPath parameter in YAML files, which creates pods with volumes and opens the opportunity for malicious code injection.
“At the 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 attempts, we managed to achieve a similar result: running commands as kubelet service (SYSTEM privileges),” he wrote.
Exploitation and patching
The proof of concept performed by the researchers focused on local volumes, one of the volume types within Kubernetes. When creating a pod that includes a local volume, the kubelet service will eventually hit a function with a cmd line call to “exec.command”, creating a symbolic link between the volume’s location on the node and the location within the pod.
Like many terminals, the Windows command prompt (cmd) allows the execution of two or more commands one 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 achieve this on local volumes, including the need to specify or create a persistentVolume, among others. However, once the volume is created, “a user can request storage using a persistentVolumeClaim,” she wrote. “This is where the injection can be given.”
The patch created for the flaw removes the injection opportunity by eliminating 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 originally intended,” she explained.
Is your system vulnerable?
Kubernetes has emerged as one of the most widely used open source systems for containers; however, it has also become one a primary objective for threat actors because of its vast potential for exploitation and access to organizational data. Additionally, the Kubernetes configuration itself often creates a vulnerable installation, providing a large attack surface for threat actors.
“Kubernetes is a very complex and robust tool,” says Peled. “On the one hand its robustness allows users to adapt their experience to the needs of their organization, but on the other hand it makes it very difficult to protect every aspect of it from both the developer and user point of view.”
Indeed, the discovery of CVE-2023-5528 and related flaws highlights for companies implementing Kubernetes “how crucial it is to verify Kubernetes configuration YAMLs, since input sanitization is missing in several areas of code in the same Kubernetes and its sidecar projects,” Peled wrote.
Following best practices like role-based access control (RBAC) and making sure clusters are updated “should also mitigate much of the known threats,” he tells Dark Reading.
An enterprise environment running Kubernetes is vulnerable to exploitation of the flaw only if a system version is earlier than 1.28.4 and the system is running Windows nodes. In this case, Akamai has provided administrators with a command to run to determine whether the system needs to be patched. If so, patching should take priority.
“If your Kubernetes cluster does not have Windows nodes, you should not rush to patch this specific vulnerability,” Peled noted. “But it’s still important to fix it when you have time.”
If immediately applying patches isn’t an option, Akamai does too is providing an Open Policy Agent (OPA) rule to help detect and block this type of behavior. OPA is an open source agent that allows users to receive data about traffic entering and leaving nodes and take policy-based actions on the data received.