Under the radar: The risky terrain of OAuth scopes in third-party Integrations

While OAuth scopes are instrumental in providing seamless online user authentication, they also carry significant risk in terms of security breaches. This risk magnifies when exposed to malicious actors, who can exploit certain high-risk scopes such as Microsoft 365’s “MailboxSettings.ReadWrite”, and Google Workspace’s “gmail.settings.sharing” to carry out nefarious actions.

This article includes the most common high-risk scopes that may pose risk to your organization following the compromise of a third-party integration. Watch out for these common, dangerous scopes in your next risk assessment.

Capability: Backdoor Mailbox

Types of attacks: Business email compromise, account takeover via password reset email

Scopes that allow you to alter sensitive mailbox settings, such as forwarding rules, can allow malicious actors to take over a user’s mailbox by moving, deleting, or forwarding mail externally. This type of attack is typically prevalent in business email compromise (BEC) scenarios where malicious actors intercepts sensitive communications, leading to invoice fraud as an example.

The malicious actor would also be able to forward password reset email requests and delete the email from the victim’s inbox to avoid detection, thereby gaining the ability to reset credentials and gain access to third-party SaaS applications while remaining undetected.

Capability: Account Takeover, Privilege Escalation

Types of attacks: account takeover via password reset, privilege escalation via group membership change

The above scopes are typically used by applications that perform identity management within your cloud environment. “Directory.ReadWrite.All” for example, allows you to read and modify practically any aspect of objects within your directory. This includes group membership, password resets, and re-enabling previously disabled accounts.

“User.ReadWrite.All” has similar privileges, albeit limited in scope to user accounts only. An attacker in a position to abuse such scopes would be able to take over accounts, escalate privileges by assigning the accounts to privileged groups, and remain under the radar by making use of previously disabled accounts.

Capability: Email Access

Types of attacks: Business email compromise, account takeover via password reset email

Scopes that have direct access to mailboxes naturally provide risk in terms of a malicious actor’s ability to read sensitive information, and access to third-party SaaS applications’ password reset email requests, not unlike the ‘Backdoor Mailbox’ capability.

Capability: Access as User

Types of attacks: Gain access to resources available to the particular account

Scopes that provide “Access as User” privileges are typically used by applications that need to impersonate a user and their access permissions. This may not sound super risky at the surface level, but if you consider that a user may have access to shared resources across an organization, the risk starts to add up.

One example of the impact of such scopes is noted in Chris Moberly's incredibly informative blog post where the “https://www.googleapis.com/auth/cloud-platform” scope is abused to authenticate to practically all API functions within Google Cloud, and in turn access the owner’s data.

Capability: OneDrive / SharePoint /  Google Drive File Access

Types of attacks: Gain access to all files stored within the OneDrive/SharePoint or Google Drive services

OneDrive, SharePoint, and Google Drive are likely the services where some of the most sensitive content in your organization resides. Scopes that provide access to document stores should thus be treated as having access to critical information (think PII, trade secrets, acquisition deals).

Document theft would be possible with the read-only scopes. However, a malicious actor with ‘write’ permissions would be able to expand into another level of attacks which involves manipulating the content of documents. This could include altering banking details on invoices, or the inclusion of malicious code in macros embedded in the documents, leading to code execution and further compromise.

Capability: Privilege Escalation, Persistence

Types of attacks: Adding credentials, backdooring applications

The "Application.ReadWrite.All" scope could enable a malicious actor to add credentials to applications already present in your tenant, paving the way for privilege escalation.As an example, if a malicious actor compromises an application with this scope, they could add credentials to any other application in your tenant that has the "Directory.ReadWrite.All" scope, thereby gaining access to its data and privileges.

This naturally lends itself to a malicious actor gaining persistence via the addition of credentials to other applications. This would allow them to authenticate as these other applications within your Azure or Google tenants, and allow them to assume those applications’ privileges, too.

Capability: Teams chat history / OneNote access

Types of attacks: Gain access to users’ teams chat histories or OneNote notes

If a malicious actor were to gain access to your meeting notes or Teams chat histories, what would they find? Perhaps passwords shared between team members or confidential proprietary information? With the scopes designated with ‘All’, a malicious actor will be able to pull the Teams or notes history of all users within the organization.

I found an integration we use that includes these dangerous scopes… now what?

While the scopes listed here are definitely some of the most dangerous when granted to third-party integrations, they will usually be paired with legitimate apps offering legitimate functionality. But then how do you determine which integrations need further scrutiny?

The biggest red flag you might come across would be an unrecognized or unapproved integration making use of these scopes, as it may be associated with attacks such as consent phishing. 

Determining their legitimacy should be the number one priority. This would hopefully be done via your security team having performed due diligence and permissions review, and ascertaining whether the app has legitimate use within the business. As with the consent phishing example, a user may have granted a third-party app access to their mailbox or OneDrive files without fully grasping the implications of their actions.

Push provides visibility to the security team whenever a new third-party integration is detected by way of notifications via a designated Slack or Teams channel. This may help your security team stay on top of unsanctioned apps by providing the ability to remove integrations which may provide unnecessary risk to your organization.

If you’re interested in further reading about how attackers can compromise your environment through SaaS apps, this article may shed some light on the topic.