A privilege escalation vulnerability in Microsoft Azure Kubernetes Services could have allowed attackers to access sensitive information, such as credentials for services used by the cluster, Mandiant reports.
Impacting Azure Kubernetes Services clusters set to use Azure CNI for the network configuration and Azure for network policy, the issue could allow an attacker to access any secret on 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,” Mandiant explains.
The flaw, which could be exploited even if the pod did not run with hostNetwork enabled and did not have root privileges, was resolved by Microsoft after being notified via its vulnerability disclosure program.
Kubernetes clusters deployed without proper configurations in place, such as NetworkPolicies, could allow attackers to execute code on pods, access resources available to other pods, and compromise clusters, or even the on-premises network, Mandiant notes.
The internal cloud services for the worker nodes could also be exposed, including the metadata server, which “provides machine configuration and often the credentials used to identify the machine to the cloud provider”.
Accessible at http://169.254.169.254 across cloud providers, the metadata server can be used to bootstrap trust in Kubernetes nodes by delivering a static token to provisioned VMs, proving that the VMs should be part of the cluster and be issued a kubelet TLS certificate signed by the control plane CA.
However, the metadata services are network accessible and a network attacker could exploit vulnerabilities such as server-side request forgery (SSRF) bugs to expose the tokens.
“With possession of these bootstrap tokens, an attacker can create a kubelet certificate for their own machine and use those credentials to attack the control plane, steal secrets, and interfere with the workloads scheduled on their malicious ‘node’,” Mandiant explains.
In Azure, an undocumented component named WireServer can be used by attackers to request the key used to encrypt protected settings values, which is written to the wireserver.key that can be used to decrypt an encrypted settings blob returned from the undocumented HostGAPlugin to obtain the script used to provision the machine.
The script includes the template result of a provisioning script for Azure Kubernetes Service nodes, which contains various secrets as environment variables, including the generic node TLS key and certificate, the Kubernetes CA certificate, and the TLS bootstrap authentication token, which can be used for privilege escalation.
The secrets can be used to authenticate to the cluster, albeit with minimal privileges. The TLS bootstrap authentication token can be used in a TLS bootstrap attack to read and create ClientSigningRequests (CSR).
The TLS bootstrap token can be used to submit the CSR to the Kubernetes API, and Azure Kubernetes Services would automatically sign the CSR and generate an authentication certificate, which can then be validated and used to access secrets.
“The Node Authorizer grants permissions based on the workloads scheduled on the node, which includes the ability to read all secrets for a workload running on the node. This process can be repeated across all active nodes to gain access to all secrets used by running workloads,” Mandiant notes.
Related: OpenMetadata Vulnerabilities Exploited to Abuse Kubernetes Clusters for Cryptomining
Related: Microsoft Plugs Gaping Hole in Azure Kubernetes Service Confidential Containers
Related: Developers Warned of Critical Remote Code Execution Flaw in Quarkus Java Framework
Related: Azure Kubernetes Service Now Supports Confidential Containers
