Kubernetes Vulnerability Allows Remote Code Execution

A severe vulnerability, tracked as CVE-2024-9042, has been discovered in Kubernetes, allowing attackers to execute arbitrary code with SYSTEM-level privileges on Windows nodes in affected clusters. This flaw, uncovered by Akamai security researcher Tomer Peled, revolves around a weakness in Kubernetes’ beta logging feature, “Log Query.”

Summary of the Issue

The vulnerability resides in Kubernetes’ Log Query functionality, designed to enable users to access system logs from remote nodes via the Kubernetes API. However, this feature introduced a critical flaw that exposes Windows nodes to remote code execution (RCE). Attackers can exploit this vulnerability by sending a carefully crafted HTTP GET request that injects malicious commands, potentially allowing them to take full control of all Windows nodes within the cluster.

How the Attack Works

The issue stems from the inadequate input validation within the Log Query feature, specifically within the pattern parameter of the API endpoint. This flaw allows attackers to inject arbitrary PowerShell commands into the system. A simple curl request, for example, could execute the injected code:

curl "/api/v1/nodes//proxy/logs/?query=nssm&pattern=’$(Start-process cmd)’"

By exploiting this weakness, attackers can run malicious commands remotely on Windows nodes, potentially escalating their privileges to SYSTEM level, which grants full control over the affected node.

Scope of the Vulnerability

This vulnerability impacts several Kubernetes versions, including:

• v1.32.0
• v1.31.0 to v1.31.4
• v1.30.0 to v1.30.8
• v1.29.12 and earlier

For an attack to succeed, certain conditions must be met:

• The cluster must have Windows nodes.
• The beta “Log Query” feature must be enabled.
• The Kubernetes version must be older than v1.32.1.

While the CVSS score for this vulnerability is 5.9 (medium), its potential impact is far-reaching. If exploited, attackers could gain SYSTEM privileges on all Windows nodes within the cluster, leading to a complete node takeover. This could enable them to pivot and escalate attacks within the entire Kubernetes environment, risking widespread data exposure and unauthorized access.

Potential Impact

The exploitation of CVE-2024-9042 can result in:

• Full System Compromise: Attacker gains full control over Windows nodes with SYSTEM privileges.
• Cluster-Wide Security Breach: Once a node is compromised, the attacker may use it as a launching pad to target other parts of the Kubernetes cluster.
• Sensitive Data Exposure: Any sensitive data on the compromised nodes could be at risk of theft or modification.

Despite its medium CVSS score, the vulnerability poses a significant risk, especially due to the simplicity of exploitation and the prevalence of Kubernetes clusters in enterprise environments.

Affected Kubernetes Versions

The vulnerability affects Kubernetes versions:

• v1.32.0
• v1.31.0 to v1.31.4
• v1.30.0 to v1.30.8
• v1.29.12 and earlier

Clusters running these versions with Windows nodes and the Log Query feature enabled are vulnerable to this RCE flaw.

Patches and Mitigation

Kubernetes has released patches for the affected versions to address this issue:

• v1.32.1
• v1.31.5
• v1.30.9
• v1.29.13

Administrators are strongly advised to upgrade to these patched versions immediately to protect their systems.

Additional Mitigation Steps

For organizations that cannot immediately upgrade, there are several steps they can take to mitigate the risk:

1. Disable Log Query: If the feature is not essential, disable the Log Query functionality entirely.
2. Limit Access with RBAC: Use Role-Based Access Control (RBAC) to restrict access to the sensitive /logs API endpoint, preventing unauthorized queries.
3. Monitor for Suspicious Activity: Administrators should actively monitor their cluster logs for unusual requests targeting the /logs endpoint, especially those with suspicious patterns or unexpected inputs.

In addition, security teams should audit their systems for any signs of exploitation. Reviewing audit logs for strange requests to the /logs endpoint may help identify early attempts to exploit this vulnerability.