How PostgreSQL-as-a-Service solutions from GCP, Azure, and other providers were found to have numerous connected vulnerabilities.
The cloud has an isolation problem
Tenant isolation is a core tenet of the cloud, and Wiz Research did substantial research on it over the past year. We looked at how well clients’ environments are segregated from one another across various cloud service providers (CSPs). We concentrated particularly on how managed services impose cloud separation. Many of the managed services provided by CSPs are built using well-known open-source applications that operate on vendor-controlled compute instances. This is often outdated software that wasn’t created with the needs of cloud multi-tenancy in mind. This begs the question of how CSPs are modifying existing open-source software to meet cloud requirements.
Focus on PostgreSQL
After examining the PostgreSQL services provided by a number of significant cloud providers, we identified a number of vulnerabilities in the changes that these cloud providers made to their individual PostgreSQL projects in order to turn it into a multi-tenant managed service. We exploited these flaws to get access to internal networks of cloud providers by executing unauthorized instructions on vendor-managed compute instances of various PostgreSQL-as-a-Service offerings. As a result, we got a behind-the-scenes peek at how the biggest database services on the internet function. In extreme circumstances, we were able to use the flaws to get unauthorized access to other users’ data who were utilizing the impacted service.
What is PostgreSQL?
One of the most widely used database servers worldwide is PostgreSQL. Thousands of businesses utilize this robust, open source, and well-developed object-relational database to store various kinds of data. It has a solid reputation because of its reliable design and tested architecture. The majority of CSPs provide it as a managed service because of the project’s popularity.
PostgreSQL in the cloud
A 25-year-old project, PostgreSQL. Its creators were unable to foresee the needs of the cloud because it was initially created and developed before managed services and cloud computing was ever a thing. CSPs found that PostgreSQL lacked a rights model appropriate for a managed service when they began modifying it for managed database solutions. Customers were used to having complete administrative control over the non-cloud managed databases they used, but CSPs could not permit customers to have any control over aspects of PostgreSQL-as-a-stability Service or security.
For instance, all CSPs provide comparable semi-admin features to their clients, such as the ability to build event triggers, checkpoints, loading extensions, manage replications, and more. However, CSPs also prevent their clients from running any code on the underlying server or accessing the file system of the compute instance holding the database.
Each CSP approached this issue a little bit differently. Due to PostgreSQL’s extremely constrained permissions model, which essentially only permits some admin capabilities, CSPs have to make adjustments to PostgreSQL in order to permit users to perform some admin functions while still forbidding them from undertaking risky actions. Some CSPs implemented these modifications through extensions or unique configurations. Others even went so far as to alter the PostgreSQL engine’s source code and maintain their own branch. Unexpected security vulnerabilities may arise as a result of any of these strategies.
We will look at two vulnerabilities we found in Azure and Google Cloud Platform to demonstrate our findings.
Case study 1: Google Cloud Platform Cloud SQL
One of GCP’s flagship services, Cloud SQL was introduced in October 2011 and uses the standard database engines MySQL, PostgreSQL, and SQL Server while offering users a fully managed database service, automated backups, replication, encryption, and capacity expansions.
The PostgreSQL implementation used by Cloud SQL is the only subject of this study. We tried running some code on the underlying virtual machine that was running our PostgreSQL instance as the initial step in our investigation.
Case study 2: Azure Database for PostgreSQL – Privilege Escalation and Code Execution
Similar to GCP, Microsoft Azure has made certain changes to the PostgreSQL engine to make PostgreSQL-as-a-Service available in the cloud. Similar to Cloud SQL, these modifications provide users access to some superuser features that are typically only available to superusers, such as generating event triggers, checkpoints, and loading extensions.
Azure PostgreSQL gives users CREATEROLE permission in addition to these superuser-like privileges. Users can also get CREATEROLE permissions from other PostgreSQL-as-a-Service products, such as Cloud SQL, therefore this privilege is not specific to Azure. However, other services place some kind of restriction on the role to avoid abuse. There was no such restriction in Azure.
The permission CREATEROLE is quite potent. The CREATEROLE permission allows users to add new users and assign them to particular roles. Other strong built-in roles provided by PostgreSQL are pg read server files, pg write server files, and pg execute server program. Users may be able to read/write files on the file system and even run arbitrary commands on the underlying operating system if they hold one of those roles.
The official PostgreSQL documentation advises users to treat those who are given the ability to arbitrary create roles as “almost-superusers”.
Summary
As we investigated managed PostgreSQL across clouds and vendors, we discovered that CSPs frequently provide well-liked open-source products as multi-tenant managed services. The ability to offer anything as a scalable, managed service is a significant power of the cloud. However, because these projects weren’t developed with managed services in mind, each provider will need to make a number of tweaks and adjustments before they can be adopted. We discovered that even if all CSPs want to provide their clients with comparable capabilities, they employ various strategies to get there. In the process of converting non-cloud technology to the cloud, CSPS encounters new security challenges.
