The written word about the TLS Boot Launch Attack on Azure Kubernetes Clusters
Cybersecurity experts have brought to light a flaw in Microsoft Azure Kubernetes Services which, if successfully used, might permit a trespasser to heighten their privileges and access credentials for services utilized by the cluster.
“A cyber offender with command execution within a Pod established in an impacted Azure Kubernetes Services cluster might retrieve the configuration employed to set up the cluster node, extract the transport layer security (TLS) bootstrap tokens, and execute a TLS bootstrap strike to view all secrets within the cluster,” Google-owned Mandiant stated.
Clusters using “Azure CNI” for the “Network setup” and “Azure” for the “Network Policy” have been identified as experiencing the privilege escalation flaw. Microsoft has already taken care of the problem after being informed about it responsibly.
The strategy of attack formulated by the intelligence organization banks on accessing an obscure component called Azure WireServer to request a key employed to encrypt secured settings values (“wireserver.key”) and use it to decipher a provisioning script containing numerous secrets such as below –
- KUBELET_CLIENT_CONTENT (Universal Node TLS Key)
- KUBELET_CLIENT_CERT_CONTENT (Universal 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 are capable of being Base64 decoded and inscribed to disk to utilize with the Kubernetes command-line tool kubectl for authentication to the cluster,” researchers Nick McClendon, Daniel McNamara, and Jacob Paullus remarked.
“This account has minimal Kubernetes permissions in recently implemented Azure Kubernetes Service (AKS) clusters, but it can significantly list nodes in the cluster.”
TLS_BOOTSTRAP_TOKEN, on the flip side, could be applied to activate a TLS bootstrap attack and eventually access all secrets used by running processes. The attack does not mandate the pod to be operating as a root user.
“Implementing a method to compose restrictive NetworkPolicies that permit access solely to mandatory services prevents the entirety of this category of attacks,” Mandiant outlined. “Privilege escalation via an unrecognized service is averted when the service cannot be accessed at all.”
The revelation coincides with the Kubernetes security platform ARMO bringing to light a fresh high-severity Kubernetes flaw (CVE-2024-7646, CVSS scoring: 8.8) that influences the ingress-nginx controller and could allow a malevolent actor to acquire unwarranted access to sensitive cluster resources.
“The security vulnerability derives from a defect in how ingress-nginx validates annotations on Ingress objects,” security expert Amit Schendel asserted.
“The flaw allows a hacker to embed malevolent content into specific annotations, circumventing the planned validation checks. This can result in arbitrary command injection and potential access to the ingress-nginx controller’s credentials, which, in default setups, possesses access to all secrets in the cluster.”
This is further underscored by the disclosure of a structural defect in the Kubernetes git-sync project that could potentially allow for command injection across Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), and Linode.
“This structural flaw can lead to either the exfiltration of any file in the pod (inclusive of service account tokens) or command execution with the git_sync user rights,” Akamai researcher Tomer Peled shared. “To exploit this flaw, an attacker just needs to apply a YAML file on the cluster, which is an action of low privilege.”
No fixes are in the pipeline for this vulnerability, making it crucial for organizations to scrutinize their git-sync pods to understand the operations being performed.
“Both vectors stem from the absence of input sanitization, accentuating the necessity for a sturdy defense concerning user input sanitization,” Peled mentioned. “Detection teams need to pay attention to odd behavior emanating from the gitsync user within their organizations.”
About Author
