Live data from Hacker News

GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

dig.security

21–30 of 54 posts

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#21

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.

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

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#22
post #4

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

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.

Probably not. There's no coherent market for serverside vulnerabilities of any sort.

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#23
post #7
post #2

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

It's responsibly disclosed after the hole is patched.

The term of art is "coordinated" disclosure. All sorts of disclosures, with or without vendor consent, can be "responsible", so we try not to use that term, which was coined as a device to give vendors power over researchers.

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#24
post #10

Earlier quoted context omitted.

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.

I'm going to guess that this VM was considered the 'customers' VM as far as security goes... Ie. you couldn't access any other customers data. Likewise, GCP Dataflow quite trivially allows you to escape onto the worker machines and take the (huge) binaries that implement it. They have some really nice detailed status pages!

Yes. They don't want you to be able to poke around but the real security boundary is the VM, not the database server.

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#25
"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.

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#26
post #20

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?

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

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#27
post #24

Earlier quoted context omitted.

I'm going to guess that this VM was considered the 'customers' VM as far as security goes... Ie. you couldn't access any other customers data. Likewise, GCP Dataflow quite trivially allows you to escape onto the worker machines and take the (huge) binaries that implement it. They have some really nice detailed status pages!

Yes. They don't want you to be able to poke around but the real security boundary is the VM, not the database server.

Back when there was a critical Azure bug that enabled an Azure user to gain access to top-level keys (i.e. the keys to the entire kingdom), a Google engineer commented on an HN thread that Google specifically didn't consider container boundaries secure, so everything is always tied to a VM specific to a customer. The issue with Azure is that a container escape allowed a user to take over the entire Azure subsystem.

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#28
post #20

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?

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

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#29
post #10
post #3

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

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.

It took 8 days to proactively reach out. It may very well have been identified earlier and then taken some time to be passed off to Google's vulnerability reward program and get any approvals necessary
Post reply on HN