Acelere a implantação do SASE com a série SASE Week Backstage. Explore as sessões

fechar
fechar
  • Por que Netskope divisa

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

  • Nossos clientes divisa

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

  • Nossos parceiros divisa

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

Um Líder em SSE.
E agora Líder em Single-Vendor SASE.

Descubra por que a Netskope estreou como líder no Quadrante Mágico™ do Gartner® para Single-Vendor SASE

Obtenha o Relatório
Destaques de clientes visionários

Leia como os clientes inovadores estão navegando com sucesso no cenário atual de mudanças na rede & segurança por meio da plataforma Netskope One.

Baixe o eBook
Destaques de clientes visionários
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
Grupo de diversos jovens profissionais sorrindo
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
Vista aérea de uma cidade
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
Rodovia iluminada através de ziguezagues na encosta da montanha
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
Passeio de barco em mar aberto
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 divisa

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

  • Blog divisa

    Saiba como a Netskope permite a transformação da segurança e da rede por meio do serviço de acesso seguro de borda (SASE)

  • Eventos e workshops divisa

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

  • Security Defined divisa

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

Podcast Security Visionaries

O futuro da segurança: mudança quântica, inteligência artificial e macropolítica
Emily Wearmouth e Max Havey conversam com o CEO da Netskope, Sanjay Beri, e o CTO Krishna Narayanaswamy sobre o futuro da segurança.

Reproduzir o podcast Navegue por todos os podcasts
O futuro da segurança: mudança quântica, inteligência artificial e macropolítica
Últimos blogs

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

Leia o Blog
Nascer do sol e céu nublado
SASE Week 2024 On-Demand

Aprenda a navegar pelos últimos avanços em SASE e confiança zero e explore como essas estruturas estão se adaptando para enfrentar os desafios de segurança cibernética e infraestrutura

Explorar sessões
SASE Week 2024
O que é SASE?

Saiba mais sobre a futura convergência de ferramentas de redes e segurança no modelo predominante e atual de negócios na nuvem.

Saiba mais sobre a SASE
  • Empresa divisa

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

  • Carreira divisa

    Join Netskope's 3,000+ amazing team members building the industry’s leading cloud-native security platform.

  • Customer Solutions divisa

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

  • Treinamento e credenciamentos divisa

    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
Ajude a moldar o futuro da segurança na nuvem

At Netskope, founders and leaders work shoulder-to-shoulder with their colleagues, even the most renowned experts check their egos at the door, and the best ideas win.

Faça parte da equipe
Vagas na Netskope
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
Grupo de jovens profissionais trabalhando

New Phishing Attacks Exploiting OAuth Authorization Flows (Part 3)

Aug 12 2021

This blog series expands upon a presentation given at DEF CON 29 on August 7, 2021.

In Part 1 of this series, we provided an overview of OAuth 2.0 and two of its authorization flows, the authorization code grant and the device authorization grant. In Part 2 of this series, we described how a phishing attack could be carried out by exploiting the device authorization grant flow.

Phishing attacks are starting to evolve from the old-school faking of login pages that harvest passwords to attacks that abuse widely-used identity systems such as Microsoft Azure Active Directory or Google Identity, both of which utilize the OAuth authorization protocol for granting permissions to third-party applications using your Microsoft or Google identity.

In the past few years, we have seen illicit grant attacks that use malicious OAuth applications created by attackers to trick a victim into granting the attacker wider permissions to the victim’s data or resources:

Instead of creating fake logins/websites, illicit grant attacks use the actual OAuth authentication/authorization flows in order to obtain the OAuth session tokens. This has the advantage of bypassing MFA authentication, with permanent or nearly indefinite access since the OAuth tokens can be continually refreshed in most cases.

In this blog series, we will review how various quirks in the implementation of different OAuth authorization flows can make it easier for attackers to phish victims due to:

  1. Attackers not needing to create infrastructure (e.g., no fake domains, websites, or applications), leading to easier and more hidden attacks
  2. An ability to easily reuse client ids of existing applications, obfuscating attacker actions in audit logs
  3. The use of default permissions (scopes), granting broad privileges to the attacker
  4. A lack of approval (consent) dialogs shown to the user
  5. An ability to obtain new access tokens with broader privileges and access, opening up lateral movement among services/APIs

Finally, we will discuss what users can do today to protect themselves from these potential new attacks.

In Part 3 of this blog series, we will describe what security controls can be put in place to defend against these new attacks.

Security Controls

It is a challenge dealing with attacks targeting OAuth authorization flows, because:

There are some controls that can be implemented to mitigate OAuth-related attacks, but each organization will need to evaluate the practicality and difficulty of implementation of the various controls.

  1. Prevention: Disallow device code flows. If at all possible, start with a policy that rules out all authorization using device code flows, as it will make detection and prevention controls easier. 

    The challenges will be enforcing this on unmanaged networks and devices such as remote workers at home or smartphone use. Additionally, some valid required tools use device code flows (discussed below in the Exceptions section). This may make this control difficult to achieve for many organizations, but should still be the starting point in your security plan.
  1. Prevention: Restrict application consent. Administrators can restrict whether or how users consent to applications. For example, normal users can be prevented from consenting to any applications. 

    This helps with illicit grant attacks but if a device code phish uses an existing application like Outlook that needs to be allowed, this is of limited use. Additionally, it may be burdensome and non-scaleable for administrators to approve all applications or it may be too restrictive to prevent users from approving any applications, in which case, explore which of the several options regarding user approvals fit your policies best.
  1. Prevention: Block URLs: The first approach to blocking new phishing attacks using device code flows will be to block as early as possible relevant URLs being used, which includes 
    1. Device Code Login URLs that would be sent to the user include the following:
      1. https://www.microsoft.com/devicelogin
      2. https://login.microsoftonline.com/common/oauth2/deviceauth
      3. https://www.google.com/device
      4. https://accounts.google.com/o/oauth2/device/usercode

        Notes:
        1. There are two per vendor as they both employ a URL redirect from a short, convenient URL to the official device login URL. 
        2. Numerous application protocols are used for phishing, so as many as possible should be covered, starting with SMTP (email). Corporate chat apps may be difficult to check inline, but detection/remediation can be done with authorized apps performing out-of-band checks on messages after they are posted.
    2. Device Code Generation URLs: To minimize malicious insiders generating phishing attacks using device code flows, one can also block the endpoints used to generate device and user codes:
      1. https://login.microsoftonline.com/common/oauth2/devicecode
      2. https://oauth2.googleapis.com/device/code
    3. Full path URL matching is required since the domains are official vendor domains. GET query parameters or POST parameters do not need to be checked. Detection and blocking/alerting on the above URLs can be effective. 

      The challenges are:
      1. Phishes that are delivered over unmanaged channels (applications) such as mobile apps
      2. Exception apps (detailed below)
      3. Phishes that use the more common authorization code grant, since that flow is common and would be harder to block without losing critical user functionality. This includes illicit grant phishes.
  1. Prevention: Exceptions: Any critical applications that must use device code flows need to be considered:
    1. SmartTV
      If conference room or other office devices are allowed to connect to content such as video streaming, then the flows must be allowed. In this case, look at implementing very specific IP allow lists so that only a few devices with well-known IPs are allowed to initiate or respond to device flow authorizations.
    2. Common applications that support device code flows e.g. Azure CLI.
      The Azure CLI supports the more common authorization code grant flow as well as the device code flow when a local browser cannot be launched. If the latter case is common, then you will need to allow device code flows. This could make it much harder to set up IP allow lists, as the potential number of IPs may be larger and more dynamic than the SmartTV case.
  1. Detection: Since OAuth access tokens are often the common authorization method used by many REST APIs, any actions are typically logged as the user’s actions if supported by the application e.g. API calls can be logged in Azure logging or GCP Stackdriver logging. 

    However, other OAuth actions are not typically logged, such as refresh tokens being used to refresh a new access token. And authorization flows are usually not logged in any detail. Here is an entry from the Azure sign-in logs for the victim of the phish:



    The IP address of where the attacker script is run is available, but the lateral movement to get a new access token for Azure is not logged. This limited logging poses a challenge to identify the attacker techniques described in this blog.

    However, here are some controls that can provide more visibility on suspicious activity:
    1. Use conditional access policies to enforce IP allow lists or allow only authorized devices
    2. Monitor Azure logs for any attempted API calls that fail due to the conditional access policies
    3. Monitor Azure sign-in audit logs for suspicious activity, such as IP addresses that do not match the IP allow lists
    4. Leading behavioral detection and analytics (UEBA) solutions should be evaluated and used. Typically machine-learning based, these approaches are important to detecting anomalous or suspicious activity.
  1. Mitigation: If compromised tokens are suspected, it may be unclear whether they were hijacked directly or if obtained because the primary credentials (username and password) were compromised. The safest remediation procedures should include:
    1. Restoring the compromised environment to a known, clean state (possibly restore from known backup to ensure no backdoors)
    2. Changing of primary credentials to prevent future access and abuse
    3. Revoking of all current session tokens (both access and refresh tokens) to ensure current access by the attacker is revoked.
      1. In Azure, refresh tokens can be invalidated with the Powershell cmdlet: Revoke-AzureADUserAllRefreshToken, but there is no current way to revoke access tokens.
      2. In Google, deleting the OAuth connected application from Google Workspace will delete all access and refresh tokens for that application: Users > user > Security > Connected applications:
Screenshot showing how to delete OAuth connected applications from Google Workspace.

Conclusion

OAuth 2.0 has brought a lot of benefits in terms of secure authentication and authorization among Internet-enabled applications/devices and end-users. However, as is the case with most protocols, there is a level of complexity that can also open the door to abuse by attackers.

With OAuth, some of the complexity derives from the number and richness of the protocol and the number of different use cases.

We’ve shown and discussed how the device code grant flow and one implementation of it allows attackers to more easily phish victims, taking advantage of several aspects:

  • Reuse of existing application client ids to provide more obfuscation of attacker actions
  • Weak application authentication allowing easy reuse of existing applications
  • Default scopes/permissions that grant wider initial privileges to the attacker
  • Lack of consent dialogs for end users, making it confusing about what permissions have been granted to the applica