A design flaw in Google Workspace’s domain-wide delegation feature, discovered by Hunters’ Team Axon, can allow attackers to misuse existing delegations, enabling privilege escalation and unauthorized access to Workspace APIs without Super Admin privileges. Such exploitation could result in the theft of emails from Gmail, data exfiltration from Google Drive, or other unauthorized actions within Google Workspace APIs on all the identities in the target domain.
Snippet from DeleFriend: enumeration of custom roles
Domain-wide delegation permits a comprehensive delegation between Google Cloud Platform (GCP) identity objects and Google Workspace applications. In other words, it enables GCP identities to execute tasks on Google SaaS applications, such as Gmail, Google Calendar, Google Drive, and more, on behalf of other Workspace users.
The design flaw, dubbed “DeleFriend,” allows potential attackers to manipulate existing delegations in GCP and Google Workspace without possessing the high-privilege Super Admin role on Workspace, essential for creating new delegations. Instead, with less privileged access to a target GCP project, they can create numerous JSON web tokens (JWTs) composed of different OAuth scopes, aiming to pinpoint successful combinations of private key pairs and authorized OAuth scopes which indicate that the service account has domain-wide delegation enabled.
The root cause lies in the fact that the domain delegation configuration is determined by the service account resource identifier (OAuth ID), and not the specific private keys associated with the service account identity object.
Additionally, no restrictions for fuzzing of JWT combinations were implemented on the API level, which does not restrict the option of enumerating numerous options for finding and taking over existing delegations.
This flaw is amplified by the following:
Long life: By default, GCP Service account keys are created without an expiry date. This feature makes them ideal for establishing backdoors and ensuring long-term persistence.
Easy to hide: Creating new service account keys for existing IAMs or setting a delegation rule within the API authorization page is easy to conceal. This is because these pages typically host a wide array of legitimate entries, which are not examined thoroughly enough.
Awareness: IT and Security departments may not always be cognizant of the domain-wide delegation feature. They might especially be unaware of its potential for malicious abuse.
Hard to detect: Since delegated API calls are created on behalf of the target identity, the API calls will be logged with the victim details in the corresponding GWS audit logs. This makes it challenging to identify such activities.
A particular GCP permission is needed on the target Service Accounts to execute the attack method. However, Hunters observed that such permission is not an uncommon practice in organizations, making this attack technique highly prevalent in organizations that don’t maintain a security posture in their GCP resources. By adhering to best practices and managing permissions and resources smartly, organizations can dramatically minimize the attack method’s impact.
Hunters has created a proof-of-concept tool (full details are included in the full research) to assist organizations in detecting DWD misconfigurations, increasing awareness, and reducing DeleFriend’s exploitation risks. Using this tool, red teams, pen testers, and security researchers can simulate attacks and locate vulnerable attack paths of GCP IAM users to existing delegations in their GCP Projects to evaluate (and then improve) the security risk and posture of their Workspace and GCP environments.
Hunters responsibly reported DeleFriend to Google as part of Google’s “Bug Hunters” program in August, and are collaborating closely with Google’s security and product teams to explore appropriate mitigation strategies. Currently, Google has yet to resolve the design flaw.