Microsoft has finally finished hardening Azure to ensure better tenant separation, eliminating a critical vulnerability uncovered by Orca Security researcher Tzah Pahima in January that gave full control over any customer’s Azure Synapse workspace and further, put "any integration runtime in the palm of my hands".
The Azure Synapse vulnerability, dubbed SynLapse, also affected Azure Data Factory. It gave Pahima access to "areas in the service where a huge amount of Microsoft and third-party code, runs with SYSTEM permissions... on shared machines with access to Azure service keys and sensitive data of other customers" .
As The Stack covered last month, the security risk was sufficiently high for Orca to recommend clients stop using Azure Synapse until Microsoft had hardened the service. Whilst Redmond made a number of fixes in May (after two initial patches were promptly bypassed) it added at the time that it would be working harder to ensure "cloud processes and workloads, including third-party data connectors, run in a Zero Trust architecture that advance cross tenant isolation [with] virtualization of third-party connector execution to achieve per-tenant isolation."
https://twitter.com/TzahPahima/status/1536705780098949124
See: Microsoft mauled over fresh cross-tenant vulnerability
In an update, Orca now says Microsoft has implemented the more fundamental changes it suggested to address the Azure Synapse vulnerability – and therefore the security firm has removed its advisory that customers cease use of the cloud enterprise analytics service: “At the beginning of June Microsoft shared with us that they have implemented all recommendations and Synapse Integration Runtime is now using ephemeral nodes and scoped low-privileged API tokens,” said Pahima in a blog post.
“In light of this information, we now believe that Azure Synapse Analytics provides sufficient tenant isolation. As such, we have removed alerting on Synapse from within the Orca Cloud Security Platform. Microsoft continues to work on additional isolation and hardening.”
Specifically Microsoft has moved the shared Synapse integration runtime to a sandbox – so it is no longer shared between tenants. Microsoft has also limited API access, with least-privilege access to the management server, which will prevent attackers using the certificate to access other tenants’ information.
Pahima’s post also contains a much more detailed look at how his Azure Synapse vulnerability exploit worked, and the specific ways he was able to bypass Microsoft’s attempts at patching the problem, from March onwards.
In its earlier post on SynLapse, Orca said it was holding back the technical details of the exploit because “we believe that the technical details of the exploit will make it easier for attackers to find more open attack vectors, and the delay will allow time for organizations to reconsider their usage of Synapse”.
See also: “Keys to the cloud” stored in plain text in Azure AD security blooper
Now Redmond has addressed the fundamental issues behind the Azure Synapse vulnerability, Orca is more comfortable releasing the juicy details. Pahima’s latest post is worth reading for the blow-by-blow account of how Microsoft tried to fix the flaw, and how Pahima was able to bypass it at least twice.
By the end of the security researcher’s investigations, it seems as if Pahima and Microsoft were working on the shared runtime at the same moment.
“MSRC was doing patches and mitigations at the same time, and probably somehow disabled the access to the vulnerable feature in the Redshift connector. What I tried to do was to find another vulnerable connector installed, and exploit it via the full ODBC access I had just acquired again,” said Pahima.
“I found more vulnerabilities to utilize this access, but when in the middle of my work – after performing a few requests testing some vulnerabilities, it seemed that Microsoft patched the Salesforce connector I was exploiting, while I was using it. There goes my ODBC bypass.
“I looked for another one, including some other ways to execute code, but after a few days I concluded that this attack vector was patched pretty well.”
In a May blog post on SynLapse, which was updated on 14 June, Microsoft gave its own explanation of the Azure Synapse vulnerability, and said it had found no evidence of misuse or malicious activity.
“To ensure that your resources receive the necessary security updates, customers using Azure Data Factory with Self-hosted IRs (SHIRs) with auto-update turned off must update their SHIRs to the latest version (5.17.8154.2). Customers can download the latest version here. These customers were also notified of this guidance through Service Health (Tracking ID: MLC3-LD0) in the Azure Portal,” said the Microsoft blog.
“For additional protection, Microsoft recommends configuring Synapse workspaces with a Managed Virtual Network which provides better compute and network isolation. Customers using Azure Data Factory can enable Azure integration runtimes with a Managed Virtual Network.”
