How to contact Google SRE by dropping a shell in Cloud SQL
offensi.com
offensi.com
> Therefore, if a customer ever enabled Private IP access to their instance, they could be targeted by an attacker-controlled Cloud SQL instance. This could go wrong very quickly if the customer solely relied on the instance being isolated from the external world, and didn’t protect it with a proper password.
I'm not convinced by this, I'm not sure it is vulnerable in the way the author is suggesting "they could be targeted by an attacker-controlled Cloud SQL instance".
First of all, GCE has firewall rules outside of iptables. But the main thing is that the way Cloud SQL does Private IP is via VPC peering. Google creates a VPC on their side, runs MySQL in it, and peers that VPC with your VPC. You actually tell Google what CIDR range to use in the their VPC (the Cloud SQL VPC).
I don't think is it fair to assume that all customers are in the same VPC, and same subnets, with routes between them, and no GCE firewall rules blocking them.
This problem would have probably been avoided if Cloud SQL used different tenant projects per customer (Something most other GCP services do), but for some reason it doesn't do that.
A project can contain multiple VPCs. And a VPC can contain multiple subnets, but not with overlapping ranges.
https://cloud.google.com/sql/docs/mysql/configure-private-se...
If I break it, sure, fine, no problem. IF it's their fault, I expect to be able to hold them to account.
The GKE SLO is something like no more than 3.5 hours of downtime per month.
"I expect to hold them to account".
No - if you are not paying for support you will just be able to claim the credits. You do this by filling out a form within 30 days. That's it.
I think google's higher end service level starts with a $150K/year base fee + cut of spending. That's actually a pretty good deal (1FTE) to have your back much more covered when there are issues - I think they work towards 15 minute response times there. Plus they can help you avoid screwing up your own redundancy planning through reviews of your setup.
What wasn't clear from parent was do they expect to hold google ($100B+/year) to account while spending $2,000/month - that isn't going to happen at all as google as already outlined how they will compensate you for downtime.
Finally - for really large deals you can negotiate with their sales folks.
but do kids these days not know about https://linux.die.net/man/1/wall ?
Edit: I think I was wrong; you can't manipulate network socket fds this way, you'd have to use ptrace() on the process. If it were a real shell with a pty I believe what I suggest could work, but reverse shells don't open ptys.
I didn't know what it stood for, at least :)
NAME wall - write a message to all users
Worrying that the CloudSQL internals (like the private IP range) aren't strongly walled off. It will be interesting to see how this changes in response to the researchers' work.
> the container was configured with the Docker host networking driver (–network=host).
The canonical document on argument injection is here btw:
https://www.defensecode.com/public/DefenseCode_Unix_WildCard...
I want to read more about things like this, but it feels reckless on the authors part ?!
You can read up more of such reports at hackerone.com/hackitivity or just searching about bug bounty writeups for X organization
"Page not found
The page you are looking for does not exist. "
You have to pay for your support and its not cheap.
Its a good thing on one side: You get yourself a cheaper selfservice solution and you can use a ton of stuff until you really need support. Its a bad thing as you haven't thought about this and support costs money.
Big company with Support contract with Google: Its awesome. Srsly. You get an answer in the next 4h, they will experiment, they will talk to the product teams, they will keep you posted etc.
CloudSQL (expensive wrapper around mysql) restricts you changing the wait_timeout which is really terrible when using cloudfunctions OR innodb_flush_log_at_trx_commit. Now! With my own reverse shell I can finally edit the CloudSQL variables and contact a SRE.
https://dev.mysql.com/doc/refman/5.7/en/server-system-variab...
However, it seems like innodb_flush_log_at_trx_commit is not supported indeed.
The Google Cloud console offers a way to export data into cloud storage based on a SQL query expression.
By exploiting a SQL injection vulnerability related to that SQL query expression field, the attacker learned that they had file write access to /mysql/tmp.
The attacker found a second vulnerability affecting the API endpoint used to export data. This endpoint invokes mysqldump behind the scenes.
Then, the attacker creates a database with a malicious plugin embedded in a BLOB. This plugin is a C program that creates a shell process where standard input and output file descriptors are an alias for a socket file descriptor, creating a "reverse shell" where the attacker can execute commands remotely.
Then, this malicious database was imported via mysqldump, and the malicious plugin was written to /mysql/tmp, then loaded, thus executing the malicious plugin.
Using the reverse shell created by the malicious plugin, the attacker found that the process was running in a Docker container using host networking, which could be used by the attacker to monitor network traffic in the VM host machine.
Using traffic monitoring, the attacker found traffic related to the Google Guest Agent, and then used a TCP connection hijack attack to hijack connections to the Google Guest Agent.
The connection hijacking was used to trick the Google Guest Agent to authorize a new SSH user, which was then used to escape the Docker container VM.
>Therefore, if a customer ever enabled Private IP access to their instance, they could be targeted by an attacker-controlled Cloud SQL instance. This could go wrong very quickly if the customer solely relied on the instance being isolated from the external world, and didn’t protect it with a proper password.
Anyone care to expand on that? Would that be common practice?
In practice, this network may only contain instances of limited use cases.
Source: I work in GCP support.
I think I might alias "XYZZY" to "sudo -i" :)
Chilling too.
If SRE can write a file to the filesystem, they can totally copy the database files out too.
I completely support SRE being able to log into instances for debugging, but them being able to do that without leaving an audit trail visible to me, the data owner, isn't up to modern standards IMO.
That button should create for them a fully logged SSH connection to the VM, and the data owner should be notified that SRE has connected. The data owner should then be able to see the commands executed via the SSH connection, and also request an explanation of what the SRE was doing.
The vast majority of instances are going to be things like "your instance hit a SIGSEGV, we logged in to grab the crash dump" or "your instance had a much higher than usage than all other users. We logged in to run tools to find where is was going".
To be more serious, it would be unacceptable for me that an employee can, for whatever reason, access my instance without my express permission and oversight. Even crash dumps could contain very sensitive information.
But it should be possible for a client to audit all accesses, and the audit logging system be robust enough to catch evil employees.
If your threat model is a single rogue employee, auditing systems address the issues. If your threat model is "the whole company works against you", you probably shouldn't be using any company to host your infra, so host it yourself, because there's no way to be secure in that situation.
This seems much more likely than OP's exploration being detected in realtime, then someone SSHing into the container manually to put a message.
Disclaimer: I work at Google, not on Cloud SQL, and don't know anything specific about that greetings.txt.
I interpreted the "new" as meaning that it wasn't there before
In rare cases SRE's reach out to ISE's who contact us on their behalf. In this case a file was added. I personally don't see any reason why this would be a bad thing, it's a managed service and we tried to attack it after all. No data was removed, nor is there any indication that there are no audit trails. I hold both the ISE's and SRE's in extremely high regard. (If you try to Hunt for bugs in GCP you will find out why)
So `docker run --net=host --cap-drop=NET_RAW` seems like it might be a good idea. I wonder if it's still needed for `ping` and such in modern Linux?
[1] https://docs.docker.com/engine/reference/run/#runtime-privil...
I've been reading some Google VRP writeups [2] in order to inspire me in my bug bounty journey. There are a few by Ezequiel Pereira and Offensi. There's some really cool stuff, that go beyond XSS.
[1] https://www.youtube.com/watch?v=E-P9USG6kLs [2] https://github.com/xdavidhu/awesome-google-vrp-writeups
Shellcodes are binary strings that you write to memory or execute another way (like this plugin situation) through an exploit to actually initiate a shell under that process' user id. This can be local on a setuid process for escalation or remote (there are 2 other types in that article in addition to the reverse shell).
How did they get the user wouter created on the host and how did it have sudo access?
Anyway, they have a local process that polls the metadata endpoint and adds authorized keys on the host. So you can e.g. upload your public key in the web UI, their metadata endpoint will serve it up on your instance, the guest agent will poll the metadata endpoint and add your key to the authorized_keys file.
These folks spoofed a response from the metadata endpoint. They used https://github.com/kpcyrd/rshijack to inject their own hand-crafted public key, which the guest agent happily added to authorized_keys (and created the wouter user).
They then ssh'd using their key:
> ssh -i id_rsa -o StrictHostKeyChecking=no wouter@localhost
> Once we accomplished that, we had full access to the host VM (Being able to execute commands as root through sudo).
Looks like they had passwordless sudo as well.
There's also: simply not leaving the gcp login backdoor open. We run our gcp instances similar to ec2: on first boot we take the ssh keys from the metadata service and lay them down and do not run the GCP agent, we have standard config management + ldap for login after the first boot. This means that a hacker gaining access to your GCP credentials can't gain a shell on an existing instance trivially.
But yeah, it seems strange to me that the metadata endpoint isn't secured via TLS. I guess they figured they had sufficiently prevented any kind of MitM attack (but obviously not in this case) so it was unnecessary?
The host VM had this running. Since they had access to the host's network (due to running in a `--network=host` container), they were able to spoof the response from the metadata server to say a new user should be added to `.authorized_keys`, with their supplied public key. The guest agent automatically adds the new users to the `sudoers` group, also giving them sudo access.
I thought it would have been automated by a script. Either they are super fast typers or the metadata server is quite slow!
Will you ever be in MySQL 8