GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

DIG.SECURITY
180
46
ivmoreau
4d

Comments

@jimmyl02 4d
I'm pretty impressed with the GCP response, both the fact that they identified the behavior and took the first step in reaching out.
@jalk 4d
I don’t know why, but I was disappointed they didn’t disclose how much the reward was.
@redwood 4d
Oh boy someone's not going to have a fun long weekend
@lima 4d
Last time I checked, their hosted databases run in dedicated VMs, which is where the real security boundary is.

Getting access to the host OS won't give you much other than some internal binaries and config.

@londons_explore 4d
Remember that MS SQL server isn't Google code... Any vulnerabilities it may contain they might be powerless to fix.

Considering that, Google probably has an extensive monitoring system running in the VM, looking for things happening that shouldn't happen... And they have probably also built a filtering infrastructure between the users and the SQL server so that if any vulnerability is found, they can at least filter attempts to exploit it while a fix is being made.

@tidbitruminator 4d
There is a probably a good reason why they didn't elaborate on this:

"Our research began when we identified a gap in GCP’s security layer that was created for SQL Server."

It would have been interesting to see how they identified that security gap.

@Alien2 4d
[flagged]
@jorams 4d
So this blog post is missing any information about what the actual vulnerabilities were. What was the "gap"? What was the misconfiguration? Also missing is whether access to the host VM exposes meaningful secrets. Does this actually risk customers' sensitive data?
@speedgoose 3d
Isn’t the blur effect too light on the screenshots? I may be possible to recompute the /etc/shadow file.
@AtNightWeCode 4d
"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."

Fascinating how sloppy some people are when they set up infrastructure even though this may be down to bad defaults.

@mcstafford 3d
The vulnerability sounds like it's inherent to SQL Server, and that cloud providers haven't been successful in blocking the underlying problem due to its proprietary nature.

Presenting it as a Cloud SQL problem is disingenuous.

@breakingcups 3d
This article is lacking the actual interesting bit, which is how was the escalation achieved? Just reads like bragging instead of being informative.