Intro
IT security has been a topic of my interest for a long while; being looped in related topics at some depth since my teenage days. While I am listed in the Android Security Acknowledgements page for some of my reports dated around 2015, being credited by the VRP team as well was on also my bucket list. I decided to promote it to one of my New Year’s resolutions at the end of 2019 — this write up is about researching Google’s domain. Since this is a hobby, I had to carry it out in my free time after completing 9 hours as a software developer at an enterprise. The route was also hardened by a lovely new factor (so definitely not covid): doing that without pushing my first child in the background. She is now 13 months old, so this was a real challenge! :)
Early attempts
I started with focusing on some of the mainstream products (Hangouts, Drive, Sheets), but couldn’t find anything important. I reported a not really practical information disclosure flaw in Hangouts, which landed me in the honorable mentions section of the Bughunter page. A side product of this research is published here, a tool that can reconstruct the protocol buffer definition based on API error messages under certain circumstances — circumstances I haven’t seen in any other Google products yet. In my second attempt, I reported usage of a quite old headless Chrome instance leveraged by the Google-Document-Conversion internal service (41.0.2272.118 — more than 5 years old with hundreds of known security issues). Remember the phrase on the bug submission form? “Around 90% of reports we receive describe issues that are not security vulnerabilities, despite looking like one.” This ticket was rejected quickly — hinting the browser is running in an isolated segment of the infrastructure by design.
Then I found a java deserialization issue leading to code execution in an open-source Google product — but that API method was exposed to more privileged users only, which I felt isn’t “good enough”, so I didn’t even report it at all (which I think was a mistake — so I gonna revisit this early next year). I rather concluded that I’ll have to try harder and be smarter at selecting the targets. I decided to suspend my Google efforts temporarily and focus on Microsoft in my precious free 10 minutes :). After some months this yielded in an EoP and an arbitrary file read vulnerability —I also contributed back some minor improvements to OleViewDotNet, an awesome Google Project Zero tool.
OSConfig
Later on, I switched the context back to Google. After a while, I came across the OS configuration management product, a solution “to deploy, query, and maintain consistent configurations (desired state and software) for your VM instance (VM)”. Linux VMs have the related “google_osconfig_agent” running by default (since the Windows platform is supported as well, I guess the same is true for that OS too) and it is running as root. It is effectively a daemon application polling the https://osconfig.googleapis.com service and the Metadata server to learn whether it has anything to do. The actions supported by this agent include the typical “run these lines of commands” recipe. The agent is written in Go, you can find the source code on Github.
By reviewing it manually I could relatively quickly identify a potential attack vector — the service was relying on temporarily files created in a subdir of a world writeable location (/tmp) with a predictable name, which is an anti-pattern in case of applications running with high privileges. When the agent received a new recipe to be executed, it executed the following relevant syscalls:
This means, a compromised application or a low-privileged user in a Virtual Machine GCE, could mount a race condition attack to hijack this directory, replace the recipe and thus execute code with elevated privileges.
Consider this os-config policy:
Then running the exploit script powered by inotify to monitor the tmp dir, I could prove that it was indeed possible to win the race:
And the proof indicating the exploitation was successful:
Just like any vulnerabilities, exploitation of this one has some conditions to be met, too. The key point was taking over the “base directory” (/tmp/osconfig_software_recipes) which is possible if no recipes have been processed in the current session yet, which means:
- no recipes have been executed at all so far (e.g. the osconfig feature was not in use, but will be at some point later)
- the VM is rebooted and all recipes are present in the db (/var/lib/google/osconfig_recipedb), but some policy updates are executed at some point later
While this special combination indeed decreases the likelihood of exploitation, I think relying on a working directory in /tmp is not secure here. Neither did Google, my report was finally accepted! You can find the timeline and the code behind it in this Github repo. The fix itself — using ioutil.TempDir instead –, can be found here.
Follow up findings
We are around the end of the summer, and I’ve some more to share, but unfortunately without full disclosure due to them not being fixed (completely) yet.
While googling for my osconfig privesc, I found an advisory by Chris Moberly about a similar service of Google: oslogin. His idea to hijack the metadata server is brilliant and inspired me to dig into something relevant which evolved into my next finding at Google. Though this bug has the potential to affect other cloud providers as well, I found AWS, Azure, and Digital Ocean are not due to other factors or security controls. I can’t disclose more details yet, but stay tuned, this can be uncovered in Q1 2021 hopefully. Unfortunately, this also means this bug is not eligible in the VRP contest — according to the current set of rules, bugs must be fixed and the article must be published in the same calendar year. I believe this disqualifies quite a few nice findings — so Google is considering adjusting the rules. Of course, don’t take this for granted until it’s announced officially.
Later on, after I read Offensi’s article that won the GCP VRP Prize last year, I started messing with Cloud Shell. After a dead-end with git (hah a target again that has been assessed by many already), I started looking into the cgo features of the Go language. Shortly after I found a way to execute arbitrary code while “go get” is executed — a build process that is advertised as having no such side effects. This got a CVE assigned — CVE-2020–28367 with CVSS 7.5 The fix on Github is here. As Go is a core dependency of many services in Google land, anything that relied on the vulnerable versions of the Go compiler ecosystem needs also to be bumped. Since this issue is not closed in the official tracker, it means this isn’t complete yet.
I was not the only one inspired by Offensi (btw, the gopath concern kicked off this research for me too!), I think there were at least 15 similar bugs in Cloud Shell in the past 2 years. You may also be interested in the “Go’s Recurring Security Problem” article. Google realized this and deployed a new security control in Cloud Shell:
Opening a link without explicitly selecting “Trust” will provision a new VM without your home directory attached and without access to the oauth tokens via the metadata server. I learned about this change when I reported one more similar issue a few days ago :)
Since I’ve mentioned some findings in this post that are not related to Google, let me add a link to this OpenOffice flaw and hint at one more Microsoft EoP finding that I found in a service that has a long history of security issues. To continue my tradition of finding a hole if I buy a new phone, I reported a security issue to Huawei as well.
Wrap up
I encourage everyone to read the advisories of fellow researchers — it is an invaluable source of more tricks and sometimes could even give you an idea about what to target next. You can read some really impressive Google VRP write-ups here.
I was uncertain whether Google accepts my osconfig finding or not (due to its requirements and since the service is still in beta stage). It was unnecessary — my overall experience is that Google’s decisions were fully reasonable. So don’t worry and rather just file a report — also remember their platform is a moving target, security controls are being improved constantly and the race in the community is big.
My initial goal of getting a VRP trophy is accomplished — actually outperformed by being in the top 100 of the hall of fame currently. Now I am considering to go for bug bounties full time (#will-hunt-bugs-for-food) — a decision to be made tomorrow.
