Akamai researchers recently discovered a high-severity vulnerability in Kubernetes tracked as CVE-2023-3676 (CVSS 8.8). This identification of this issue led to the discovery of two more vulnerabilities tracked as CVE-2023-3893, and CVE-2023-3955 (CVSS 8.8). All three vulnerabilities were caused by insecure function call and the lack of user input sanitization.
The vulnerability can be exploited to gain remote code execution with SYSTEM privileges on all Windows endpoints within a Kubernetes cluster. An attacker can trigger the issue by applying a malicious YAML file on the cluster.
The vulnerability impacts default installations of Kubernetes and was tested against both on-prem deployments and Azure Kubernetes Service.
The researchers noticed that the presence of “exec.Command” combined with unsanitized user-supplied could have created the condition for a command injection.
PowerShell allows users to evaluate values inside strings before they are used.
Any PowerShell command can be inserted between the parentheses and will be evaluated, including $(Start-Process cmd), $(Invoke-Expression exp), and other PowerShell treats.
An attacker can abuse the subPath subproperty in a YAML file to gain access to privileged data outside of the container. The subPath evaluation can be abused to reach the vulnerable code and execute arbitrary command with SYSTEM privileges (kubelet’s own context) from remote nodes, and gain control over all Windows nodes in the cluster
“CVE-2023-3676 requires low privileges and, therefore, sets a low bar for attackers: All they need to have is access to a node and apply privileges. As we discussed in this blog post, successful exploitation of this vulnerability will lead to remote code execution on any Windows node on the machine with SYSTEM privileges.” reads the advisory published by Akamai. “High impact coupled with ease of exploitation usually means that there is a higher chance of seeing this attack (and similar attacks) on organizations.
Akamai provided a proof-of-concept YAML file as well as an OPA rule for blocking this vulnerability.
Below is the disclosure timeline:
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, RCE)