Netskope named a Leader in the 2022 Gartner® Magic Quadrant™ for Security Service Edge. Get the Report.

  • Platform

    Unrivaled visibility and real-time data and threat protection on the world's largest security private cloud.

  • Products

    Netskope products are built on the Netskope Security Cloud.

Netskope delivers a modern cloud security stack, with unified capabilities for data and threat protection, plus secure private access.

Explore our platform
Birds eye view metropolitan city

Netskope Named a Leader in the 2022 Gartner Magic Quadrant™ for SSE Report

Get the report Go to Products Overview
Netskope gartner mq 2022 sse leader

Make the move to market-leading cloud security services with minimal latency and high reliability.

Learn more
Lighted highway through mountainside switchbacks

Prevent threats that often evade other security solutions using a single-pass SSE framework.

Learn more
Lighting storm over metropolitan area

Zero trust solutions for SSE and SASE deployments

Learn more
Boat driving through open sea

Netskope enables a safe, cloud-smart, and fast journey to adopt cloud services, apps, and public cloud infrastructure.

Learn more
Wind turbines along cliffside
  • Customer Success

    Secure your digital transformation journey and make the most of your cloud, web, and private applications.

  • Customer Support

    Proactive support and engagement to optimize your Netskope environment and accelerate your success.

  • Training and Certification

    Netskope training will help you become a cloud security expert.

Trust Netskope to help you address evolving threats, new risks, technology shifts, organizational and network changes, and new regulatory requirements.

Learn more
Woman smiling with glasses looking out window

We have qualified engineers worldwide, with diverse backgrounds in cloud security, networking, virtualization, content delivery, and software development, ready to give you timely, high-quality technical assistance.

Learn more
Bearded man wearing headset working on computer

Secure your digital transformation journey and make the most of your cloud, web, and private applications with Netskope training.

Learn more
Group of young professionals working
  • Resources

    Learn more about how Netskope can help you secure your journey to the cloud.

  • Blog

    Learn how Netskope enables security and networking transformation through security service edge (SSE).

  • Events & Workshops

    Stay ahead of the latest security trends and connect with your peers.

  • Security Defined

    Everything you need to know in our cybersecurity encyclopedia.

Security Visionaries Podcast

Bonus Episode: The Importance of Security Service Edge (SSE)

Play the podcast
Black man sitting in conference meeting

Read the latest on how Netskope can enable the Zero Trust and SASE journey through security service edge (SSE) capabilities.

Read the blog
Sunrise and cloudy sky

Netskope CSO speaking events

Meet the Netskope CSO team at one of our upcoming events.

Find an event
Netskope CSO Team

What is Security Service Edge?

Explore the security side of SASE, the future of network and protection in the cloud.

Learn more
Four-way roundabout
  • Company

    We help you stay ahead of cloud, data, and network security challenges.

  • Why Netskope

    Cloud transformation and work from anywhere have changed how security needs to work.

  • Leadership

    Our leadership team is fiercely committed to doing everything it takes to make our customers successful.

  • Partners

    We partner with security leaders to help you secure your journey to the cloud.

Netskope enables the future of work.

Find out more
Curvy road through wooded area

Netskope is redefining cloud, data, and network security to help organizations apply Zero Trust principles to protect data.

Learn more
Switchback road atop a cliffside

Thinkers, builders, dreamers, innovators. Together, we deliver cutting-edge cloud security solutions to help our customers protect their data and people.

Meet our team
Group of hikers scaling a snowy mountain

Netskope’s partner-centric go-to-market strategy enables our partners to maximize their growth and profitability while transforming enterprise security.

Learn more
Group of diverse young professionals smiling
Blog Threat Labs GCP OAuth Token Hijacking in Google Cloud – Part 1
Aug 07 2020

GCP OAuth Token Hijacking in Google Cloud – Part 1

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):

  1. 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.
  1. 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.
  1. 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.

Let’s switch to the other machine my-attack-host-12345.com and check if the copied credentials work with gcloud.

It worked. So, all context/credentials have been transferred over to another machine by simply copying over all files in ~/.config/gcloud. Bucket access via gsutil also works on the attacker’s machine. The cached OAuth tokens are still valid. No reauthentication or MFA prompt is required from the new host.

Token Hijacking for API Calls

We just showed how we can easily copy the cached credentials en masse and access the user’s GCP environments. We can also pull out the OAuth tokens from the cache and use them directly to execute API calls instead of the CLI.

Let’s look back at the sqlite database files in ~/.config/gcloud. The file, access_tokens.db, contains the current OAuth access token, while credentials.db contains the refresh token, the OAuth client id/secret, scopes, and other information.

As you can see, the files are unencrypted and are easy to query. OAuth access tokens normally expire in 3600 seconds, after which, the refresh token must be used to obtain another access token. The credential.id_token.exp field indicates when the initial OAuth token was set to expire:

Since the default token duration is one hour, we know that the production environment prod-mfa-hw.com was first accessed from this machine back on June 17 at 09:12:03am PDT. And more than a month later, these cached credentials (OAuth refresh and access tokens) have not expired, are still valid, and can be used by an attacker. In other words, the time window for accessing the production environment from this host has been open for many weeks/months.

The refresh token will continue to be valid except under certain conditions (e.g. expiration is set, tokens explicitly revoked, or max limits hit) — these scenarios will be discussed later in Part 2 of this blog series.

So, how do we make use of these OAuth tokens directly?

We take the client id, secret, and refresh token from credentials.db as shown in the above query, and then generate a new, valid access token with an API call (part of the OAuth flow):

The response from the API call is a new OAuth access token, which can be used in any API call. Let’s execute a bucket listing call on the production bucket.

Other Token Hijacking Risk Areas

Service Accounts

Since OAuth is used for all Google Cloud authentication, when you add a service account key file locally during gcloud account configuration, gcloud will obtain OAuth tokens and store the tokens in the local access_tokens.db and credentials.db cache.

On a client machine outside of the GCP environment, stealing OAuth tokens for service accounts may not seem useful since the service account key file is likely stored under the user’s account anyways , and is more general and valuable for an attacker to compromise–the key file allows permanent access/reauthentication as it contains the private key secret.

However, there is an advantage to stealing the OAuth tokens generated for service accounts. Depending upon the remediation step taken by the victim, service account OAuth tokens may not be revoked, thereby granting up to an additional hour of access/persistence for the attacker: 

  1. Deleting the API keys generated under the service account, will not revoke current OAuth session tokens, and the attacker can still execute the CLI/API calls until the token expires (up to one hour).
  2. Disabling the service account works and causes subsequent API calls using the OAuth token to fail. However, the token is not actually revoked, it still exists, so if the service account is re-enabled, the last OAuth access token will work again.
  3. Deleting the service account revokes the OAuth access token.

These remediation steps are discussed in more detail in Part 2.

Compute Instances

If an attacker gains shell access to compute instances and if the user has installed gcloud (Google Cloud SDK), then all of the above regarding token compromise applies. 
Service accounts and their associated OAuth tokens on compute instances are another common attack vector. Compute instances can run as a service account identity, and in order to make it easier and more secure for users to run their compute application code and perform CLI tasks as that service account, a metadata service is provided that fetches a valid OAuth access token.

This is useful as the service account credentials (a key file) are not normally stored on a compute instance–the metadata service was created to avoid storing key files locally. But as we can see, once access is gained to the compute instance, the metadata service is easily queried to obtain a valid OAuth token. The expiration time for the access token is still a max of one hour. After the access token expires, no refresh token is needed to obtain a new access token, one just requires the metadata service. The metadata service is run locally on the compute instance and must be queried locally.

Cloud Shell

A special compute instance use case is the Google Cloud shell, which provides access to a Google-managed compute environment that includes the Google Cloud SDK pre-installed. Google Cloud shell has recently had root compromises as well as backdoor vulnerabilities. Once access is obtained to a Cloud shell and the underlying compute instance, both the ~/.config/glcoud credential cache and the metadata service can be exploited to hijack OAuth tokens.

Conclusion

In this post, we discussed 3 scenarios for hijacking OAuth tokens directly for subsequent use in the gcloud/gsutil CLI or in REST API calls:

  • Bulk copy of the gcloud sqlite database files used by the CLIs
  • Reuse of the OAuth tokens stored in the sqlite database, for use in API calls
  • Stealing of the OAuth tokens returned from a compute instance’s metadata service for use in API calls

The scenarios rely upon several design or configuration aspects of OAuth tokens:

Accessibility

  • Open sqlite database holding cached credentials/tokens
  • OAuth tokens are cached and unencrypted, allowing easy access once the client endpoint has been exploited.
  • Ease of copying unencrypted cached tokens to another host for exploitation

Persistence

  • Tokens can have long or no expiration, allowing potentially long time windows for compromise.
  • The attacker can easily refresh tokens, allowing persistence.
  • Token refresh does not require MFA making it easy to maintain persistence, creating a false sense of security when MFA is enabled.

In our next blog post, OAuth Token Hijacking in Google Cloud (GCP), Part 2, we’ll look at the challenges in detecting, remediating, and preventing abuse from hijacked OAuth tokens.

author image
About the author
Jenko has 15+ years of experience in research, product management, and engineering in cloud security, AV/AS, routers/appliances, threat intel, Windows security, vulnerability scanning and compliance. At Netskope, he researches new cloud attacks.
Jenko has 15+ years of experience in research, product management, and engineering in cloud security, AV/AS, routers/appliances, threat intel, Windows security, vulnerability scanning and compliance. At Netskope, he researches new cloud attacks.