Azurescape Vulnerability: Cross-Account Container takeover in Azure Container Instances

Azure Container Instances (ACI) service allows users to run containers directly in a serverless cloud environment, requiring no virtual machines or clusters.

While Palo Alto Networks' Unit 42 threat intelligence team has disclosed a vulnerability in ACI service that could have been exploited by an attacker to access other customers' information. The vulnerability dubbed "Azurescape" involves how a malicious actor can leverage the cross-tenant technique to escape a rogue ACI container, escalate privileges, and take over an impacted containers by executing malicious code.

Microsoft, however, has issued a patch shortly after the disclosure and there is no known information on Azurescape exploit in the wild.

How Azurescape could have been exploited by a Malicious actor to access customers' information?

Azure Container Instances (ACI) offers a Container-as-a-Service (CaaS) that enables customers to run containers on Azure without managing the underlying servers.

The CaaS offering is notoriously hard to access, and users are only exposed to their container environment, and local network access is disabled through firewalls. But the researchers created WhoC, a container image that reads the container runtime executing it. It's based on a rarely discussed design flaw in Linux containers that allow them to read the underlying host's container runtime.

Deploying WhoC to ACI, enabled the researchers to retrieve the container runtime used in the platform and unsurprisingly, they were able to find runC, the industry standard container runtime.

RunC v1.0.0-rc2 which was released in 2016, was vulnerable to at least two container breakout CVEs. The presence of this old version of runC in ACI, allowed the researchers to successfully broke out of their container and gained a reverse shell running as root on the underlying host, which turned out to be a Kubernetes node.

Albeit, the node's Kubelet only allowed anonymous access, the researchers tried to access Kubelets on neighboring nodes, but all attempted requests to access neighboring nodes timed out, probably due to a firewall configuration that prevented communication between worker nodes. The researchers deployed a few breakout containers which landed on different Kubernetes clusters, with unique cluster IDs ranging between 1-125 and these cluster IDs indicated that each location (e.g. West Europe) hosted a few dozen clusters.

As ACI was hosted on clusters running either Kubernetes v1.8.4, v1.9.10 or v1.10.9, which versions were released between November 2017 and October 2018 and are vulnerable to multiple publicly known vulnerabilities. The researchers started going over past Kubernetes issues, searching for ones that would allow their compromised node to escalate privileges or gain access to other nodes and CVE-2018-1002102 was identified as promising.

The CVE-2018-1002102 marks a security issue in how the api-server communicated with Kubelets, it accept redirects. And by redirecting the api-server's requests to another node's Kubelet, a malicious Kubelet can spread in the cluster.

Again, this discovery highlights the need for cloud users to take a 'defense-in-depth' approach to securing their cloud infrastructure that includes continuous monitoring for threats, inside and outside the cloud platform.