SASE Week 2023 オンデマンド! セッションを探索します

未来のプラットフォームはNetskopeです

インテリジェントセキュリティサービスエッジ(SSE)、クラウドアクセスセキュリティブローカー(CASB)、クラウドファイアウォール、セキュアウェブゲートウェイ(SWG)、およびZTNAのプライベートアクセスは、単一のソリューションにネイティブに組み込まれており、セキュアアクセスサービスエッジ(SASE)アーキテクチャへの道のりですべてのビジネスを支援します。

製品概要はこちら
Netskopeの動画
Next Gen SASE Branch はハイブリッドであり、接続、保護、自動化

Netskope Next Gen SASE Branchは、コンテキストアウェアSASEファブリック、ゼロトラストハイブリッドセキュリティ、 SkopeAI-Powered Cloud Orchestrator を統合クラウド製品に統合し、ボーダレスエンタープライズ向けに完全に近代化されたブランチエクスペリエンスを実現します。

Next Gen SASE Branchの詳細はこちら
People at the open space office
  • NewEdge

    NewEdgeは、世界最大かつ最高のパフォーマンスを誇るセキュリティプライベートクラウドです。

  • クラウドセキュリティプラットフォーム

    世界最大のセキュリティプライベートクラウドにおける可視性とリアルタイムデータおよび脅威保護

  • 技術パートナーと統合

    Netskopeは、エンタープライズテクノロジーの最強の企業と提携しています。

セキュアアクセスサービスエッジ(SASE)アーキテクチャの採用

Netskope NewEdgeは、世界最大かつ最高のパフォーマンスのセキュリティプライベートクラウドであり、比類のないサービスカバレッジ、パフォーマンス、および回復力を顧客に提供します。

NewEdgeの詳細
NewEdge
明日に向けたネットワーク

サポートするアプリケーションとユーザー向けに設計された、より高速で、より安全で、回復力のあるネットワークへの道を計画します。

ホワイトペーパーはこちら
明日に向けたネットワーク
Netskope Cloud Exchange

Netskope Cloud Exchange (CE) は、セキュリティポスチャに対する投資を活用するための強力な統合ツールを提供します。

Cloud Exchangeについて学ぶ
Netskopeの動画
最小の遅延と高い信頼性を備えた、市場をリードするクラウドセキュリティサービスに移行します。

NewEdgeの詳細
山腹のスイッチバックを通るライトアップされた高速道路
アプリケーションのアクセス制御、リアルタイムのユーザーコーチング、クラス最高のデータ保護により、生成型AIアプリケーションを安全に使用できるようにします。

生成AIの使用を保護する方法を学ぶ
ChatGPTと生成AIを安全に有効にする
SSEおよびSASE展開のためのゼロトラストソリューション

ゼロトラストについて学ぶ
大海原を走るボート
Netskopeは、クラウドサービス、アプリ、パブリッククラウドインフラストラクチャを採用するための安全でクラウドスマートかつ迅速な旅を可能にします。

業界別ソリューションについて学ぶ
崖沿いの風力タービン
  • リソース

    クラウドへ安全に移行する上でNetskopeがどのように役立つかについての詳細は、以下をご覧ください。

  • ブログ

    Netskopeがセキュリティサービスエッジ(SSE)を通じてセキュリティとネットワークの変革を可能にする方法を学びましょう。

  • イベント&ワークショップ

    最新のセキュリティトレンドを先取りし、仲間とつながりましょう。

  • 定義されたセキュリティ

    サイバーセキュリティ百科事典、知っておくべきすべてのこと

「セキュリティビジョナリー」ポッドキャスト

2024年の予測
ホストのEmily Wearmouthが、BCD Travelのシニアバイスプレジデント兼CISOであるSherron Burgess氏と、Netskopeのクラウド戦略およびイノベーション責任者であるShamla Naidoo氏と対談し、来年のホットなトピックについて語ります。

ポッドキャストを再生する
2024年の予測
最新のブログ

Netskopeがセキュリティサービスエッジ(SSE)機能を通じてゼロトラストとSASEの旅を可能にする方法。

ブログを読む
日の出と曇り空
SASE Week 2023年:SASEの旅が今始まります!

第4回 SASE Weekのリプレイセッション。

セッションの詳細
SASE Week 2023
セキュリティサービスエッジとは

SASEのセキュリティ面、ネットワークとクラウドでの保護の未来を探ります。

セキュリティサービスエッジの詳細
4方向ラウンドアバウト
私たちは、お客様が何にでも備えることができるように支援します

お客様を見る
窓の外を見て微笑むメガネをかけた女性
Netskopeの有能で経験豊富なプロフェッショナルサービスチームは、実装を成功させるための規範的なアプローチを提供します。

プロフェッショナルサービスについて学ぶ
Netskopeプロフェッショナルサービス
Netskopeコミュニティは、あなたとあなたのチームが製品とプラクティスからより多くの価値を引き出すのに役立ちます。

Netskopeコミュニティに移動
Netskope コミュニティ
Netskopeトレーニングで、デジタルトランスフォーメーションの旅を保護し、クラウド、ウェブ、プライベートアプリケーションを最大限に活用してください。

トレーニングと認定資格について学ぶ
働く若い専門家のグループ
  • 会社概要

    クラウド、データ、ネットワークセキュリティの課題に対して一歩先を行くサポートを提供

  • Netskopeが選ばれる理由

    クラウドの変革とどこからでも機能することで、セキュリティの機能方法が変わりました。

  • リーダーシップ

    Netskopeの経営陣はお客様を成功に導くために全力を尽くしています。

  • パートナー

    私たちはセキュリティリーダーと提携して、クラウドへの旅を保護します。

データセキュリティによる持続可能性のサポート

Netskope は、持続可能性における民間企業の役割についての認識を高めることを目的としたイニシアチブである「ビジョン2045」に参加できることを誇りに思っています。

詳しくはこちら
データセキュリティによる持続可能性のサポート
Highest in Execution. Furthest in Vision.

ネットスコープは2023年Gartner®社のセキュリティ・サービス・エッジ(SSE)のマジック・クアドラント™でリーダーの1社として評価されました。

レポートを読む
ネットスコープは2023年Gartner®社のセキュリティ・サービス・エッジ(SSE)のマジック・クアドラント™でリーダーの1社として評価されました。
思想家、建築家、夢想家、革新者。 一緒に、私たちはお客様がデータと人々を保護するのを助けるために最先端のクラウドセキュリティソリューションを提供します。

当社のチーム紹介
雪山を登るハイカーのグループ
Netskopeのパートナー中心の市場開拓戦略により、パートナーは企業のセキュリティを変革しながら、成長と収益性を最大化できます。

Netskope パートナーについて学ぶ
色々な若い専門家が集う笑顔のグループ

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 application (attacker)
  • Ability to easily move laterally to other API services and permissions

Some of the key differences between the device code flow and the more common authorization code grant flow that create opportunities for new attacks include:

Functional AreaAuthorization Code GrantDevice Authorization Grant
Authorization code or device codeReturned by authorization server via user redirect, dependencies on redirect mechanism/userDevice code generated upfront by application, attacker in control, no dependencies on redirect/user, no complications from inserting into OAuth handshake
Access tokensREST API call with authorization code. Client secret and registered application redirect URL typically required for application authentication.Polling model to directly retrieve OAuth access tokens. The attacker does not need server infrastructure. No dependencies on redirect/user. Weak authentication of device.
ConsentExplicit consent dialogs presented to users with scopes listed.Typically, no detailed consent dialogs are presented to the user. In some cases, a simple "approve login" message is shown. Scopes not listed.

Finally, we’ve covered some of the controls that can be implemented to assist in prevention, detection, and mitigation, namely:

  • Blocking of the common login or device code URLs
  • Policies that enforce IP allow lists or other device checks to ensure that only approved or expected applications and locations are allowed to participate in device code flows
  • Detecting suspicious events in the sign-in or OAuth application logs
  • Being clear on how to recover from compromised session tokens, especially when revoking session token access (Azure APIs to revoke OAuth session tokens and Google deletion of OAuth applications).

In future blogs, we’ll discuss attacks that exploit other OAuth authentication flows, more differences between OAuth vendor implementations, additional security controls, and open source tools we’ve released that can help you assess your exposure to some of these new phishing attacks.

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