New Phishing Attacks Exploiting OAuth Authorization Flows (Part 3)

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:

• Phishing Attack Hijacks Office 365 Accounts Using OAuth Apps, Lawrence Abrams, 12/10/2019.
• DEMONSTRATION – ILLICIT CONSENT GRANT ATTACK IN AZURE AD / OFFICE 365, Joosua Santasalo, 10/25/2018

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:

• The OAuth protocol and authorization flows are complex and can be confusing
• Attacker techniques targeting OAuth itself are relatively new
• Once OAuth session tokens are hijacked, it is often difficult to detect and remediate due to factors described in previous blogs:
  • GCP OAuth Token Hijacking in Google Cloud – Part 1
  • GCP OAuth Token Hijacking in Google Cloud – Part 2

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.

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

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