Part 2: How Attackers Exploit OAuth: A Deep Dive

Originally published by Astrix.

Written by Michael Silva, Danielle Guetta, and Tal Skverer.

“Identity is the new perimeter.” This catch phrase is present in almost every website of identity security vendors, and for a good reason. Human access, more commonly referred to as user access, is an established security program in most organizations – big or small. The realization that user identities and login credentials need to be vigorously protected with IAM policies and security tools like MFA or IP restrictions or via SSO happened long ago. However, when it comes to non-human access like API keys, OAuth tokens, service accounts, secrets and other programmable access credentials, the situation is very different. Lack of visibility, monitoring and governance to this permissive access is everywhere, and attackers have figured it out.

In this guide, we will deep dive into the non-human identities attack surface, how it’s created, how attackers exploit it, and what steps you can take to minimize your exposure now.

Part 1 recap

In the first installment of this series, we covered the non-human access problem space, and the drivers that make it such a prevalent security gap. The topic of consent fatigue, and how employees will connect anything without really understanding the permissions they grant tools and services to sensitive systems and data, is one of the main drivers of the non-human access issue. Permission scopes and lack of offboarding of machine credentials make non-human access the path of least resistance for hackers looking to gain initial access, and then escalate privileges and even move laterally inside the organization. Lastly, we lightly touched on how one of the most commonly used authorization methods of non-human access works – the OAuth framework.

This brings us to this installment, where we will dive even deeper into how the OAuth framework works, the inherent upsides and downsides of OAuth as a non-human access credential, and what makes it so lucrative for attackers to try and exploit. This will help us better understand how attackers think, what they like to exploit, and consequently how to protect our environments from potential breaches. Let’s get started, shall we?

Behind the scenes of the OAuth process

In part 1, we detailed at a high level the sequence of the OAuth process. Now, let’s explore the actual events that occur behind the scenes when an end user undergoes the authorization process of a new tool that uses OAuth.

Referring to the flow in the image above we will use a fictional scenario in which our sales team member, Bob ([email protected]) wants to use a new note aggregator tool called NoteNinja, and connect it to the company’s CRM platform – Forceful Sales.

The OAuth flow can be logically split into two parts: the first part revolves around consent, and includes steps 1 and 2: Bob is prompted by NoteNinja to authorize the application in Bob’s Forceful Sales instance. At this point, Forcesul Salesdisplays the consent screen, which contains the permissions the client application (NoteNinja) requests, and Bob then consents.

The second part involves the rest of the steps and is basically the access token handshake:
Forceful Sales generates a one-time authorization code, and gives it to Bob who then passes it back to the application in step 3. This is where the application and the server communicate directly: NoteNinja uses the authorization code to request a token from the Forceful Sales server on step 4. Then, the flow is completed in step 5 when NoteNinja receives an access token which is used to access Bob’s data.

Scopes, privileges and other hidden layers in OAuth

Some parts of the above described flow are a little hidden still, like what are the actual permissions (called scopes) that have been requested, and what exactly we just allowed the client application developer to do. Although Bob was prompted with a common language breakdown of what he was giving access for (and sometimes why it’s needed) during the consent screen stage, what Bob doesn’t see is the exact scope of privilege being given. For example, the NoteNinja scope talks about giving authorization to read notes, list opportunities and write summary updates. However, the exact scope of access granted may include additional access needed to make NoteNinja work, that are not explicitly called out to Bob.

<code><mark>{
    "access_token": "<access_token>",
    "expires_in": null,
    "refresh_token": "<refresh_token>",</mark>
    "scope": "opportunities notes api history accounts user_profile_data",
<mark>    "user_id": "<[email protected]>"
}</mark></code>

Above is the actual scope breakdown that was granted to NoteNinja. There are a few items to take note of; firstly, the client application has been provided with a refresh token, but its expiration is “null”. This can happen for several reasons, one may be a setting in the Forceful Sales application that hands out refresh tokens without an expiry – a configuration issue that should be investigated. Secondly, the scope requested by NoteNinja was for read/write access, while a simple read would have been sufficient for items like accounts and opportunities. This practice is a common thing in OAuth scopes, which happens for a variety of reasons, such as a limitation of the platform not providing granular-enough scopes, the developer of the app not wanting to limit themselves if they decide to expand their offering in the future, to test new capabilities without asking for a new authorization, or possibly for a nefarious reason.

This brings us to the second misunderstanding – what can the client application (NoteNinja in our case) do with this token? How much trust did Bob just put into a relatively unknown entity that has not been vetted by his security team? Once the access token has been provided, it’s up to the client application developer to handle the token, save it and safeguard it. Additionally, it’s important to understand that the application developer or company can use the access token anytime, as they wish, not just when it is invoked by the client application’s normal process.

Attackers ♥️ non-human access credentials

The last paragraph is crucial to remember when granting access to external entities. Since non-human access, such as token-based OAuth connections, are not bound by all the amazing security advancements given to our oft-targeted user identities—like RSA tokens, Multi-Factor Authentication (MFA), IP and behavior-based restrictions, etc.—they can be used by all of those who possess the token and have access to the corresponding API.

This means that not only do you have to worry about the third party entities themselves taking advantage of their access to your core environments, but also put your trust in them to properly safeguard your tokens. This ties into the challenge of consent screen fatigue, and underscores the importance of end-users having a thorough understanding of the vendor behind the tool they are trying to integrate with, so they can make informed decisions.

Vendor breaches are on the rise and it’s because of their connections and access to customer data. Threat actors are well aware that the way into the crown jewels of businesses (customer info, source code and financial data to name a few), is way easier through previously consented third party connections than trying to break in the front door of each company. The topic of vendor breaches will be covered in depth in Part 3 of this series.

How attackers exploit OAuth & best practices for staying ahead

With a simple Google search, you will find plenty of different types of OAuth based attacks. These happen due to commonly known vulnerabilities in OAuth functions, as well as common mishandlings – such as improper handling of state parameters, reusability of an OAuth access token to flawed scope validation, and others.

Similar to CVEs disclosed for your Windows and Linux distributions, there are shared vulnerabilities within OAuth implementations that malicious actors are acquainted with and know how to exploit. These vulnerabilities can be used in conjunction with the grants given to applications.

Let’s use the scope from the example of NoteNinja’s access to our fictional CRM, Forceful Sales:

<code><mark>{
    "access_token": "<access_token>",
    "expires_in": null,
    "refresh_token": "<refresh_token>",</mark>
    "scope": "opportunities notes api history accounts user_profile_data",
 <mark>   "user_id": "<[email protected]>"
}</mark></code>

Once the attacker was able to compromise NoteNinja’s organization via phishing, ransomware or brute force, and gained access to the backend of their client application, they now essentially have full access to the scopes in question for all customers, including Bob’s. With the granted scopes, the attackers could download a full customer inventory, modify and/or delete records, etc. Causing scenarios such as data leakage, for both Bob’s organization and his clients, or corruption of source of truth data – all because Bob wanted to make aggregating his notes a little bit easier.

Since completely blocking employees from connecting productivity tools to the enterprise environment badly damages business agility, security teams should opt in to other initiatives that will allow them to monitor non-human access in a way that empowers the business side of things. This includes processes such as assessing OAuth vendors and their reputations, to discern the entities or individual developers we grant access to. Achieving comprehensive visibility into the connections linking core environments like Salesforce, GitHub, Office 365 and AWS with third-party vendors is crucial. Additionally, it is important to evaluate how vendors interact with our environment—identifying normal behavior, recognizing anomalies, and ensuring that their scopes align appropriately with their intended purpose.

OAuth is not alone in the non-human access attack surface

Even though the focus of this part of the series is OAuth, it is just a piece of the non-human identity space. Unlike OAuth, where most non-human connections are tied to a user account, and consequently with the deletion of the user account most will be automatically terminated or become void, there are other machine credentials that are not so easy to expunge from an environment. These include Personal Access Tokens, API keys, SSH keys etc.

Cases of “floating token” or “rogue token” happen in other types of integrations, such as SSH or deploy keys, that stay “alive” even after the user is offboarded. While the OAuth connections that are associated with Bob will be removed once he is terminated or moves on to his next career endeavor, some connections he has will not get offboarded with him. This can create headaches for security teams who may not control the disparate applications that are acting as authorization holders for third party vendors. For instance, collaboration, business intelligence or even finance applications that allow for APIs, webhooks, bot tokens, etc. may fly under the radar and only become exposed during a forensic search in the wake of a breach – too little, too late.

Lastly, highlighting the fact that OAuth is implementation-specific, the Zero-Day vulnerability Astrix’s research team found in Google Cloud Platform – Ghost Token, shows that sometimes even OAuth isn’t doing what it’s supposed to, and its tokens may not be automatically terminated either.

Coming next: Deep dives

In the next parts of this series we will dive even deeper into how non-human access credentials work and how to protect yourself from supply chain attacks.