Multiple cloud vendors impacted by PostgreSQL vulnerability that exposed enterprise databases

Flaws discovered in various PostgreSQL-as-a-Service offerings, including those from Microsoft and Google

Wiz Research has found vulnerabilities in popular ‘PostgreSQL-as-a-Service’ offerings from various cloud vendors, introduced by the cloud vendors themselves.

Earlier this year, the security outfit discovered a chain of critical vulnerabilities in Microsoft Azure Database for PostgreSQL Flexible Server.

The exploit, named #ExtraReplica, allowed unauthorized read access to other customers’ PostgreSQL databases, bypassing tenant isolation.

“The isolation was not perfect, and we had network access from our managed instance to other customers’ instances, which opened an attack surface for other potential vulnerabilities,” Shir Tamari, head of research at Wiz, tells The Daily Swig.

“We proved it was possible to exploit this attack surface and gained full read access to the databases of other customers.”

Decades-old bug

Wiz has now revealed that a similar vulnerability affects Google Cloud Platform (GCP), though with less severe potential effects.

Dating back 25 years, PostgreSQL lacks a permissions model suitable for a managed service, leading vendors to add their own code.

DON’T MISS New class of HTTP request smuggling attacks showcased at Black Hat USA

“In turning Postgres into a managed service, cloud service providers wanted to provide users with superuser privileges without risking their service by allowing some capabilities considered dangerous,” says Tamari.

“PostgreSQL’s permission model cannot provide a user only a set of superuser privileges. Therefore, cloud vendors had to introduce modifications to allow regular users a set of superuser capabilities. “

These modifications let the team execute arbitrary commands on vendor-managed compute instances of multiple PostgreSQL-as-a-Service offerings – in extreme cases gaining unauthorized cross-tenant data access to other customers using the affected service.

Dozens of fixes

In the case of Cloud SQL, while the team wasn’t able to gain superuser status, it was possible to access some of its privileges. One was the ability to arbitrarily change the ownership of a table to any user or role in the database.

This meant the team could create a table with dummy content, create a malicious index function – with its code execution payload – on the table, and then alter the table owner to , GCP’s superuser role, used only by Cloud SQL to maintain and manage the database.

Analyzing the table then forced the PostgreSQL engine to switch user-context to the table’s owner, , and call the malicious index function with the permissions, resulting in execution of the shell command.

“During the research, we worked with more than a dozen PostgreSQL vendors to verify and fix the issues we discovered. It turns out that many cloud providers introduced the same modifications to adjust PostgreSQL as a managed service and therefore were potentially vulnerable,” says Tamari.

“As part of a broad responsible disclosure process, we shared our findings with major cloud providers and others to help them determine whether they were exposed to the issues we identified.”

YOU MIGHT ALSO LIKE Germany to mandate minimum security standards for web browsers in government