Microsoft mauled over fresh cross-tenant vulnerability
"This is a major attack surface and not consistent with the level of security that public cloud customers expect."
A critical vulnerability in a driver used to connect AWS and Azure data services allowed an attacker to perform remote command execution (RCE) across infrastructure to reach other Azure tenants, or customers.
The security failure affected Azure Data Factory, an Extract Transform Load (ETL) service, as well as Azure Synapse pipelines, used to create an Integration Runtime for data integration across different networks.
Exploiting it also exposed what security researchers at Orca Security described as "areas in the service where a huge amount of Microsoft and 3rd party code, runs with SYSTEM permissions, processing customer controlled input. This runs on shared machines with access to Azure service keys and sensitive data of other customers. These areas of the service only have application-level separation and lack sandbox or hypervisor-level isolation. This is a major attack surface and not consistent with the level of security that public cloud customers expect."
Exploitability was possible via a vulnerability in a driver used to connect Azure services to the Amazon Redshift data warehouse. Once in, an attacker could access and control other customers’ Synapse workspaces and grab sensitive data stored in the service including Azure service keys, API tokens, and passwords to other services.
Microsoft this week admitted that it had been forced to make a range of fundamental changes to architecture for "defence in depth" as a result, after an initial hotfix for the issue was followed by reports of two more cross-tenant attack paths -- all reported under coordinated disclosure to Microsoft by Orca Security. It says it will also "invest engineering effort" in virtualising third-party connector execution to achieve per-tenant isolation.
Azure cross-tenant vulnerability: More robust separation needed?
Orca Security is unconvinced by Microsoft's fixes (a timeline for which is below). The company this week said: "Based on our understanding of the architecture of the service, and our repeated bypasses of fixes, we think that the architecture contains underlying weaknesses that should be addressed with a more robust tenant separation mechanism. Until a better solution is implemented, we advise that all customers assess their usage of the service and refrain from storing sensitive data or keys in it."
Orca Security's Avi Shua said that the company's security researchers were able to "download highly privileged internal Microsoft keys" and that it took "until late March [two months], after several escalations, for MSRC to notify us that they had fixed the reported issue. We were disappointed to see that while the specific vulnerability was fixed, the tenant separation was still extremely weak, and we were able to demonstrate a different attack vector that also allowed a bypass of Synapse tenant separation on March 30. At this time, we also reminded Microsoft that the keys we downloaded were still valid and allowed access to sensitive data of other customers."
> Follow The Stack on LinkedIn <
- Jan 4 – Orca reported the issue to MSFT.
- Mar 2 – MSFT deployed an initial hotfix
- Mar 11 – MSFT notified affected customers
- Mar 30 – Orca disclosed an additional attack path
- Apr 13 – Orca disclosed another attack path (same vuln)
- April 15 – MSFT deployed fixes, added additional defense in depth measures
- May 9 -- The driver itself was patched
Microsoft said May 9 it had taken the following actions to shore up security across the service: "Mitigated remote command execution in the impacted driver; reduced the job execution privilege in the Azure Integration Runtime; added extra validation layers as a defense in depth to harden the service; rotated and revoked the backend service certificate and other Microsoft credentials that were accessed by the finder; collaborated with the third-party ODBC driver provider on root-cause fixes to the driver used to connect to Amazon Redshift; reviewed third-party driver vendor code and ran our security tooling to ensure it meets our security standards."
The vulnerability is troubling for what it reveals about tenant separation failures. It comes weeks after security researchers at Wiz discovered a chain of vulnerabilities in the widely used Azure Database for PostgreSQL Flexible Server that also bypassed tenant isolation to give read access to other customers' databases -- Wiz in 2021 also reported cross-tenant vulnerabiities in Azure Cosmos DB that let "any unprivileged attacker obtain complete and unrestricted access to the databases of several thousand Microsoft Azure customers."
As Wiz noted at the time "tenant isolation is a fundamental premise of the cloud. Organizations trust that the cloud services they use, especially high value assets such as databases, are isolated from other customers."
Azure cross-tenant vulnerability: The driver to blame (initially)
The vulnerability, CVE-2022-29972, affects the Amazon Redshift ODBC and JDBC drivers and Amazon Athena ODBC and JDBC drivers maintained by insightsoftware subsidiary Magnitude Simba.
"The vulnerability in the third-party ODBC connector for Amazon Redshift allowed a user running jobs in a Synapse pipeline to execute remote commands. A user who exploited this vulnerability could then potentially acquire the Azure Data Factory service certificate and execute commands in another tenant’s Azure Data Factory Integration Runtimes. These certificates are specific to Azure Data Factory and Synapse Pipelines, and do not pertain to the rest of Azure Synapse," Microsoft said on May 9, in a blog on the vulnerability.
The driver vulnerability itself (one of four bugs in driver software from Magnitude Simba) was patched at source on May 9. Disclosure came as Microsoft dropped its customary series of other fixes on May's Patch Tuesday, including several CVSS 9.8-rated vulnerabilities that deserve attention; one listed as under attack.
Somewhat unusually, Microsoft opted to blog in some detail about the driver vulnerability, emphasising that an audit for signs of abuse of the bug only turned up activity by the firm that reported the vulnerability.
Orca Security's write-up is here.
Microsoft's write-up is here.
Magnitude Simba's advisory is here.
Strong views on the above? Pop us a line.
