Vulnerability Discovered on Azure Kubernetes: TLS Bootstrap

Cybersecurity researchers have revealed a vulnerability affecting Microsoft Azure Kubernetes Services (AKS), which, if successfully exploited, could allow an attacker to elevate their privileges and access the credentials of services used by the cluster.

The new Azure Kubernetes vulnerability

“An attacker with the ability to execute commands on a Pod running within an affected Azure Kubernetes Services cluster could download the configuration used to provision the cluster node, extract Transport Security (TLS) bootstrap tokens and perform a TLS bootstrap attack to read all secrets inside the cluster“, has declared Mandiant, owned by Google.

Clusters using “Azure CNI” for “Network Configuration” and “Azure” for “Network Policy” have been found vulnerable to this privilege escalation bug; Microsoft addressed the issue following a responsible report.

The new cyber attack technique

The attack technique developed by the threat intelligence firm relies 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 decrypt a provisioning script that includes several secrets, such as the following:

• KUBELET_CLIENT_CONTENT (Generic Node TLS Key)
• KUBELET_CLIENT_CERT_CONTENT (Generic Node TLS Certificate)
• KUBELET_CA_CRT (Kubernetes CA Certificate)
• TLS_BOOTSTRAP_TOKEN (Bootstrap TLS Authentication Token)

“The KUBELET_CLIENT_CONTENT, KUBELET_CLIENT_CERT_CONTENT and KUBELET_CA_CRT can be decoded to Base64 and written to disk for use with the Kubernetes command line tool, kubectlto authenticate to the cluster“, explained researchers Nick McClendon, Daniel McNamara and Jacob Paullus, who then added: “This account has minimal Kubernetes permissions on newly deployed Azure Kubernetes Service (AKS) clusters, but can still list nodes in the cluster.”

The TLS_BOOTSTRAP_TOKEN could be used to enable a TLS bootstrap attack and ultimately gain access to all secrets used by the running workloads. The attack does not require the pod to run as root.

“Adopting a process to create Network Policies “A restrictive approach that allows access only to requested services prevents this entire class of attacks,” Mandiant said. “Elevation of privilege via an undocumented service is prevented when the service cannot be accessed in any way.”

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

“The vulnerability stems from a flaw in the way ingress-nginx validates annotations on Ingress objects.“, has declared security researcher Amit Schendel, adding: “The vulnerability allows an attacker to inject malicious content into certain annotations, bypassing intended validation checks. This can 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.“

This also follows the discovery of a design flaw in the project Kubernetes git sync which could enable command injection through Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), and Linode.

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

There are no planned patches for this vulnerability, making it crucial that organizations examine their git-sync pods to determine which commands are being executed.

“Both vectors are due to a lack of input sanitization, which highlights the need for a robust defense in regards to user input sanitization.“, Peled said. “Security team members should be alert to unusual behavior from the git_sync user in their organizations.”