CVE-2023-30617 in Kruise
Summary
by MITRE • 01/03/2024
Kruise provides automated management of large-scale applications on Kubernetes. Starting in version 0.8.0 and prior to versions 1.3.1, 1.4.1, and 1.5.2, an attacker who has gained root privilege of the node that kruise-daemon run can leverage the kruise-daemon pod to list all secrets in the entire cluster. After that, the attacker can leverage the "captured" secrets (e.g. the kruise-manager service account token) to gain extra privileges such as pod modification. Versions 1.3.1, 1.4.1, and 1.5.2 fix this issue. A workaround is available. For users that do not require imagepulljob functions, they can modify kruise-daemon-role to drop the cluster level secret get/list privilege.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 01/23/2024
The vulnerability identified as CVE-2023-30617 affects Kruise, a Kubernetes extension for automated management of large-scale applications. This security flaw exists in versions 0.8.0 through 1.5.1 of the Kruise operator, creating a critical privilege escalation path for attackers who have already compromised a node running the kruise-daemon component. The vulnerability stems from overly permissive cluster-level permissions granted to the kruise-daemon pod, specifically the ability to list all secrets across the entire Kubernetes cluster. This represents a significant deviation from the principle of least privilege that should govern all Kubernetes components and aligns with CWE-276, which addresses improper privileges for system resources.
The technical exploitation of this vulnerability begins with an attacker gaining root access to a node where kruise-daemon is running, which typically occurs through a successful node compromise or container escape attack. Once the attacker has root-level access to the node, they can leverage the kruise-daemon pod's elevated permissions to enumerate all secrets within the cluster through the cluster-level secret listing capabilities. This enumeration process allows the attacker to discover sensitive information including service account tokens, database credentials, and other confidential data stored as Kubernetes secrets. The impact extends beyond mere information disclosure, as the captured secrets can be used to authenticate against the Kubernetes API server and escalate privileges to modify pods, deploy malicious workloads, or access other cluster resources.
The operational consequences of this vulnerability are severe for Kubernetes environments using Kruise, particularly those with compromised nodes or insufficient network segmentation. Attackers can leverage the captured service account tokens to perform actions such as creating new pods, modifying existing workloads, accessing sensitive data, or even establishing persistence within the cluster. This vulnerability maps to multiple ATT&CK techniques including T1078 for valid accounts, T1566 for phishing, and T1059 for command and scripting interpreter. The attack chain typically begins with initial compromise of a node, followed by privilege escalation through the kruise-daemon, and culminates in lateral movement and data exfiltration. Organizations running affected Kruise versions face a significant risk of cluster takeover, especially in environments where the kruise-daemon runs with elevated privileges or where node compromise is possible through unpatched vulnerabilities in the underlying infrastructure.
The fix for this vulnerability involves upgrading to versions 1.3.1, 1.4.1, or 1.5.2 of Kruise, which properly restrict the permissions granted to the kruise-daemon component. Prior to upgrading, administrators can implement a workaround by modifying the kruise-daemon-role to remove the cluster-level secret get/list privileges. This temporary solution aligns with the principle of least privilege and reduces the attack surface while maintaining operational functionality. Organizations should conduct immediate assessment of their Kruise deployments to identify affected versions and implement appropriate mitigations. The vulnerability highlights the importance of regular security auditing of Kubernetes RBAC configurations and the need for comprehensive monitoring of privilege escalation attempts. Security teams should also consider implementing network segmentation, pod security policies, and runtime protection mechanisms to limit the impact of potential node compromises and prevent lateral movement within the cluster.