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.
GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure
21–30 of 54 posts
Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure
#22I 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.
Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure
#23Oh boy someone's not going to have a fun long weekend
It's responsibly disclosed after the hole is patched.
Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure
#24Earlier 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!
Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure
#25Fascinating 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
#26So 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?
Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure
#27Earlier 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.
Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure
#28So 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?
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
#29I'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.