We’re part of the security resources at SADA, a leading Google Cloud Premier Partner. With our backgrounds being notably diverse, we appreciate the need for visibility of your core access controls.
If you’re involved in securing your enterprise’s Google Cloud Platform (GCP) environment, ideally, the organization policy for Domain Restricted Sharing (DRS) is well-regarded in your security toolbox. In the event DRS hasn’t made its way into your arsenal, after reading this post, please take a moment and review these docs.
While we’re not covering DRS in-depth here, we will be discussing related concepts. We believe it is crucial for an enterprise to maintain full visibility into which identities have access to its GCP resources. DRS is intended to prevent external or non-enterprise managed identities from obtaining or being provided Identity Access Management (IAM) role bindings within your GCP environment.
If we take this one step further, we believe an enterprise should maintain visibility of the use of its managed identities within external GCP environments. This is the basis of the post where we’ll raise a number of concerns.
The SADA security team has found a feature of IAM that presents challenges with detection and mitigation. We’ll refer to this IAM feature as Cross-Domain Sharing (XDS).
Introduction to XDS
Today, external parties with GCP environments can provide IAM role bindings to your enterprise’s managed identities. These IAM policies can be set and made effective without your knowledge or awareness, resulting in GCP resources being accessed beyond the boundaries of your enterprise. While we agree there are a number of valid use cases for these XDS IAM policies, we are not comfortable with the lack of enterprise visibility.
Malicious actors are constantly seeking new avenues to gain any type of foothold within a targeted organization. Targeting Cloud DevOps and SREs with social engineering attacks yields high rewards as these organizational employees have more elevated privileges and trusted relationships.
Acknowledging this mindset, let’s consider the following:
Alice (alice@nullexternal.org) views internal.org as a prime target for a social engineering campaign combined with her newly discovered XDS bug. She quickly spins up a new GCP project called “Production Secrets” and adds a GCP IAM role binding to it for Bob (bob@nullinternal.org) (see the diagram below).
Alice then initiates a social engineering campaign targeting Bob, informing him of the new “Production Secrets” project. As Alice is not part of the internal.org organization, the “Production Secrets” project is presented in Bob’s list of available GCP Projects without an organization association. And, if Bob searches for “Production Secrets” using the search bar of the GCP cloud console, the project will again be presented with no clear indicators it’s not actually affiliated with the internal.org GCP organization. With Bob not wanting to miss any team deadlines related to adopting the new “Production Secrets” project, he migrates secrets over and begins creating new ones within the “Production Secrets” project. Alice rejoices as internal.org’s secrets are now fully disclosed and available for additional attacks.
If your organization’s identities are being used externally, would you be able to prevent, or even detect, this type of activity? If Bob connects to this external project, what other attacks could he be vulnerable to in this scenario?
Keeping in mind Google Cloud’s IAM identities or “members” in IAM Policies can include users, groups, and domains, bad actors can easily increase their target scope from a single user identity to your entire enterprise. Once the nefarious GCP Project “Production Secrets” is in place and accessible by everyone in your enterprise with GCP environment access, the bad actors can wait for unintended or accidental access while developing more advanced phishing ruses.
Now, the good news!
The team at Google Cloud have been hard at work, and they recently released a new GCP Organization Policy constraint specifically to address this concern. The Organization Policy constraint “constraints/resourcemanager.accessBoundaries” once enabled, removes this concern as a broad phishing vector by not presenting external and no-organization GCP Projects within the Cloud Console and associated APIs. While this approach does not address all risks related to XDS, it does reduce the effective target scope.
Before you run and enable this constraint, remember there are valid use cases for XDS, and we recommend identifying all XDS projects and assessing if they are valid, or if they may be adversely affecting your enterprise’s managed identities. This exercise may help you identify external organizations that are contractors, vendors, partners, etc. and should be included in the Organization Policy constraint.
To further reduce the chances of successful exfiltration of your enterprise’s sensitive data from existing GCP resources via XDS abuse, consider also implementing Google Cloud’s VPC Service Controls (VPC-SC).
Is your GCP environment at risk, or do you have security questions about your GCP environment? SADA and IOActive are here to help. Contact SADA for a Cloud Security Assessment and IOActive for a Cloud Penetration Test.
Chris Cuevas, Sr Security Engineer, SADA
Erik Gomez, Associate CTO, SADA
Note: This concern has been responsibly reported to the Google Cloud Security team.