Netskope é nomeada líder no Quadrante Mágico do Gartner® de 2024 para Security Service Edge. Obtenha o Relatório

fechar
fechar
  • Por que Netskope chevron

    Mudando a forma como a rede e a segurança trabalham juntas.

  • Nossos clientes chevron

    A Netskope atende a mais de 3.000 clientes em todo o mundo, incluindo mais de 25 das empresas da Fortune 100

  • Nossos parceiros chevron

    Fazemos parceria com líderes de segurança para ajudá-lo a proteger sua jornada para a nuvem.

Ainda mais alto em execução.
Ainda mais longe na visão.

Saiba por que o 2024 Gartner® Magic Quadrant™ nomeou a Netskope como líder em Security Service Edge pelo terceiro ano consecutivo.

Obtenha o Relatório
A Netskope foi nomeada líder no Quadrante Mágico do Gartner de 2024®™ para o gráfico Security Service Edge para menu
Ajudamos nossos clientes a estarem prontos para tudo

Veja nossos clientes
Woman smiling with glasses looking out window
A estratégia de comercialização da Netskope, focada em Parcerias, permite que nossos Parceiros maximizem seu crescimento e lucratividade enquanto transformam a segurança corporativa.

Saiba mais sobre os parceiros da Netskope
Group of diverse young professionals smiling
Sua Rede do Amanhã

Planeje seu caminho rumo a uma rede mais rápida, segura e resiliente projetada para os aplicativos e usuários aos quais você oferece suporte.

Receba o whitepaper
Sua Rede do Amanhã
Apresentando a plataforma Netskope One

O Netskope One é uma plataforma nativa da nuvem que oferece serviços convergentes de segurança e rede para permitir sua transformação SASE e zero trust.

Saiba mais sobre o Netskope One
Abstrato com iluminação azul
Adote uma arquitetura Secure Access Service Edge (SASE)

O Netskope NewEdge é a maior nuvem privada de segurança de alto desempenho do mundo e oferece aos clientes cobertura de serviço, desempenho e resiliência inigualáveis.

Conheça a NewEdge
NewEdge
Netskope Cloud Exchange

O Cloud Exchange (CE) da Netskope oferece aos clientes ferramentas de integração poderosas para tirar proveito dos investimentos em estratégias de segurança.

Saiba mais sobre o Cloud Exchange
Vídeo da Netskope
A plataforma do futuro é a Netskope

Intelligent Security Service Edge (SSE), Cloud Access Security Broker (CASB), Cloud Firewall, Next Generation Secure Web Gateway (SWG) e Private Access for ZTNA integrados nativamente em uma única solução para ajudar todas as empresas em sua jornada para o Secure Access Service Arquitetura de borda (SASE).

Vá para a plataforma
Vídeo da Netskope
Next Gen SASE Branch é híbrida — conectada, segura e automatizada

Netskope Next Gen SASE Branch converge o Context-Aware SASE Fabric, Zero-Trust Hybrid Security e SkopeAI-Powered Cloud Orchestrator em uma oferta de nuvem unificada, inaugurando uma experiência de filial totalmente modernizada para empresas sem fronteiras.

Saiba mais sobre Next Gen SASE Branch
Pessoas no escritório de espaço aberto
Desenvolvendo uma Arquitetura SASE para Leigos

Obtenha sua cópia gratuita do único guia de planejamento SASE que você realmente precisará.

Baixe o eBook
Mude para serviços de segurança na nuvem líderes de mercado com latência mínima e alta confiabilidade.

Conheça a NewEdge
Lighted highway through mountainside switchbacks
Permita com segurança o uso de aplicativos generativos de IA com controle de acesso a aplicativos, treinamento de usuários em tempo real e a melhor proteção de dados da categoria.

Saiba como protegemos o uso de IA generativa
Ative com segurança o ChatGPT e a IA generativa
Soluções de zero trust para a implementação de SSE e SASE

Conheça o Zero Trust
Boat driving through open sea
Netskope obtém alta autorização do FedRAMP

Escolha o Netskope GovCloud para acelerar a transformação de sua agência.

Saiba mais sobre o Netskope GovCloud
Netskope GovCloud
  • Recursos chevron

    Saiba mais sobre como a Netskope pode ajudá-lo a proteger sua jornada para a nuvem.

  • Blog chevron

    Saiba como a Netskope permite a transformação da segurança e da rede por meio do SSE (Security Service Edge)

  • Eventos e workshops chevron

    Esteja atualizado sobre as últimas tendências de segurança e conecte-se com seus pares.

  • Security Defined chevron

    Tudo o que você precisa saber em nossa enciclopédia de segurança cibernética.

Podcast Security Visionaries

On Patents, Trolls, and Innovation
In this episode host Emily Wearmouth chats with Suzanne Oliver, an intellectual property expert, and Krishna Narayanaswamy, co-founder and CTO of Netskope, about the world of patents.

Reproduzir o podcast
On Patents, Trolls, and Innovation
Últimos blogs

Leia como a Netskope pode viabilizar a jornada Zero Trust e SASE por meio de recursos de borda de serviço de segurança (SSE).

Leia o Blog
Sunrise and cloudy sky
SASE Week 2023: Sua jornada SASE começa agora!

Replay das sessões da quarta SASE Week anual.

Explorar sessões
SASE Week 2023
O que é o Security Service Edge?

Explore o lado de segurança de SASE, o futuro da rede e proteção na nuvem.

Saiba mais sobre o Security Service Edge
Four-way roundabout
  • Empresa chevron

    Ajudamos você a antecipar os desafios da nuvem, dos dados e da segurança da rede.

  • Liderança chevron

    Nossa equipe de liderança está fortemente comprometida em fazer tudo o que for preciso para tornar nossos clientes bem-sucedidos.

  • Customer Solutions chevron

    Estamos aqui junto com você a cada passo da sua trajetória, assegurando seu sucesso com a Netskope.

  • Treinamento e certificação chevron

    Os treinamentos da Netskope vão ajudar você a ser um especialista em segurança na nuvem.

Apoiando a sustentabilidade por meio da segurança de dados

A Netskope tem o orgulho de participar da Visão 2045: uma iniciativa destinada a aumentar a conscientização sobre o papel da indústria privada na sustentabilidade.

Saiba mais
Apoiando a sustentabilidade por meio da segurança de dados
Pensadores, construtores, sonhadores, inovadores. Juntos, fornecemos soluções de segurança na nuvem de última geração para ajudar nossos clientes a proteger seus dados e seu pessoal.

Conheça nossa equipe
Group of hikers scaling a snowy mountain
A talentosa e experiente equipe de Serviços Profissionais da Netskope fornece uma abordagem prescritiva para sua implementação bem sucedida.

Conheça os Serviços Profissionais
Netskope Professional Services
Proteja sua jornada de transformação digital e aproveite ao máximo seus aplicativos de nuvem, web e privados com o treinamento da Netskope.

Saiba mais sobre Treinamentos e Certificações
Group of young professionals working

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.

Instâncias de computação

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.

Conclusão

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