Microsoft addressed a critical privilege escalation vulnerability in its managed Azure Kubernetes Service (AKS), which allowed attackers to gain access to credentials for various services used by the cluster.
Attackers could have exploited the issue to access sensitive information, steal data, and execute other malicious actions in an affected AKS cluster, Mandiant said in a report this week. The company had already discovered and reported the vulnerability to Microsoft.
No Privileges Required
The vulnerability affected AKS clusters using the Azure CNI and Azure Network Policy network configuration settings. An attacker with command execution privileges within any pod of an affected AKS cluster could have leveraged the flaw to download the configuration details for the node, including the TLS bootstrap tokens used during the initial setup of a Kubernetes node, Mandiant said. The tokens would have allowed an adversary to perform a TLS bootstrap attack and generate a legitimate kubelet certificate, which would have given them elevated privileges within the cluster and unauthorized access to all its contents.
Significantly, an attacker could have exploited the flaw without needing any special privileges, Mandiant said. “This attack did not require the pod to be running with hostNetwork set to true and does not require the pod to be running as root,” Mandiant researchers Nick McClendon, Daniel McNamara, and Jacob Paullus wrote in a blog post this week.
Undocumented WireServer Component
Mandiant identified the vulnerability — before Microsoft fixed it — as stemming from the ability for an attacker with command execution privileges on an AKS pod to access an undocumented Azure component called WireServer. Mandiant researchers found that by following an attack technique that CyberCX published in May 2023, they could recover TLS bootstrap tokens for the cluster from WireServer. “Given access to the WireServer and HostGAPlugin endpoint, an attacker could retrieve and decrypt the settings provided to a number of extensions, including the ‘Custom Script Extension,’ a service used to provide a virtual machine its initial configuration,” the Mandiant researchers wrote.
They described the issue as a manifestation of what happens when organizations deploy Kubernetes clusters without considering how an attacker with code execution rights within a pod might be able to leverage that access. There are multiple ways in which attackers can take over a pod, including by exploiting vulnerabilities in the applications running in a pod, during continuous integration processes, or via a compromised developer account.
Excessive Access
Without granular network policies, restrictions against unsafe workloads, and authentication requirements for internal services, an attacker with access to a pod in a Kubernetes cluster can access other pods and services on a Kubernetes cluster. This includes servers that contain configuration details, instance metadata, and credentials for services within the cluster and with other cloud services.
“Adopting a process to create restrictive NetworkPolicies that allow access only to required services prevents this entire attack class,” Mandiant said. “Privilege escalation via an undocumented service is prevented when the service cannot be accessed at all.”
Callie Guenther, senior manager, cyber threat research at Critical Start, said that though Microsoft has patched the issue, security teams must immediately audit their AKS configurations. This is especially true if they are using Azure CNI for network configuration and Azure for network policy, Guenther said in an emailed comment. “They should also rotate all Kubernetes secrets, enforce strict pod security policies, and implement robust logging and monitoring to detect any suspicious activities,” Guenther noted. “While this vulnerability is serious, requiring prompt action, it is a second-stage attack, meaning it needs prior access to a pod. Thus, it should be prioritized accordingly within the broader context of an organization’s threat landscape.”