A newly discovered vulnerability in Microsoft Azure Kubernetes Services has been revealed by cybersecurity analysts. This flaw, if exploited successfully, can lead to an escalation of privileges for an attacker and unauthorized access to credentials for services utilized by the cluster.
“An intruder with command execution within a Pod operating within an affected Azure Kubernetes Services cluster could retrieve the configuration employed to provision the cluster node, extract the transport layer security (TLS) bootstrap tokens, and carry out a TLS bootstrap attack to view all secrets within the cluster,” Google-owned Mandiant mentioned.
The vulnerability affects clusters utilizing “Azure CNI” for the “Network configuration” and “Azure” for the “Network Policy”. Microsoft has promptly responded to the issue post its responsible disclosure.
The attack strategy outlined by the threat intelligence firm is based on accessing a lesser-known component termed Azure WireServer to request a key utilized for encrypting protected settings values (“wireserver.key”). This key is then used to decode a provisioning script that contains 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 (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 for authenticating to the cluster,” researchers Nick McClendon, Daniel McNamara, and Jacob Paullus elaborated.
“This account has minimal Kubernetes permissions in recently deployed Azure Kubernetes Service (AKS) clusters, but it can notably list nodes in the cluster.”
On the contrary, TLS_BOOTSTRAP_TOKEN could be leveraged to enable a TLS bootstrap attack and eventually obtain access to all secrets utilized by running workloads. This attack does not mandate the pod to be running as the root user.
“Implementing a procedure to generate restrictive NetworkPolicies that authorize access only to necessary services effectively thwarts this entire attack spectrum,” Mandiant stated. “Privilege escalation through an undocumented service is averted when the service remains inaccessible.”
The disclosure coincides with Kubernetes security platform ARMO highlighting a newly discovered high-severity Kubernetes vulnerability (CVE-2024-7646, CVSS score: 8.8) affecting the ingress-nginx controller, potentially granting unauthorized access to sensitive cluster resources.
“The vulnerability originates from a weakness in the manner ingress-nginx authenticates annotations on Ingress objects,” security researcher Amit Schendel explained.
“The flaw allows an attacker to insert malicious content into specific annotations, circumventing 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.”
This revelation comes on the heels of the identification of a design flaw in the Kubernetes git-sync project that could permit command injection across Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), and Linode.
“This design flaw has the potential to cause the exfiltration of any file within the pod (including service account tokens) or execute commands with the git_sync user privileges,” Akamai researcher Tomer Peled stated. “To exploit the flaw, all an attacker has to do is apply a YAML file on the cluster, which is considered a low-privilege operation.”
No patches are currently in the pipeline for this vulnerability, underscoring the importance of organizations conducting audits on their git-sync pods to ascertain the commands being executed.
“Both vulnerabilities stem from a lack of input sanitization, emphasizing the necessity of a robust defense mechanism concerning user input sanitization,” Peled emphasized. “Security teams need to remain vigilant for any anomalous activities originating from the gitsync user within their organizations.”
About Author
