GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

Originally published by Dig Security.

Written by Ofir Balassiano and Ofir Shaty.

One of the top three cloud providers is Google Cloud Platform (GCP), which offers a range of services including a managed database service called CloudSQL. CloudSQL is capable of supporting three different database engines: MySQL, PostgreSQL, and SQL Server.

By their nature, databases tend to contain large amounts of information, and often contain sensitive information such as PII, Developer Secrets, and even financial data like bank accounts or credit cards. In our research, we chose to focus on CloudSQL because of its potential impact on customer data.

Many vulnerabilities have been disclosed in MySQL and PostgreSQL hosted in all 3 major cloud environments (GCP, AWS and Azure). The integration of database engines to native CSP services required significant changes to be made which exposed new risks and vulnerabilities. Unlike the other two, SQL Server is not an open-source DB, which means that it could not be modified by the cloud providers. To integrate SQL Server to their environments, cloud providers built their own security layer on top of the database engine.

In this blog, we reveal a new critical vulnerability in GCP CloudSQL service that was discovered by our Dig research team.

SQL Server Basics

SQL server has 4 system databases:

Understanding SQL Server permissions: server permissions vs. database permissions

To gain a better understanding of this new vulnerability and its impact, it’s important to understand how permissions are structured in SQL server.

Server permissions contain operations that are done on the instance level, for example CREATE / ALTER / DROP database (or other objects like logins, audit etc.)
that is considered at the server level.

`CONTROL SERVER` is the most powerful permission a user can be granted on the instance level.

Database permissions contain CREATE / ALTER / DROP on objects inside the database (like tables, triggers, users etc.).

`CONTROL DATABASE` is the most powerful permission a user can be granted on the database level.

Default permissions on GCP SQL server

The default permissions that are granted to a user define the starting point to our research as described below:

• The default login and user for SQL Server on GCP is `sqlserver`, and is granted with the GCP role `CustomerDbRootRole`.
• This role does not allow the default `sqlserver` user to create/alter anything on the server level.
• The default user has no permissions on sys objects, which means that the user cannot create objects in any system database.

Vulnerability discovery: escalating from a basic CloudSQL user to full-fledged sysadmin on the container

Following are the steps in which this vulnerability was uncovered:

First hop: privilege escalation to DbRootRole

Our research began when we identified a gap in GCP’s security layer that was created for SQL Server. This vulnerability enabled us to escalate our initial privilege and add our user to the DbRootRole role, a GCP admin role.

The screenshot below shows that the principal `sqlserver` is a member of both `DbRootRole` and `CustomerDbRootRole`:

Second hop: Gaining control on the host container

With the role `DbRootRole` we were able to do many things that we didn’t have permission to do before. Still, the `DbRootRole` is not a sysadmin role and doesn’t have full permissions on the SQL Server instance.

As our research progressed, we found another critical misconfiguration in the roles permissions architecture, which enabled us to further escalate our privilege, and this time we could grant our user the `sysadmin` role.

At this point we bypassed the barrier and got full control on the SQL Server.

`sqlserver` user default privileges

`sqlserver` user privileges after second privilege escalation

The Impact: Gaining access to all the data

By assuming complete control on the database engine, our user was granted access to the operating system hosting the database. At this point we could access sensitive files in the host OS, list files and sensitive paths, read passwords, and extract secrets from the machine.

In addition, the host has access to the underlying service agents which could potentially lead to further escalation to other environments.

Gaining access to internal data like secrets, URLs, and passwords can lead to exposure of cloud providers’ data and customers’ sensitive data which is a major security incident.

With access to the operating system, we managed to find some internal Google URLs related to the docker image repository. We could also access the internal repo which later was fixed and the access from non internal IPs was blocked.

Google’s internal docker image repository URL:

‍Reading /etc/passwd:

The disclosure process: Collaborating with Google VRP Program

The professional team at Google identified our research activity within 8 days of our initial vulnerability discovery. The team reached to us with the following email:

The following weeks were dedicated to collaborating with the Google team to address the newly discovered security vulnerability, resolve it, and handle the necessary formalities related to the finding.

Needless to say that if you tried to follow the hops described above - it is no longer possible.

The following is a quote from a Google spokesperson: “An external party recently identified a vulnerability with Cloud SQL for SQL Server and reported it through the VRP program. Google security teams investigated and mitigated the issue and no customers were impacted.”

Research Timelines

• February 5th 2023 - GCP CloudSQL vulnerability discovered by Dig’s research team.
• February 13th 2023 - Google’s vulnerability reward program identified activity and reached out to Dig’s research team.
• During April 2023 -The vulnerability was successfully addressed and resolved.
• April 25 2023 - We were rewarded by GCP VRP program.