GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

[jimmyl02]

I'm pretty impressed with the GCP response, both the fact that they identified the behavior and took the first step in reaching out.

[londons_explore]

I'm going to take a guess that reading files like /etc/shadow are 'tripwires', which trigger a review by an engineer.

With seccompbpf it's pretty simple to have systemwide tripwires on certain files/syscalls/network operations. Even if the attacker gains root, your tripwire will probably alert you before they can disable it.

[belter]

The other way to see it, is that it took them 8 days to notice a full compromise of the hosting OS and an open access to Google’s internal docker image repository URL.

[jorams]

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?

[ec109685]

It’s marketing for their other products. A pretty annoying read.

[VWWHFSfQ]

Yeah this was terrible.

First, we did a privilege escalation.

How? They don't say.

Next, we did another privilege escalation.

And how?? They don't say.

what's the point of this

[lima]

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.

[cflewis]

I was part of the Cloud SQL team when putting databases in VMs was designed (previously the MySQL process was run in a sandbox).

I am sure Cloud SQL is far more advanced since then (9 years ago), but security in depth was something we thought about a lot. Running in a VM for each database rather than a multi-tenant system was for security more than anything else. We could have multi-tenanted just as easily implementation-wise.

[tidbitruminator]

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.

[Havelock]

It reads like paint two circles... then the rest of the owl.

[breakingcups]

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

[jalk]

I don’t know why, but I was disappointed they didn’t disclose how much the reward was.

[belter]

Per their published table, not more than $13,337

https://bughunters.google.com/about/rules/6625378258649088/g...

[londons_explore]

Hopefully not very much... They were 'caught' by googles security team.

Who knows - if Google hadn't detected the intrusion, this attack might be on the black market by now.

[AtNightWeCode]

"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]

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.

[nitrammm]

No? From the article:

> 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.

So Google took proprietary software not designed for this use-case and built their own security layer on top of it and ended up with bugs.

Of course that's an issue with the service. Presenting it as anything else than an issue in Cloud SQL seems disingenuous.

[londons_explore]

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.

[drewda]

According to the blog post, the vulnerability is not within SQL Server itself, the vulnerability is in the security layer that Google built on top of SQL Server in order to offer it as a managed service on GCP.

[speedgoose]

Isn’t the blur effect too light on the screenshots? I may be possible to recompute the /etc/shadow file.

[kccqzy]

And what would that accomplish? Knowing the contents of /etc/shadow of a random (virtual) machine that belonged to someone else that you could not access, one that most likely already ceased to exist.

[redwood]

Oh boy someone's not going to have a fun long weekend

[dub]

As the article says, the vulnerability was fixed in April and the people who discovered it have already been rewarded under Google's Vulnerability Reward Program. Google also proactively detected the problem before being notified by the researchers.

[coderintherye]

It's already been resolved by Google and is not exploitable, so yes hopefully sysadmins using SQL Server on CloudSQL will indeed have an actually fun long weekend.

[yafbum]

It's responsibly disclosed after the hole is patched.