Cybersecurity experts have unearthed a security flaw within Microsoft Azure Kubernetes Services, which, if successfully exploited, could allow a malicious actor to elevate their privileges and seize credentials for critical services employed by the cluster.
“An adversary who gains command execution within a Pod operating in a compromised Azure Kubernetes Services cluster could retrieve the configuration used to set up the cluster node, extract the transport layer security (TLS) bootstrap tokens, and initiate a TLS bootstrap assault, granting them access to all secrets housed within the cluster,” stated Mandiant, a subsidiary of Google.
Clusters that utilize “Azure CNI” for “Network Configuration” and “Azure” for “Network Policy” have been identified as susceptible to this privilege escalation flaw. Microsoft has since remedied the vulnerability following responsible disclosure.
The attack methodology conceived by the threat intelligence firm relies on exploiting a relatively obscure component known as Azure WireServer. This component is utilized to request a key that encrypts sensitive settings values (“wireserver.key”) and decrypts a provisioning script containing several critical secrets, including:
- KUBELET_CLIENT_CONTENT (Generic Node TLS Key)
- KUBELET_CLIENT_CERT_CONTENT (Generic Node TLS Certificate)
- KUBELET_CA_CRT (Kubernetes CA Certificate)
- TLS_BOOTSTRAP_TOKEN (TLS Bootstrap Authentication Token)
“KUBELET_CLIENT_CONTENT, KUBELET_CLIENT_CERT_CONTENT, and KUBELET_CA_CRT can be Base64 decoded and inscribed onto disk to be employed with the Kubernetes command-line utility kubectl for cluster authentication,” explained researchers Nick McClendon, Daniel McNamara, and Jacob Paullus.
“While this account possesses minimal Kubernetes permissions in recently deployed Azure Kubernetes Service (AKS) clusters, it can, notably, enumerate nodes within the cluster.”
Conversely, the TLS_BOOTSTRAP_TOKEN could facilitate a TLS bootstrap attack, ultimately granting the perpetrator access to all secrets utilized by active workloads. This attack does not necessitate the Pod running with root privileges.
“Implementing a process to craft restrictive NetworkPolicies that permit access solely to required services mitigates this entire category of attacks,” Mandiant advised. “Privilege escalation through an undocumented service is thwarted when access to the service is entirely blocked.”
This disclosure coincides with a report from Kubernetes security platform ARMO, highlighting a novel, high-severity Kubernetes vulnerability (CVE-2024-7646, CVSS score: 8.8) that impacts the ingress-nginx controller. This flaw could enable a malicious actor to gain unauthorized entry to sensitive cluster resources.
“The vulnerability originates from a defect in how ingress-nginx validates annotations on Ingress objects,” noted security researcher Amit Schendel.
“This vulnerability permits an attacker to inject harmful content into specific annotations, bypassing the intended validation mechanisms. Such an action could lead to arbitrary command injection and potential unauthorized access to the ingress-nginx controller’s credentials, which, by default, have access to all secrets within the cluster.”
This revelation follows the identification of a design flaw in the Kubernetes git-sync project, which could allow command injection across platforms like Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), and Linode.
“This design flaw could result in either data exfiltration of any file within the Pod (including service account tokens) or command execution with the privileges of the git_sync user,” reported Akamai researcher Tomer Peled. “To exploit the flaw, an attacker needs only to apply a YAML file to the cluster, a low-privilege operation.”
No patches are currently planned for this vulnerability, making it imperative for organizations to audit their git-sync Pods to ascertain the commands being executed.
“Both attack vectors stem from inadequate input sanitization, underscoring the necessity for rigorous defense mechanisms concerning user input sanitization,” Peled emphasized. “Blue team members should remain vigilant for any anomalous behavior emanating from the git_sync user within their organizations.”
