Google Cloud Patches Vulnerability In CloudSQL Service

May 26, 2023 TH Author headline,database,flaw,google,patch

A vulnerability in the CloudSQL service of the Google Cloud Platform (GCP) could have let a bad actor escalate from a basic CloudSQL user to a full-fledged sysadmin on a container and gain access to internal GCP data, such as secrets, sensitive files, passwords and customer data.

In a May 24 blog post, Dig Security researchers said upon discovering the vulnerabilities, its research team followed coordinated disclosure practices with Google, and all issues were resolved quickly. The issue was not assigned a CVE; as in the vast majority of cases involving cloud services, it’s up to the cloud provider to fix the flaw and there’s not much rank-in-file security teams can do.

The Dig Security researchers said they identified the vulnerability through a gap in GCP’s security layer. This vulnerability let them escalate initial privilege and add a user to the DbRootRole role, a GCP admin role. Another critical misconfiguration in the roles permissions architecture also let Dig’s researchers further escalate their privilege, eventually granting their user the sysadmin role. They then bypassed the barrier and got full control on the SQL Server.

Once they assumed complete control on the database engine, Dig Security’s researchers gained access to the operating system hosting the database. At that point they could access sensitive files in the host OS, list files and sensitive paths, read passwords and extract secrets from the machine.

There’s a gray line between products and services, explained Timothy Morris, chief security advisor at Tanium. Morris said vulnerabilities aren’t always tied to a software product’s source code and attackers can exploit them because of misconfigurations. So any vendor offering software as a service, which cloud providers do, are providing services through prebuilt offerings that can use an array of hardware and software combinations, said Morris.

“It’s not unusual for companies to not use the CVE process for disclosing vulnerabilities,” said Morris. “I’m not sure of the exact number, but it used to be that only about 50% of vulnerabilities are assigned a CVE. I would expect that number to be a lot less with services. As always, it’s important to understand what services are being purchased and as much of the components that make up that service offering as possible. Misconfigurations are still the leading cause of cloud data breaches.”

Mike Parkin, senior technical engineer at Vulcan Cyber, added that privilege escalation can become a potential problem in almost any case, as it lets a user gain access to capabilities they shouldn’t have. Parkin said while it’s interesting research from Dig Security, it’s light on details with nothing on how they escalated their privileges. It sounds like they just used basic SQL commands to add their user to a higher privilege group, but there’s not enough detail to tell, said Parkin.

“As for why there isn’t a CVE on this, it appears to be an issue at the cloud infrastructure level, where only the cloud provider themselves could fix the issue,” Parkin said. “It’s not a case where the user can patch, or change configuration, or otherwise mitigate or remediate the vulnerability. It’s a very specific vulnerability with one vendor’s internal platform.”