Researchers Uncover TLS Bootstrap Attack on Azure Kubernetes Clusters

Aug 20, 2024Ravie LakshmananVulnerability / Container Security

Cybersecurity researchers have disclosed a security flaw impacting Microsoft Azure Kubernetes Services that, if successfully exploited, could allow an attacker to escalate their privileges and access credentials for services used by the cluster.

“An attacker with command execution 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 the “Network configuration” and “Azure” for the “Network Policy” have been found to be impacted by the privilege escalation bug. Microsoft has since addressed the issue following responsible disclosure.

The attack technique devised by the threat intelligence firm hinges on accessing a little-known component called Azure WireServer to request a key used to encrypt protected settings values (“wireserver.key”) and use it to decode a provisioning script that includes several secrets such as follows –

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

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

TLS_BOOTSTRAP_TOKEN, on the other hand, could 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 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.”

The disclosure comes as Kubernetes security platform ARMO highlighted a new high-severity Kubernetes flaw (CVE-2024-7646, CVSS score: 8.8) that affects the ingress-nginx controller and could permit a malicious actor to gain unauthorized access to sensitive cluster resources.

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

“The vulnerability allows an attacker to inject malicious content into certain annotations, bypassing the intended validation checks. This can lead to arbitrary command injection and potential access to the ingress-nginx controller’s credentials, 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 for command injection across Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), and Linode.

“This design flaw can cause either data exfiltration of any file in the pod (including service account tokens) or command execution with the git_sync user privileges,” Akamai researcher Tomer Peled said. “To exploit the flaw, all an attacker needs to do is apply a YAML file on the cluster, which is a low-privilege operation.”

There are no patches being planned for the vulnerability, making it crucial that organizations audit their git-sync pods to determine what commands are being run.

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