GCP organizations can be used to easily manage resources (Such as projects, billing accounts, IAM roles, etc.) in one single place. Most resources cannot be detached from the organization they were created in, and even though they can be deleted, most of them can be restored within a month.
Because of this, it is important that users pay attention to where they are putting their resources, for example: if for some reason they created a billing account on an organization they do not trust, they could end up being charged for the actions of someone else.
But, how could they even get to create a resource in an organization?
Well, they could either:
- Be part of the G Suite/Cloud Identity domain (i.e. An employee, or a student), and it wouldn’t be anything unexpected.
- Or the organization can be shared with them.
GCP organizations can be shared with any Google user through the Cloud Identity & Access Management (IAM).
So, if I shared it with several users, maybe one of them could accidentally create a resource in it, and I could manage that resource however I want.
But, GCP organizations have names, their domains, so my organization was called “ezequiel.tech“, wouldn’t everyone realize they are creating resources in a weird organization they never saw before?
Usually yes, but I found that for some reason this name could be changed through the (deprecated) organizations.update method in the Resource Manager, even though the documentation said the “displayName” was read-only.
With this, I could have my own organization and name it as another one and confuse users:
- I name my organization “
.com “ - Share it with “domain:
.com ” (Effectively sharing it with every Google user with a @.com account) - Profit from unsuspecting users creating resources in my organization, specially billing accounts (Which can be closed, not deleted, and I can just re-open them and use them), or building projects that manage sensible information (For instance, a project that access other servers I previously had no credentials for)
There was another issue too, if I shared my GCP organization with a normal (@gmail.com) user, whenever they create a project the Google Cloud Console interface forced them to choose an organization, if mine was the only one they had access to, they would be forced to create a project in it (Note: The underlying API can create organization-less projects with no issue).
I could have easily had called my organization “No organization” (There was no requirement for it to be a domain) and probably most users would have never realized what happened.
For some reason this also removed the Google Cloud Platform free trial banner if the victim hadn’t signed up to it already.
Considering the simpleness of this attack (An attacker could just buy a $4 domain, and sign up for the 14-day free trial of G Suite and then create a GCP organization), and the effects this could have, I reported the issue to the Google Vulnerability Rewards Program.
They quickly fixed the causes of this issue, so now it is not possible to change the name of an organization, and when sharing it, users are not forced by the interface to create resources in the organization.
Also, according to Google, this issue had an interesting effect if done against the “google.com” organization (They internally use “google.com” as a GCP organization for internal stuff), the fake organization would look more realistic than the real “google.com” organization, they even have a picture of how this looked like:
Picture the Google Security Team sent me: A fake organization is on top, the one below is the real one.
Obviously attacking the “google.com” organization could’ve had big effects, since confused Google employees using Google Cloud Platform could had created resources without realizing their mistake and do internal/confidential stuff (Although Google probably has lots of checks in order to avoid serious issues, and, after all, the platform if theirs).
Because of all of this, on January 29th, 2019, I got a reward of 7500 dollars.
Timeline
- Issue found and reported on November 29th, 2018
- Issue quickly fixed
- Reward decision delayed (Holidays)
- Reward of $7500 issued on January 29th, 2019