Microsoft Patches Pair of Dangerous Vulnerabilities in Azure PostgreSQL
Flaws gave attackers a way to access other cloud accounts and databases, security vendor says.
April 28, 2022
Microsoft has patched a dangerous pair of vulnerabilities in its Azure Database for PostgreSQL Flexible Server that gave attackers unauthorized cross-account access to databases in cloud hosted environments.
The first is a privilege escalation bug in a modification that Microsoft made to the PostgreSQL engine. The second is a bug that leverages the privilege escalation enabled by the former to give attackers cross-account access.
Threat actors could have used the flaws to bypass authentication mechanisms and gain full access to customer data across multiple databases in a region without leaving any trace of their presence, researchers from cloud security vendor Wiz Research recently discovered.
"An attacker could create a full copy of a target database in Azure PostgreSQL [Flexible Server], essentially exfiltrating all the information stored in the database," says Ami Luttwak, co-founder and CTO at Wiz. The vulnerabilities would have allowed attackers to bypass firewalls configured to protect the hosted databases unless an organization had configured it for private access only. "But this is not the default configuration," Luttwak says.
In an advisory Thursday, Microsoft described the security issue as impacting organizations that had deployed their PostgreSQL Flexible Server instances using the public access networking option. The company said it mitigated the issue on Jan. 13, 2022, less than 48 hours after Wiz had notified it of the issue. Microsoft said its analysis showed no evidence of attackers having exploited the vulnerabilities to access customer data. Though organizations using the service need not take any action, Microsoft recommended they enable private network access for their Flexible Server instances to minimize exposure to similar issues.
Luttwak says vulnerabilities like these highlight why organizations need to have a defense in depth security model when deploying and running cloud workloads. He says, "Here, a simple developer mistake — a wrong prefix validation — led to a potential ability for attackers to gain access to customer data." The only way to mitigate such risks is to have multiple layers of protection so a single bug does not allow for a compromise, Luttwak says.
The Wiz researchers found the bugs as part of a wider research effort to find cross-account access vulnerabilities in cloud services. These are a class of vulnerabilities that essentially give attackers a way to break through tenant isolation mechanisms in cloud environments to access other customer accounts and data. Wiz's effort follows the company's discovery in August 2021 of a critical vulnerability — dubbed ChaosDB — in Microsoft's Azure Cosmos DB that gave the company unrestricted access to databases and accounts belonging to thousands of customers of the Azure service, many of whom were Fortune 500 companies.
"Following the ChaosDB vulnerability we disclosed last year, we specifically focused on cloud-managed databases as they pose the most risk holding sensitive customer data," Luttwak notes.
Cross-Account Access Flaws in the Cloud
Wiz decided to focus on Azure PostgreSQL Flexible Server because it is a widely used cloud managed database service, where the database instances run in an internal cloud environment owned by the service provider. The researchers began by trying to figure out a way to escalate privileges within their own PostgreSQL Flexible Server instance and discovered a vulnerability in some modifications that Microsoft had made to the engine ostensibly to harden its privilege model.
"The privilege escalation bug is not a PostgreSQL vulnerability, but rather is a result of modifications Azure introduced to the PostgreSQL engine on their end," Luttwak says. "It's likely these modifications were introduced to help Azure better manage customers' instances and reduce friction."
Once the researchers gained code execution privileges on their PostgreSQL Flexible Server instance, they found they had network access to other accounts within the subnet via their internal network interface. To test whether the access would work, the researchers created another PostgreSQL Flexible instance using a separate account and tried accessing it from their first database. When that worked, they looked for a way to similarly use their instance to access other accounts without authenticating to them. This led to the discovery of a vulnerability that allowed them to do just that, using a forged certificate.
Luttwak explains the exploit as leveraging an Azure high availability function that uses PostgreSQL's replication feature to replicate databases between servers.
"The replication service connects to the database instance and has the permissions to replicate it to other nodes" via a shared network, he says. Wiz researchers found they could get complete copies of other databases by authenticating as the replication service to other PostgreSQL instances using a certificate issued to an arbitrary domain rather than Azure's replication service certificate.
"We didn't actually achieve access to the replication service certificate," Luttwak says. "But we found a way to bypass [it] since the PostgreSQL was only looking for a private key with a certain prefix."
That allowed Wiz to simply create a legitimate-looking certificate that passed the authentication, Luttwak notes.
He says the two — now patched — vulnerabilities would have needed to be chained to have significant impact. That's because the first vulnerability only provides local access to a database instance. But without it, an attacker would not have the privileges required for cross-account access.
About the Author
You May Also Like
Unleashing AI to Assess Cyber Security Risk
Nov 12, 2024Securing Tomorrow, Today: How to Navigate Zero Trust
Nov 13, 2024The State of Attack Surface Management (ASM), Featuring Forrester
Nov 15, 2024Applying the Principle of Least Privilege to the Cloud
Nov 18, 2024The Right Way to Use Artificial Intelligence and Machine Learning in Incident Response
Nov 20, 2024