Azure Kubernetes Services Vulnerability Let Attackers Escalate Privileges
- С сайта: Vulnerability(cybersecuritynews.com)
- Вернуться к списку новостей
С сайта: Vulnerability(cybersecuritynews.com)
Mandiant recently disclosed a critical vulnerability in Microsoft Azure Kubernetes Services (AKS) that could have allowed attackers to escalate privileges and access sensitive credentials within affected clusters. The vulnerability impacted AKS clusters using “Azure CNI” for network configuration and “Azure” for network policy.
An attacker with command execution in a Pod running within a vulnerable AKS cluster could have exploited this issue to download the configuration used to provision the cluster node.
The configuration contained transport layer security (TLS) bootstrap tokens that the attacker could extract and use to perform a TLS bootstrap attack. This would grant the attacker the ability to read all secrets within the cluster.
Notably, the attack did not require the compromised Pod to be running with hostNetwork enabled or as the root user. This significantly expanded the attack surface.
The attack involved accessing the undocumented Azure WireServer component at http://168.63.129.16/machine/?comp=goalstate and the HostGAPlugin endpoint at http://168.63.129.16:32526/vmSettings.
The attacker could retrieve a key from the WireServer to decrypt protected settings values. They could then request the JSON document from HostGAPlugin, parse it, and Base64 decode it to obtain the encrypted provisioning script (protected_settings.bin).
Using the WireServer key, the attacker could decrypt protected_settings.bin to access the cluster’s provisioning script (cse_cmd.sh). This script contained several secrets as environment variables, including:
Exploiting the Vulnerability
The attacker could decode the KUBELET_* variables and use them with kubectl to authenticate to the cluster with minimal permissions, notably the ability to list nodes.
However, the TLS_BOOTSTRAP_TOKEN could be used directly with kubectl to read and create ClientSigningRequests (CSR). This enabled a TLS bootstrap attack where the attacker could request a client certificate for any active node.
AKS automatically signs CSRs submitted by TLS bootstrap tokens. With the attacker-controlled client certificate, they could authenticate to the API and gain the ability to read all secrets for workloads running on the compromised node, as granted by the Node Authorizer. Repeating this process for each node would give access to all secrets in the cluster.
Mandiant disclosed this vulnerability to Microsoft via the MSRC program and Microsoft has since fixed the underlying issue. Azure Kubernetes Service users should ensure their clusters are updated to a patched version.
The exact timeline of when Mandiant reported the vulnerability to Microsoft and how quickly Microsoft responded is not clearly specified.
Enforcing authentication for internal services and restricting unsafe workloads help mitigate the impact of vulnerabilities like this.
Are you from SOC and DFIR Teams? Analyse Malware Incidents & get live Access with ANY.RUN ->Get 14 Days Free Acces
#Cyber_Security_News #Vulnerability #cyber_security #cyber_security_news #vulnerability
Оригинальная версия на сайте:
Azure Kubernetes Services Vulnerability Let Attackers Escalate Privileges
Author: Guru BaranMandiant recently disclosed a critical vulnerability in Microsoft Azure Kubernetes Services (AKS) that could have allowed attackers to escalate privileges and access sensitive credentials within affected clusters. The vulnerability impacted AKS clusters using “Azure CNI” for network configuration and “Azure” for network policy.
An attacker with command execution in a Pod running within a vulnerable AKS cluster could have exploited this issue to download the configuration used to provision the cluster node.
The configuration contained transport layer security (TLS) bootstrap tokens that the attacker could extract and use to perform a TLS bootstrap attack. This would grant the attacker the ability to read all secrets within the cluster.
Notably, the attack did not require the compromised Pod to be running with hostNetwork enabled or as the root user. This significantly expanded the attack surface.
The attack involved accessing the undocumented Azure WireServer component at http://168.63.129.16/machine/?comp=goalstate and the HostGAPlugin endpoint at http://168.63.129.16:32526/vmSettings.
The attacker could retrieve a key from the WireServer to decrypt protected settings values. They could then request the JSON document from HostGAPlugin, parse it, and Base64 decode it to obtain the encrypted provisioning script (protected_settings.bin).
Using the WireServer key, the attacker could decrypt protected_settings.bin to access the cluster’s provisioning script (cse_cmd.sh). This script contained several secrets as environment variables, including:
- 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
Exploiting the Vulnerability
The attacker could decode the KUBELET_* variables and use them with kubectl to authenticate to the cluster with minimal permissions, notably the ability to list nodes.
However, the TLS_BOOTSTRAP_TOKEN could be used directly with kubectl to read and create ClientSigningRequests (CSR). This enabled a TLS bootstrap attack where the attacker could request a client certificate for any active node.
AKS automatically signs CSRs submitted by TLS bootstrap tokens. With the attacker-controlled client certificate, they could authenticate to the API and gain the ability to read all secrets for workloads running on the compromised node, as granted by the Node Authorizer. Repeating this process for each node would give access to all secrets in the cluster.
Mandiant disclosed this vulnerability to Microsoft via the MSRC program and Microsoft has since fixed the underlying issue. Azure Kubernetes Service users should ensure their clusters are updated to a patched version.
The exact timeline of when Mandiant reported the vulnerability to Microsoft and how quickly Microsoft responded is not clearly specified.
Enforcing authentication for internal services and restricting unsafe workloads help mitigate the impact of vulnerabilities like this.
Are you from SOC and DFIR Teams? Analyse Malware Incidents & get live Access with ANY.RUN ->Get 14 Days Free Acces
#Cyber_Security_News #Vulnerability #cyber_security #cyber_security_news #vulnerability
Оригинальная версия на сайте:
