- 3 minutes
Azure Automation is a service that allows users to quickly create free-form jobs (“runbooks”) that respond to certain triggers (time-based, event-based, direct invocation, etc.). Common tasks for Azure Automation focus on cloud infrastructure management (such as SQL reporting, deployment scaling, or log processing), meaning that these jobs often have wide-ranging administrative access to cloud services.
Earlier this week, Orca Security publicized details about a vulnerability they discovered in Microsoft Azure’s Automation service. The root cause of this “AutoWarp” vulnerability was Azure incorrectly allowing any job running on the same machine to access an endpoint returning an access token for other services. This means that any other Azure customer could obtain extensive access to your infrastructure, as they can masquerade as your Automation runbook and obtain the same privileges granted to it for its normal function.
This vulnerability was fortunately reported through responsible disclosure by Orca Security, and was thus already fixed by Microsoft prior to the public announcement. Microsoft also found no indications that this issue had been exploited by an attacker.
If an Automation runbook had access to sensitive user data (for the purposes of reporting, reindexing, infrastructure migrations, etc.), an attacker would also have full access to exfiltrate that data, leading to a data breach. At-rest encryption would not have defended against this attack, as the Automation job would have access to that data’s encryption keys, which are needed for its normal operation.
AutoWarp is just another instance of a cloud provider misconfiguration or security oversight putting your sensitive user data at risk. In 2021, the Wiz Research Team publicized another Azure access control vulnerability1 known as “ChaosDB” that would similarly have exposed any data stored in Azure’s flagship CosmosDB. This vulnerability was caused by Microsoft turning on a new feature by default that exposed all customers’ databases, even if they had previously taken all necessary security precautions. AWS and GCP aren’t immune to these kinds of issues either - for instance, Orca Security recently gained control of AWS internal services through a CloudFormation vulnerability2.
Software bugs and oversights can happen to anyone, even the large cloud providers who have teams of security experts on staff - how will you be protected when it happens as a result of your code or configuration? Access controls (and at-rest encryption, which is effectively the same3) simply aren’t getting the job done, and leave all your users’ sensitive data behind a single point of failure. Moving to Zero Knowledge and end-to-end encryption is the only way to ensure that your users’ data won’t be leaked, even in the face of issues from your own code, your cloud provider, or down to the Linux kernel itself.
Bunkyr is here to help make moving to these more secure systems easier for both you and your end users. If you’d like to know more about how we can help, please request a demo or reach out directly to our engineering team.