August 20, 2024Ravie LakshmananVulnerability / Container Security

Cybersecurity researchers have discovered a vulnerability affecting Microsoft Azure Kubernetes Services. If successfully exploited, the vulnerability could allow an attacker to escalate privileges and gain access to credentials for services used by the cluster.

“An attacker executing commands in a Pod running within an affected Azure Kubernetes Services cluster could download the configuration used to provision the cluster node, extract the Transport Layer Security (TLS) bootstrap tokens, and perform a TLS bootstrap attack to read all secrets within the cluster,” Google-owned Mandiant said.

Clusters using “Azure CNI” for “Network Configuration” and “Azure” for “Network Policy” appear to be affected by the privilege escalation bug. Microsoft has addressed the issue after responsible disclosure.

The attack technique devised by the threat intelligence company revolves around gaining access to a little-known component called Azure WireServer to retrieve a key used to encrypt protected settings values ​​(“wireserver.key”) and using it to decrypt a provisioning script containing various secrets such as the following:

• KUBELET_CLIENT_CONTENT (Global 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 written to disk for use with the Kubernetes command-line tool kubectl to authenticate to the cluster,” said researchers Nick McClendon, Daniel McNamara, and Jacob Paullus.

“This account has minimal Kubernetes permissions in recently deployed Azure Kubernetes Service (AKS) clusters, but can view nodes in the cluster.”

TLS_BOOTSTRAP_TOKEN, on the other hand, can be used to enable a TLS bootstrap attack and ultimately gain access to all secrets used by running workloads. The attack does not require the pod to be running as root.

“Adopting a process to create restrictive NetworkPolicies that only grant access to required services prevents this entire class of attacks,” Mandiant said. “Privilege escalation via an undocumented service is prevented when the service is not accessible at all.”

The disclosure follows a new high-severity Kubernetes vulnerability (CVE-2024-7646, CVSS score: 8.8) affecting the ingress-nginx controller that could allow attackers to gain unauthorized access to sensitive cluster resources.

“The vulnerability is due to a flaw in the way ingress-nginx validates annotations on Ingress objects,” said security researcher Amit Schendel.

“The vulnerability allows an attacker to inject malicious content into certain annotations, bypassing intended validation checks. This could lead to arbitrary command injection and potential access to the credentials of the ingress-nginx controller, which in default configurations has access to all secrets in the cluster.”

It also follows the discovery of a design flaw in the Kubernetes git-sync project that could allow command injection in Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), and Linode.

“This design flaw could lead to data exfiltration of any file in the pod (including service account tokens) or to command execution with the git_sync user privilege,” Akamai researcher Tomer Peled said. “To exploit the flaw, an attacker would simply need to deploy a YAML file to the cluster, which is a low-privilege operation.”

There are no patches planned for this vulnerability, so it is imperative that organizations monitor their git-sync pods to determine what commands are being executed.

“Both of these vectors are due to a lack of input sanitization, which highlights the need for robust defenses regarding user input sanitization,” Peled said. “Blue team members should be on the lookout for unusual behavior from the gitsync user in their organizations.”