Contents:
The vulnerability found in Azure Container Instances called Azurescape has been recently fixed by Microsoft.
According to the researchers, an attacker abusing Azurescape may run commands in other users’ containers and get access to all of their data stored on the platform.
Customers who may have been affected by Azurescape have been contacted to update privileged credentials for containers deployed to the platform before August 31st.
Apparently, a notification was sent out of an excess of caution since no evidence of an attack that used the vulnerability to get access to client data was discovered.
If you did not receive a Service Health Notification, no action is required. The vulnerability is fixed and our investigation surfaced no unauthorized access in other clusters.
Azure Container Instances (ACI) is a cloud-based service from Microsoft that enables businesses to deploy bundled applications (containers) in the cloud. The containers include all of the executables, dependencies, and files required to execute a certain program, whilst being packaged together to make distribution and deployment easier.
At the precise time of launching the Containers, they are being isolated from other operating containers using ACI. This is how memory sharing and interaction are avoided.
The Outdated Code Is to Blame
Palo Alto Networks discovered Azurescape and reported it to Microsoft. Yuval Avrahami explains the vulnerability in a paper released today, stating that it
enabled hostile users to exploit the multitenant Kubernetes clusters running ACI.
According to Avrahami, the problem was discovered when they noticed ACI was using code from almost five years ago, that was vulnerable to container escaping bugs.
RunC v1.0.0-rc2 was released on Oct. 1, 2016, and was vulnerable to at least two container breakout CVEs. Back in 2019, we analyzed one of these vulnerabilities, CVE-2019-5736.
Exploiting only the CVE-2019-5736 proved to be more than enough to achieve breaking out of the container and get elevated privileges while executing code. And this was happening on the underlying host – a Kubernetes node.
There were also just a few extra steps necessary to get access to other containers as BleepingComputers reports:
- On the node, monitor traffic on the Kubelet port, port 10250, and wait for a request that includes a JWT token in the Authorization header.
- Issue az container exec to run a command on the uploaded container. The bridge pod will now send an exec request to the Kubelet on the compromised node.
- On the node, extract the bridge token from the request’s Authorization header and use it to pop a shell on the API-server.
Dora is a digital marketing specialist within Heimdal™ Security. She is a content creator at heart - always curious about technology and passionate about finding out everything there is to know about cybersecurity.
