Microsoft fixed two flaws in the Azure Database for PostgreSQL Flexible Server authentication process that could have allowed any Postgres administrator to gain superuser privileges and access other customers’ databases.
“By exploiting an elevated permissions bug in the flexible server authentication process for a replication user, a malicious user could exploit a poorly anchored regular expression to bypass authentication to access other people’s databases. customers,” the software giant explained in a notice on Thursday. .
Cloud security provider Wiz found the bugs in the authentication process in January, and Microsoft has since fixed the errors. Although all Flexible Server Postgres servers using the public access network option were impacted, Redmond’s goliath said it mitigated the security flaw before attackers exploited the issue and gained access. to customer data.
Microsoft did not specify how many customers were vulnerable. However, anyone who used the private access networking option was not exposed.
And while customers don’t need to do anything to resolve the issue, Microsoft recommends that they enable private network access when configuring Flexible Server instances to minimize any additional exposure.
The Wiz researchers, in an analysis of the flaws, which they dubbed Additional replicadetailed how they circumvented Azure’s cloud isolation model to exploit the two vulnerabilities.
From Cosmos DB to ExtraReplica
As a reminder: Wiz is a cloud security startup whose founders help build the Azure security stack and they also discovered the Cosmo DB vulnerability last year. This bug allowed unrestricted access to Azure customer databases through a chain of Cosmos DB misconfigurations. And, in fact, that’s how the team found this new flaw, revealed today.
“We previously found vulnerabilities in Azure Cosmos DB,” Wiz researchers Sagi Tzadik, Nir Ohfeld, Shir Tamari, and Ronen Shustin wrote in their analysis. “Could we reproduce a similar issue in other Azure services?
The answer is, of course, yes.
Azure Database for PostgreSQL Flexible Server is Microsoft’s fully managed and scalable service for the open source PostgreSQL database.
And PostgreSQL has a feature that allows users to copy their database data from one server to another, and this replication capability is useful for backup and failover scenarios. It could also have allowed cybercriminals to exploit this flaw in Microsoft’s managed service.
During a bug hunt, the Wiz team discovered that Azure had changed its PostgreSQL engine, presumably to tighten security and add new features. However, it also introduced a privilege escalation vulnerability that allowed researchers to execute arbitrary requests, including operating system-level commands, as superuser.
“Although Microsoft has patched this vulnerability, out of an abundance of caution against other vendors who may have made similar changes to their PostgreSQL engine, we are not disclosing exploitation details at this time,” they wrote.
The team also discovered that the network interfaces were accessible from inside the PostgreSQL container and that their container shared a network namespace with the host machine. So they decided to create another instance on a different account and see if through the internal network interface they could access other customers’ instances.
And it worked.
“On top of that, it worked even when the instance had its firewall configured to deny all login attempts,” they said, adding that they believe it violates users’ expectation that their databases remain isolated from other clients.
“However, since we still needed to have the username and password for this database to perform any meaningful action (such as reading or modifying data), the severity of this issue remains quite low,” admitted Wiz.
Wiz researchers also detailed how they exploited a second vulnerability in the authentication process. One more than allowed: an authentication bypass between accounts using a fake certificate.
For this, they identified a second vulnerability in the service’s authentication process: too permissive regular expression validation for the common name of the certificate:
The wildcard character (.*) at the end of the regular expression is the problem. All bug hunters had to do to exploit this was register a domain that matches this regular expression:
Then go to digicert.com and issue a certificate to:
This worked, since the security store owns wiz-research.com, so they were able to purchase a certificate from RapidSSL, an intermediate CA from DigiCert.
Issuing a certificate for their own domain allowed the Wiz team to access a database from a separate account they had on a different tenant, which provided access to the database data between accounts.
However, accessing other customers’ databases required a few extra steps.
Break and enter
Each database instance has a unique identifier, and to generate a client certificate for a specific database, an attacker would need to know this unique identifier.
The Wiz team discovered that the identifier appears in the server’s SSL certificate. “By attempting to connect other databases in the internal network using SSL, we were able to retrieve their SSL certificates and extract the unique ID of each database in the subnet,” they explained. .
Once they have the ID, they can again buy a certificate with a forged common name and set up a new database in the target region.
Then it was time to exploit the first vulnerability to elevate privileges and gain code execution, scan the subnet for the target instance, exploit the second vulnerability and gain read access to the victim’s database.
Microsoft rolls out patches
Microsoft said it rolled out patches for the most critical vulnerability, which allowed cross-tenant attacks, on January 13. The database service now provides “full isolation between the underlying virtual machine instances of different tenants,” according to the security advisory.
Additionally, replication permissions are now only matched when the exact subject name matches, as opposed to a simple prefix match.
“During this patch rollout, we also addressed all new server builds for blocking both elevated privileged access and remote code access,” Redmond added.
Microsoft also blocked the copy program in Postgres, which it said addressed the remote code execution vulnerability in the service, and fixed the Postgres error message that displayed the certificate name before February 25. ®