Google Cloud Bug Allows Server Takeover From CloudSQL Service
Google has fixed a critical flaw in its Google Cloud Platform’s database service that researchers used to gain access to sensitive data and secrets, as well as escalate privileges to breach other cloud services, including potentially those in customer environments.
Researchers at Dig Security identified the vulnerability through a gap in the security layer around the CloudSQL service of GCP, which supports several different database engines — including MySQL, PostgreSQL, and SQL Server — for use in the environment, they revealed in a blog post on May 25.
The vulnerability allowed them to escalate initial privileges and add a user to the DbRootRole role, which is an admin role in GCP, Dig Security’s Ofrir Balassiano and Ofrir Shaty revealed in the post.
From there, they exploited another critical misconfiguration in the roles-permissions architecture, to further escalate their privilege, eventually granting the malicious user a system administrator role to gain full control on the SQL Server. After that, they were able to access the OS 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,” the researchers wrote in the post. “In addition, the host has access to the underlying service agents which could potentially lead to further escalation to other environments.”
This latter aspect of the vulnerability could have given an attacker exploiting the flaw access to resources in customer environments that leverage GCP, they said.
Discovering the flaw in February, Dig Security followed coordinated disclosure practices using Google’s vulnerability award program to notify the company of the issue. The companies worked together over the following two months, and Google addressed and resolved the issues in April, rewarding Dig through its bug bounty program on April 25, the researchers said.
Navigating Google Cloud Platform’s SQL Permissions
The full exploitation of the vulnerability was a multistep process, the first of which was made possible through the default permissions on GCP SQL Server, the researchers explained.
There are two levels of permissions that a user can attain on GCP SQL Server — those at the server level and those at the database level — a point that’s important to understanding how the flaw works, they said.
Server permissions contain operations that are done on the instance level within the cloud, while database permissions are for operations done inside the database instance itself, the researchers explained. Within those, “CONTROL SERVER” is the most powerful permission a user can be granted on the instance level, while “CONTROL DATABASE” is the most powerful permission a user can be granted on the database level, they said.
The default login for SQL Server gives a user the GCP role “CustomerDbRootRole,” which does not allow for using the “create/alter” command to do anything on the server level. It also has no permissions on sys objects, which means that the user cannot create objects in any system database, they explained. So, to complete the attack, they needed to elevate their privileges.
Exploiting the SQL Server Flaw
Researchers identified a gap in the security layer created for SQL Server within GCP that allowed them to escalate their initial default privileges, and add the user they created to the DbRootRole role, which is a GCP admin role, they explained in the post.
Once the researchers achieved this role, they could perform several tasks that they couldn’t do before; however, as it is not a sysadmin role, they still didn’t have full permissions on the SQL Server, they said.
They eventually discovered a path to success using a critical misconfiguration — a common issue found in cloud environments — in the roles-permissions architecture, which allowed them to further escalate privileges, granting the user a sysadmin role that allowed full control on the SQL Server, they said. This is what gave them full access to the OS hosting the database and all of its sensitive files, passwords, secrets, and other key data, the researchers said.
Moreover, the host has access to the service agents that connect to resources in customer environments, putting enterprises who use GCP to run systems in their own environments at risk, the researchers said.
“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,” they wrote in the post.
Using their access to the OS, researchers also discovered internal Google URLs related to the Docker image repository that allowed them to access the internal repo, which Google also fixed in its remediation, they said.
Mitigating Cloud Cybersecurity Risk
Cloud misconfigurations are still common reasons for holes in cloud security, posing risks for customers. In the case of the flaw that Dig researchers found, one issue that made Google Cloud complicated to secure is that SQL Server is not open source, which means a security layer had to be built around it, Balassiano tells Dark Reading.
Indeed, as more more data is stored in cloud environments, organizations should apply data security controls regardless of what their cloud providers are offering to protect themselves even if the provider’s environment has a flaw, he says.
“Data security platforms that offer a combined DSPM (data security posture management) and DDR (data detection and response) can reduce the chances of bad actors succeeding in exfiltrating data without a fast response,” Balassiano says.
To avoid potential exploit of a flaw like the one the team found, organizations can benefit from deploying a DSPM solution that locates their most sensitive data and ensures it is protected, he says. This means that even if there is a breach, the data is encrypted and the exposure is contained.
“To get ahead of the breach, they should also apply DDR which prevents data misuse and data exfiltration by providing real-time detection and response,” Balassiano adds.