Microsoft recently disclosed a security vulnerability in its Azure Container Instances (ACI) service, referred to as Azurescape. No actual exploitations were reported and, thankfully, no Azure customers were affected by this vulnerability. To clear any doubts around risks to current environments, in this post we will examine the anatomy of a possible attack leveraging Azurescape and what it means for an effective defense-in-depth strategy for cloud native environments.
Step 1: Beginning the attack
ACI is a Container-as-a-Service (CaaS) platform from Microsoft. Customers deploy containers directly to this platform and have no direct access to the underlying VMs that run those containers, or the Kubernetes clusters that run them.
Based on the details provided by the research team that discovered Azurescape, the attacker would first run a malicious container in their own cloud account, which could then be used to conduct reconnaissance of the container runtime being used by ACI.
In the example provided by the researchers, the first vulnerability found was an outdated version of runc, which was subsequently exploited to break out to the underlying VM. It is important to note that, at this point, a potential attacker would still in an environment that “belonged” to them — that is, in a dedicated resource space.
Step 2: Cluster reconnaissance
The attacker could then use credentials stored on the compromised VM to scout what Microsoft credentials were potentially accessible, which they could use to access systems controlled and managed by Azure. This activity would most likely be picked up by cloud provider logging and monitoring tools, but would not have been visible to other tenants.
Step 3: Privileged token acquisition
The next stage of the attack would be to read traffic logs from the compromised VM in order to find an authorization token, which would authorize the attacker to take actions on other nodes.
Here, there would still be no visibility for other tenants into the attackers’ behavior.
How to detect attempted exploits of this vulnerability
It would not be possible for users to see the actions of other customers in the same cluster, so customers would not have had visibility into the initial stages of the attack.
But after the initial stages, the applicable security mechanisms for any potential attack leveraging this vulnerability would be:
Protections that run inside the application container
For attacks like this in the future, if an attacker who had broken out of their environment tried to execute commands inside a customer container or tried to read files in the container using something like kubectl exec, then Aqua’s drift prevention would stop the unexpected execution. With Aqua’s runtime drift prevention feature, any deviation from a container’s intended behavior is blocked (without killing the container).
Cloud service provider features like cloud logging, which might show unusual access from the container
To reiterate, no customers were impacted by this vulnerability. But if the attacker had been able to successfully leverage the vulnerability to execute commands in another customer’s containers and then try to expand their access to other parts of the customer’s cloud environment, cloud provider monitoring tools may have exposed those access attempts.
What else should we learn?
The researchers demonstrating this vulnerability showed a step-by-step process to escalate privileges over time, starting with a malicious container that looked for vulnerabilities to exploit, and moving on to use credentials to escalate privilege and ultimately find tokens to escalate privileges further. This step-by-step process reinforces the need for a defense-in-depth strategy that is specific to cloud native environments in terms of visibility and protection for the container environment as well as the cloud service accounts on which they run. For a full demonstration of defense-in-depth across the cloud native environment in response to an attack kill-chain, check out our webinar on the Anatomy of Cloud Native Attacks.
What should I do if I think I was affected?
Microsoft alerted anyone who may have been affected via a service health notification, while suggesting the following precautionary security measures:
- Revoking any privileged credentials that were deployed to the platform before August 31st, 2021. Common places to specify configuration and secrets for container groups include:
- Environment Variables
- Secret Volumes
- Azure file share
- Consult these security best practices resources
- As part of standard security practices, revoke any privileged credentials on a frequent basis.
- Stay up to date on important security-related notifications by configuring Azure Service Health Alerts.
