This article is more than 1 year old

Microsoft fixes cross-account vulns in Azure Database for PostgreSQL service

Presented by the Wiz team that found the Cosmos DB flaw

Microsoft fixed a pair of flaws in Azure Database for PostgreSQL Flexible Server's authentication process that could have allowed any Postgres admin 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 leverage an improperly anchored regular expression to bypass authentication to gain access to other customers' databases," the software giant explained in an advisory on Thursdsay.

Cloud security vendor Wiz found the bugs in the authentication process in January, and Microsoft has since addressed the blunders. Although all Flexible Server Postgres servers using the public access networking option were impacted, the Redmond goliath said it mitigated the security flaw before any miscreants exploited the issue and accessed customer data.

Microsoft didn't say 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 address the issue, Microsoft recommends that customers enable private network access when they set up Flexible Server instances to minimize further exposure.

Wiz researchers, in an analysis about the flaws, which they dubbed ExtraReplica, detailed 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 they also discovered the Cosmo DB vuln last year. This bug allowed unrestricted access to Azure customers' databases through a chain of misconfigurations Cosmos DB. And, in fact, that's how the team found this new flaw, disclosed today.

"We had 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, of course, is 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 capability is useful for backup and failover scenarios. It also could have allowed cybercriminals to exploit this flaw in Microsoft's managed service.

When they went bug hunting, the Wiz team discovered that Azure had modified its PostgreSQL engine, probably to harden the security and added new features. However, this also introduced a privilege-escalation vulnerability that allowed the researchers to execute arbitrary queries, including OS-level commands, as a superuser.

"While Microsoft has patched this vulnerability, out of an abundance of caution with respect to other vendors who may have made similar modifications in their PostgreSQL engine, we are not disclosing exploitation details at this time," they wrote.

The team also discovered that 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, by routing 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 connection attempts," they said, adding that they believe this violates users' expectation that their databases remain isolated from other customers. 

"However, since we were still required 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," Wiz admitted.

Vulnerability #2

Wiz researchers also detailed how they exploited a second vulnerability in the authentication process. An over that allowed: a cross-account authentication bypass using a forged certificate.

For this, they identified a second vulnerability in the service's authentication process: an over-permissive regular expression validation for the certificate's common name:

pgusermap    /^(.*?)\.eee03a2acfe6\.database\.azure\.com(.*)$    \1

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 that matches this regular expression:

Replication.eee03a2acfe6.database.azure.com.wiz-research.com

Then visit digicert.com and issue a certificate to: 

replication.eee03a2acfe6.database.azure.com.wiz-research.com.

This worked, since the security shop owns wiz-research.com, so they were able to buy a certificate from RapidSSL, an intermediate CA of DigiCert. 

Issuing a certificate for their own domain allowed the Wiz team to access a database of a separate account that it owned on a different tenant, and this provided the cross-account database access.

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

Breaking and entering

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

The Wiz team found that the identifier appears in the server's SSL certificate. "By attempting to connect other databases in the internal network using SSL, we could retrieve their SSL certificates and extract the unique identifier for each database in the subnet" they explained.

Once they've got the identifier, they can again purchase a certificate with a forged 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 vuln and gain read access to the victim's database.

Microsoft rolls out fixes

Microsoft said it rolled out fixes for the most critical vuln, which allowed cross-tenant attacks, on January 13. The database service now provides "complete isolation between different tenants' underlying virtual machine instances," according to the security advisory.

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

"During that patch rollout, we also addressed all new server creations to have blocked both elevated privileged access and remote code access," Redmond added.

Microsoft also blocked the copy program in Postgres, which it said took care of the remote code execution vuln in the service, and fixed the Postgres error message that displayed the certificate name by February 25. ® 

More about

TIP US OFF

Send us news


Other stories you might like