Microsoft fixes vulnerability in Azure Database for PostgreSQL • The Register

0

Microsoft has fixed two bugs 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 privilege bug in the Flexible Server authentication process for a replication user, a malicious user could use a mis-anchored regular expression to bypass authentication and gain access to other customers’ databases,” the software giant said explained in a consultation on Thursday.

Cloud security provider Wiz found the bugs in the authentication process in January, and Microsoft has since fixed the bugs. Although all Flexible Server Postgres servers using the public access network option were affected, the Redmond Goliath said the vulnerability was mitigated before any criminals exploited the issue and accessed customer data.

Microsoft hasn’t said how many customers are vulnerable. However, no one using the private access network option was exposed.

And while customers don’t have to take any action to fix the issue, Microsoft recommends that customers enable private network access if they choose set up Flexible server instances to minimize further risks.

Wiz researchers in an analysis about the shortcomings they dubbed ExtraReplicadescribed how they bypassed 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 also discovered the Cosmo DB vulnerability last year. This bug allowed unrestricted access to Azure customers’ databases through a chain of misconfigurations to Cosmos DB. And indeed, this is how the team found this new bug revealed today.

“We had previously found vulnerabilities in Azure Cosmos DB,” said 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, 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 feature is useful for backup and failover scenarios. It could also have allowed cybercriminals to exploit this flaw in Microsoft’s managed service.

While debugging, the Wiz team discovered that Azure had modified its PostgreSQL engine, likely to increase security and add new functionality. However, this also created an elevation of privilege vulnerability that allowed the researchers to run arbitrary queries, including operating system-level commands, as the superuser.

“Although Microsoft has patched this vulnerability, out of caution to other vendors who may have made similar changes to their PostgreSQL engine, we are not disclosing exploit details at this time,” they wrote.

The team also discovered that network interfaces were accessible from within the PostgreSQL container and that their container shared a network namespace with the host computer. So they decided to create another instance on a different account and see if they could access other customers’ instances by routing through the internal network interface.

And it worked.

“Furthermore, it worked even when the instance’s firewall was configured to reject all connection attempts,” they said, adding that they believe this violates users’ expectation that their databases remain isolated from other customers.

“However, since we still need the username and password for that database in order to perform any meaningful action (like reading or modifying data), the severity of this issue remains fairly low,” admitted Wiz.

Vulnerability #2

Wiz researchers also detailed how they exploited a second vulnerability in the authentication process. Also allows: Cross-account authentication override using a fake certificate.

To do this, they identified a second weakness in the service’s authentication process: an overly permissive regular expression check for the certificate’s common name:

The wildcard (.*) at the end of the regex is the problem. All the bug hunters had to do to exploit this was register a domain matching this regular expression:

Then visit digitert.com and issue a certificate for:

This worked because the security shop owns wiz-research.com, so they could buy a certificate from RapidSSL, an intermediate certificate authority from DigiCert.

Issuing a certificate for their own domain gave the Wiz team access to a database of a separate account that they owned on a different tenant and this enabled cross-account database access.

However, accessing other customers’ databases required a few more steps.

Departure and move-in

Each database instance has a unique identifier, and in order to generate a customer certificate for a specific database, an attacker would need to know this unique identifier.

The Wiz team noticed that the identifier appears in the server’s SSL certificate. “By attempting to connect other databases on the internal network via SSL, we were able to retrieve their SSL certificates and extract the unique identifier for each database on the subnet,” they explained.

Once they have the identifier, they can again purchase a certificate with a fake common name and set up a new database in the target’s region.

Then it was time to exploit the first vulnerability to escalate privileges and gain code execution, scan the subnet for the target’s instance, exploit the second vulnerability and gain read access to the victim’s database.

Microsoft rolls out fixes

Microsoft said it rolled out fixes on Jan. 13 for the most critical vulnerability that allowed cross-tenant attacks. The database service now provides “complete isolation between the underlying virtual machine instances of different tenants,” according to the security advisory.

Additionally, replication permissions are now only matched if the exact subject name matches, as opposed to just a prefix match.

“During this patch rollout, we also addressed any new server creations that blocked both elevated privileged access and remote code access,” Redmond added.

Microsoft also blocked the copy program in Postgres that allegedly took care of the remote code execution vulnerability in the service and fixed the Postgres error message that displayed the certificate name until February 25th. ®

Share.

Comments are closed.