¡El futuro de Zero Trust y de SASE es ahora! Regístrese ahora

cerrar
cerrar
  • Servicio de seguridad Productos Edge chevron

    Protéjase contra las amenazas avanzadas y en la nube y salvaguarde los datos en todos los vectores.

  • Borderless SD-WAN chevron

    Proporcione con confianza un acceso seguro y de alto rendimiento a cada usuario remoto, dispositivo, sitio y nube.

  • Secure Access Service Edge chevron

    Netskope SASE proporciona una solución SASE nativa en la nube, totalmente convergente y de un único proveedor.

La plataforma del futuro es Netskope

Intelligent Security Service Edge (SSE), Cloud Access Security Broker (CASB), Cloud Firewall, Next Generation Secure Web Gateway (SWG) y Private Access for ZTNA integrados de forma nativa en una única solución para ayudar a todas las empresas en su camino hacia el Servicio de acceso seguro Arquitectura perimetral (SASE).

Todos los productos
Vídeo de Netskope
Next Gen SASE Branch es híbrida: conectada, segura y automatizada

Netskope Next Gen SASE Branch converge Context-Aware SASE Fabric, Zero-Trust Hybrid Security y SkopeAI-Powered Cloud Orchestrator en una oferta de nube unificada, marcando el comienzo de una experiencia de sucursal completamente modernizada para la empresa sin fronteras.

Obtenga más información sobre Next Gen SASE Branch
Personas en la oficina de espacios abiertos.
Diseño de una arquitectura SASE para Dummies

Obtenga un ejemplar gratuito del único manual que necesitará sobre diseño de una arquitectura SASE.

Obtenga el eBook
Adopte una arquitectura de borde de servicio de acceso seguro (SASE)

Netskope NewEdge es la nube privada de seguridad más grande y de mayor rendimiento del mundo y ofrece a los clientes una cobertura de servicio, un rendimiento y una resiliencia incomparables.

Más información sobre NewEdge
NewEdge
Tu red del mañana

Planifique su camino hacia una red más rápida, más segura y más resistente diseñada para las aplicaciones y los usuarios a los que da soporte.

Obtenga el whitepaper
Tu red del mañana
Netskope Cloud Exchange

Cloud Exchange (CE) de Netskope ofrece a sus clientes herramientas de integración eficaces para que saquen partido a su inversión en estrategias de seguridad.

Más información sobre Cloud Exchange
Vídeo de Netskope
Cambie a los servicios de seguridad en la nube líderes del mercado con una latencia mínima y una alta fiabilidad.

Más información sobre NewEdge
Lighted highway through mountainside switchbacks
Habilite de forma segura el uso de aplicaciones de IA generativa con control de acceso a aplicaciones, capacitación de usuarios en tiempo real y la mejor protección de datos de su clase.

Descubra cómo aseguramos el uso generativo de IA
Habilite de forma segura ChatGPT y IA generativa
Soluciones de confianza cero para implementaciones de SSE y SASE

Más información sobre Confianza Cero
Boat driving through open sea
Netskope logra la alta autorización FedRAMP

Elija Netskope GovCloud para acelerar la transformación de su agencia.

Más información sobre Netskope GovCloud
Netskope GovCloud
  • Recursos chevron

    Obtenga más información sobre cómo Netskope puede ayudarle a proteger su viaje hacia la nube.

  • Blog chevron

    Descubra cómo Netskope permite la transformación de la seguridad y las redes a través del servicio de seguridad (SSE).

  • Eventos & Workshops chevron

    Manténgase a la vanguardia de las últimas tendencias de seguridad y conéctese con sus pares.

  • Seguridad definida chevron

    Todo lo que necesitas saber en nuestra enciclopedia de ciberseguridad.

Podcast Security Visionaries

Galletas, no bizcochos
La anfitriona Emily Wearmouthas se sienta con los expertos David Fairman y Zohar Hod para discutir el pasado, el presente y el futuro de las cookies de Internet.

Reproducir el pódcast
Podcast: Galletas, no galletas
Últimos blogs

Cómo Netskope puede habilitar el viaje de Zero Trust y SASE a través de las capacidades del borde del servicio de seguridad (SSE).

Lea el blog
Sunrise and cloudy sky
SASE Week 2023: ¡Su viaje SASE comienza ahora!

Sesiones de repetición de la cuarta SASE Week.

Explorar sesiones
SASE Week 2023
¿Qué es Security Service Edge (SSE)?

Explore el lado de la seguridad de SASE, el futuro de la red y la protección en la nube.

Más información sobre el servicio de seguridad perimetral
Four-way roundabout
Ayudamos a nuestros clientes a estar preparados para cualquier situación

Ver nuestros clientes
Woman smiling with glasses looking out window
El talentoso y experimentado equipo de servicios profesionales de Netskope proporciona un enfoque prescriptivo para su exitosa implementación.

Más información sobre servicios profesionales
Servicios profesionales de Netskope
La comunidad de Netskope puede ayudarlo a usted y a su equipo a obtener más valor de los productos y las prácticas.

Acceder a la Netskope Community
La comunidad de Netskope
Asegure su viaje de transformación digital y aproveche al máximo sus aplicaciones en la nube, web y privadas con la capacitación de Netskope.

Infórmese sobre Capacitaciones y Certificaciones
Group of young professionals working
  • Empresa chevron

    Le ayudamos a mantenerse a la vanguardia de los desafíos de seguridad de la nube, los datos y la red.

  • Por qué Netskope chevron

    La transformación de la nube y el trabajo desde cualquier lugar han cambiado la forma en que debe funcionar la seguridad.

  • Liderazgo chevron

    Nuestro equipo de liderazgo está firmemente comprometido a hacer todo lo necesario para que nuestros clientes tengan éxito.

  • Partners chevron

    Nos asociamos con líderes en seguridad para ayudarlo a asegurar su viaje a la nube.

Apoyar la sostenibilidad a través de la seguridad de los datos

Netskope se enorgullece de participar en Vision 2045: una iniciativa destinada a crear conciencia sobre el papel de la industria privada en la sostenibilidad.

Descubra más
Apoyando la sustentabilidad a través de la seguridad de los datos
La más Alta en Ejecución. Más Avanzada en Visión.

Netskope ha sido reconocido como Líder en el Gartner® Magic Quadrant™ de 2023 en SSE.

Obtenga el informe
Netskope ha sido reconocido como Líder en el Gartner® Magic Quadrant™ de 2023 en SSE.
Pensadores, constructores, soñadores, innovadores. Juntos, ofrecemos soluciones de seguridad en la nube de vanguardia para ayudar a nuestros clientes a proteger sus datos y usuarios.

Conozca a nuestro equipo
Group of hikers scaling a snowy mountain
La estrategia de venta centrada en el partner de Netskope permite a nuestros canales maximizar su expansión y rentabilidad y, al mismo tiempo, transformar la seguridad de su empresa.

Más información sobre los socios de Netskope
Group of diverse young professionals smiling

GCP OAuth Token Hijacking in Google Cloud – Part 1

Aug 07 2020

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.

Calcular instancias

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.

Conclusión

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
Jenko Hwong
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.

Stay informed!

Subscribe for the latest from the Netskope Blog