** **DISCLAIMER ****
Anyone who uses domain wide-delegation of authority and exposes their service account credentials is vulnerable to the issue described below. This means the blog post does not reveal any 0-day vulnerabilities in the described products, It is a shared responsibility issue.
It is not rare for a modern web application to have OAuth integrations, each of them requires specific set of security policies to be implemented. By exploiting a broken business logic of a web app, it can be possible to retrieve even Google service account credentials integrated through the OAuth flow and compromise all GSuite users by delegating specific permissions in the GSuite domain.
For our example let’s assume that the application has a specific enterprise focus with most of 3rd party services integrated through OAuth flows. The application then relies on these integration to provide added features and unique solutions. Furthermore, one central feature is the integration with GSuite.
When reviewing web applications it is very important to pay special attention to how the application behaves and what kind of business logic it has. For example, an admin user can update company settings through the following API endpoint:
PUT /api/settings/0921899e-c347-11ec-9d64-0242ac120002/update HTTP/2
Host: vulnerable.com
{"integration.name":"GSuite - takeover"}
If this API endpoint responds with a long list of company fields, and by reviewing all of them you identify something like “google_service_account” field, it is probably a Google service account credentials:
"google_service_account":{
"type": "service_account",
"project_id": "[PROJECT-ID]",
"private_key_id": "[KEY-ID]"
"private_key": "-----BEGIN PRIVATE KEY-----\\n[PRIVATE-KEY]\\n-----END PRIVATE KEY-----\\n",
"client_email": "[SERVICE-ACCOUNT-EMAIL]",
"client_id": "[CLIENT-ID]",
"auth_uri": "<https://accounts.google.com/o/oauth2/auth>",
"token_uri": "<https://accounts.google.com/o/oauth2/token>",
"auth_provider_x509_cert_url": "<https://www.googleapis.com/oauth2/v1/certs>",
"client_x509_cert_url": "<https://www.googleapis.com/robot/v1/metadata/x509/[SERVICE-ACCOUNT-EMAIL]>"
}
An API can be designed to support several methods at the same API route. All the methods are served for a specific reason, and execute their own business logic.
Taking a look at the GET method for that API endpoint example, the application does not return those credentials, but the PUT method does. So it is valuable to review all the supported methods for the same API route (endpoint), since they can return different datasets.
This data leak could be chained with another attack to potentially leak the data to an attacker. It can be an IDOR, XSS, misconfigured CORS attacks. Let’s review an example case with an XSS attack, where the payload would update any company setting and then redirect the application response to a malicious web server.
But before moving to the exploitation step, we need to get more information what google service credentials are)