[HN Gopher] GCP CloudSQL Vulnerability Leads to Internal Contain...
___________________________________________________________________
GCP CloudSQL Vulnerability Leads to Internal Container Access and
Data Exposure
Author : ivmoreau
Score : 151 points
Date : 2023-05-26 17:04 UTC (5 hours ago)
(HTM) web link (www.dig.security)
(TXT) w3m dump (www.dig.security)
| jorams wrote:
| 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 wrote:
| It's marketing for their other products. A pretty annoying
| read.
| VWWHFSfQ wrote:
| 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
| qwertox wrote:
| They skipped all the interesting parts.
| AtNightWeCode wrote:
| "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.
| Alien2 wrote:
| [flagged]
| lima wrote:
| 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.
| redwood wrote:
| Oh boy someone's not going to have a fun long weekend
| dub wrote:
| 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 wrote:
| 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 wrote:
| It's responsibly disclosed after the hole is patched.
| tptacek wrote:
| 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.
| yafbum wrote:
| As a customer, I'm glad that both the vendor and the
| researcher are acting responsibly
| fragmede wrote:
| But I got my pitchfork out and everything!
| jimmyl02 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| kccqzy wrote:
| The hosting OS is all but certain to be virtualized. It's no
| different from customers creating a GCE VM in the first
| place.
| [deleted]
| twunde wrote:
| 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
| belter wrote:
| To start getting info from the team, as nothing indicates
| that at that time, Google knew where the vulnerability was.
| londons_explore wrote:
| 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!
| azurezyq wrote:
| I was part of GCP Cloud Dataflow team a few years ago. The
| status page is actually the standard for all google
| internal services (/statusz). I still miss them much.
|
| In dataflow's case, container is not treated as the
| boundary. And there are several important things to note:
|
| - Dataflow's VMs are in customer projects, so there's no
| risk of cross-tenant access.
|
| - When launching dataflow jobs, the launcher identity is
| checked to have iam.serviceAccountUser IAM role, which
| means that the identity should be able to launch a VM with
| the same service account just fine. So dataflow is not
| escalating the permission beyond GCE VMs.
|
| - Just as VM launched by someone, if anyone else can log
| onto those VMs are controlled separately.
|
| - Container is used in dataflow only for convenient image
| delivery, not for a security barrier. VM is.
| lima wrote:
| Yes. They don't want you to be able to poke around but the
| real security boundary is the VM, not the database server.
| hn_throwaway_99 wrote:
| 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.
| mcstafford wrote:
| 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 wrote:
| 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.
| breakingcups wrote:
| This article is lacking the actual interesting bit, which is
| _how_ was the escalation achieved? Just reads like bragging
| instead of being informative.
| jalk wrote:
| I don't know why, but I was disappointed they didn't disclose how
| much the reward was.
| belter wrote:
| Per their published table, not more than $13,337
|
| https://bughunters.google.com/about/rules/6625378258649088/g...
| londons_explore wrote:
| 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.
| tptacek wrote:
| Probably not. There's no coherent market for serverside
| vulnerabilities of any sort.
| speedgoose wrote:
| Isn't the blur effect too light on the screenshots? I may be
| possible to recompute the /etc/shadow file.
| londons_explore wrote:
| 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 wrote:
| 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.
| tidbitruminator wrote:
| 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 wrote:
| It reads like paint two circles... then the rest of the owl.
___________________________________________________________________
(page generated 2023-05-26 23:00 UTC)