Back 
If an attacker compromises a Google Cloud Platform (GCP) user’s device, he can easily steal and abuse cached credentials, even if MFA is enabled.
In this blog post, we will demonstrate an attack in real Google Cloud environments, involving:
- Hijacking cached OAuth tokens stored on a GCP administrator’s client machine
- Reusing existing gcloud CLI sessions to gain access to multiple GCP environments,
- Showing that MFA does not apply to OAuth token refreshes for cached credentials (only the initial login)
- Discussing broader implications for service account keys
We will use realistically configured Google Cloud environments, as well as client machines where the initial compromise would happen. To demonstrate the attack, as well as defensive measures, we will alternate among the Google Cloud and G Suite Admin Consoles, the Google Cloud SDK command-line tools (gcloud and gsutil), and Stackdriver log events to demonstrate commands in the attack as well as administrative tasks for defensive measures.
This blog is from the attacker’s viewpoint, and later, in OAuth Token Hijacking in Google Cloud (GCP), Part 2, we will discuss what users can do to detect with Stackdriver Logging or G Suite Auditing Logs, remediate compromised tokens/access, and prevent such an attack in the first place.
OAuth
All authentication in Google Cloud uses the OAuth protocol underneath, regardless of whether you log on interactively via the browser or programmatically access GCP via the SDK. Here is a simplified, high-level view of the OAuth flow for programmatic access to GCP from an external GCP administrator’s machine (e.g. laptop):
- Access is requested (OAuth access token request). A GCP user typically sees this step when initially authenticating with the CLI, and a browser is launched to authenticate you, and you approve access. Part of requesting a token is to specify what scopes of permissions you are requesting–this is the prompt asking for your approval for access in the browser that is launched.
- An OAuth session access token and refresh token are created and returned. The session tokens expire after an hour and can be refreshed/regenerated by using the refresh token. These session and refresh tokens are cached.
- The access token is used for subsequent authentication for all API calls.
Token Hijacking for CLI (Bulk Credential Copy)
If we gain initial access to a laptop of a GCP administrator with normal user privileges, we can immediately access the user’s current gcloud sessions that include the cached OAuth access tokens:
The account, [email protected], has MFA enabled with a hardware security key. Let’s see what happens when we switch to that account.
We’ve switched accounts without trouble, but let’s see if the account works i.e. the credentials (tokens) are up-to-date and determine what we can access.
So, we were able to switch to the production account prod-mfa-hw.com and access a production bucket sensitive-bucket using the cached gcloud credentials (note: gsutil and gcloud share cached credentials). There was no prompt to reauthenticate when switching to the production account. In addition, MFA is enabled on this production account, but it has no effect on reauthentication.
The actual cached credentials are OAuth access and refresh tokens generated during the initial authentication (gcloud auth login). On Linux/macos, they are stored in ~/.config/gcloud, while on Windows they are stored in C:\Users\<username>\AppData\Roaming\gcloud.
The .db files are sqlite database files with a legacy directory containing text files per account. We’ll look at these files in more detail in the next scenario.
For now, let’s see how easy it is to copy these credentials off-machine and use them. Let’s just tar up the files, copy to another machine, and see what happens.
