Based on research by Wiz.io: The uncovered vulnerabilities by Wiz were the result of a bug in the code that cloud vendors introduced to the Postgress to make it fit their Clouds, not in the core of the PostgreSQL codebase. These vulnerabilities could be used as the initial stepping stone required for more complex attacks, such as in cross-tenant vulnerabilities like ExtraReplica. Disclosed in April 2022, ExtraReplica could allow attackers to access the databases of other customers in Azure Database for PostgreSQL (Flexible Server).

PostgreSQL is a 25-year-old project. It was first designed and developed before cloud computing and managed services even existed, so its authors could not possibly have anticipated the future needs of the cloud. When Cloud Providers started adapting PostgreSQL for managed database solutions, they discovered that it lacked a permissions model suitable for a managed service. Customers were accustomed to having full admin capabilities over their non-cloud managed databases, but Cloud providers could not allow customers to have capabilities that might endanger the security or stability of PostgreSQL-as-a-Service in the cloud. For example, all Cloud Providers offer customers similar semi-admin capabilities such as creating event triggers, checkpoints, loading extensions, managing replications and more. But at the same time, Cloud Providers restrict customers from accessing the file system of the compute instance hosting the database, or executing code on the underlying server.

Wiz.io came up with the following attack flow:

1. Create a new table.
2. Insert some dummy content into the table, so the index function has something to work with.
3. Create a malicious index function (with our code execution payload) on the table.
4. ALTER the table owner to cloudsqladmin, GCP’s superuser role, used only by Cloud SQL to maintain and manage the database.
5. ANALYZE the table, forcing the PostgreSQL engine to switch user-context to the table's owner ( cloudsqladmin ) and call the malicious index function with the cloudsqladmin permissions, resulting in executing our shell command, which we did not have permission to execute before.

After executing the exploit SQL query, the shell_commands_results table contains the output of the executed code:

The first step is successful: let’s see if we can unlock the VM underneath and add a user; allow that new user access to the VM. After the phase 2 script ran, we tried to log in with our newly created user:

Success! As a bonus our user was a sudoer, granting us root privileges on the host.

Shortly thereafter, we received the following email:

Wiz promptly shared their findings in a detailed report and began collaborating on mitigation for these kinds of attacks.

Like GCP, Microsoft Azure has introduced some modifications to the PostgreSQL engine in order to offer PostgreSQL-as-a-Service in the cloud. As with Cloud SQL, these modifications allow users certain superuser capabilities such as creating event triggers, creating checkpoints and loading extensions, all of which are usually reserved for superusers.

When Microsoft set out to offer PostgreSQL-as-a-Service, all Cloud Providers had the same fundamental need: overcoming PostgreSQL’s inability to allow some superuser privileges to users without allowing everything else. Thus, all Cloud Providers were forced to introduce modifications to the PostgreSQL project. The core problem is that introducing admin capabilities to low-privileged users is risky. A seemingly minor modification can allow users to bypass the security model and elevate their privileges within the local database. Because Cloud Providers tend to introduce very similar capabilities, we were able to prove the same exploit code working on multiple vendors, even though the implementation code was different across different Cloud Providers.

Wiz managed to exploit the CREATEROLE permission and by adding a new user to the database were able to easily execute a reverse shell.

Success! and no mail by Microsoft 😞. “Hey, guys, what are you up to?”

Wiz demonstrated with this research the importance of Cloud Isolation. In the case of Google Cloud SQL, where tenant-isolation measures are strictly enforced, the impact of the vulnerabilities we found was relatively small. On the other hand, in the case of Azure PostgreSQL, where the isolation of the service was less strict, these kinds of vulnerabilities could have been leveraged to gain unauthorized cross-tenant access to the database instances belonging to other customers.

If you want to know more about the exploits, scripts and details: be sure to check out the original blog post by Wiz on the matter.