In a recent report, threat hunting firm Hunters revealed a concerning design issue in how Google Cloud’s Identity and Access Management (IAM) integrates with Google Workspace’s Domain-Wide Delegation feature.
In essence, Domain-Wide Delegation could allow a compromised Google Cloud IAM user account to perform discovery actions in GCP, access sensitive data, and carry out actions across an entire Google Workspace domain.
This Hunters paper proposes two risky scenarios:
Scenario 1: The attacker compromises access to an already delegated Google Cloud IAM key and uses it to do bad things in Workspace. Or the attacker compromises a workspace Super Admin and delegates a key in another Google Cloud organization, since there is no domain limitation and cross organizational delegation works just fine.
I have seen a few apps do the second option for admin management reasons. This option is generally a bad idea since cross-organization delegation is invisible from monitoring.
Scenario 2: DeleFriend “Attack” – “Compromise an existing delegation”
With Domain Wide Delegation, Google only validates the key secret value and Oauth id (ID attached to the Google Cloud IAM user for the key) not the key ID. Scenario 2 is really the new attack right here.
That is, if the attacker can compromise the IAM user in Google Cloud, or have the permissions to create a different key on that same IAM user in Google Cloud, they can use a second key and the Google API to list out all the other keys, scopes (permissions), and a few more pieces of info needed to gain access into Google Workspace – all without ever needing the secret from the first key that was delegated.
So with a second key on the same IAM user, they can now use it with the right scopes and Oauth ID just like the first key.
What does this all mean?
Successful abuse of the Domain-Wide delegation feature exposes sensitive data stored within Google Workspaces (e.g. emails, files stored in drive, calendar, etc.) as well as access to Security and Administration tools. Hunter reports that abuse of this feature by threat actors has been observed in the wild.
Things to do when using Google Domain Wide Delegation
Understand what scopes (permissions) you are granting to that Google Cloud IAM user. Make the permissions as minimal as possible. Use read-only scopes if you can, and never store the json keys locally once you’re done setting things up. Those secret key files xxxxx.json are a prime target for attackers, so don’t keep them around.
Stay informed on the latest risks with practical, no-nonsense breakdowns. Follow Blumira on LinkedIn for notications on blog posts like This Vuln.
