Researchers Uncover TLS Bootstrap Assault on Azure Kubernetes Clusters

Aug 20, 2024Ravie LakshmananVulnerability / Container Safety

Cybersecurity researchers have disclosed a safety flaw impacting Microsoft Azure Kubernetes Providers that, if efficiently exploited, may enable an attacker to escalate their privileges and entry credentials for companies utilized 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 mentioned.

Clusters utilizing “Azure CNI” for the “Network configuration” and “Azure” for the “Network Policy” have been discovered to be impacted by the privilege escalation bug. Microsoft has since addressed the problem following accountable disclosure.

Cybersecurity

The assault method devised by the menace intelligence agency hinges on accessing a little-known part referred to as Azure WireServer to request a key used to encrypt protected settings values (“wireserver.key”) and use it to decode a provisioning script that features a number of secrets and techniques equivalent to follows –

  • KUBELET_CLIENT_CONTENT (Generic Node TLS Key)
  • KUBELET_CLIENT_CERT_CONTENT (Generic Node TLS Certificates)
  • KUBELET_CA_CRT (Kubernetes CA Certificates)
  • 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 mentioned.

“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, however, could possibly be used to allow a TLS bootstrap assault and finally acquire entry to all secrets and techniques utilized by operating workloads. The assault doesn’t require the pod to be operating as root.

“Adopting a process to create restrictive NetworkPolicies that allow access only to required services prevents this entire attack class,” Mandiant mentioned. “Privilege escalation via an undocumented service is prevented when the service cannot be accessed at all.”

The disclosure comes as Kubernetes safety platform ARMO highlighted a brand new high-severity Kubernetes flaw (CVE-2024-7646, CVSS rating: 8.8) that impacts the ingress-nginx controller and will allow a malicious actor to realize unauthorized entry to delicate cluster sources.

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

“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.”

Cybersecurity

It additionally follows the invention of a design flaw within the Kubernetes git-sync undertaking that might enable for command injection throughout 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 mentioned. “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 aren’t any patches being deliberate for the vulnerability, making it essential that organizations audit their git-sync pods to find out what instructions 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 mentioned. “Blue team members should be on the lookout for unusual behavior coming from the gitsync user in their organizations.”

Discovered this text attention-grabbing? Comply with us on Twitter and LinkedIn to learn extra unique content material we publish.

Recent articles

Grasp Certificates Administration: Be part of This Webinar on Crypto Agility and Finest Practices

Nov 15, 2024The Hacker InformationWebinar / Cyber Security Within the...

9 Worthwhile Product Launch Templates for Busy Leaders

Launching a product doesn’t should really feel like blindly...

How Runtime Insights Assist with Container Safety

Containers are a key constructing block for cloud workloads,...