Third-Party App Integration Permissions: What You Need to Know

Originally published by Abnormal Security.

Written by Ryan Schwartz.

On average, enterprise organizations have roughly 300 third-party applications integrated into their cloud environment, according to our Knowledge Base data. It isn’t surprising either as there are apps for every imaginable business need from collaboration to communication to instrumentation to coagulation. Okay, maybe not that last one, but the point stands that organizations are using a ton of apps.

Of course, the more technology an organization uses, the more attackers will attempt to find ways to compromise those technologies. Exploiting app integrations and permissions is proving an effective tactic for two reasons:

• Email platforms give applications some truly concerning permissions
• Security teams often lack visibility into when these permissions change, leading to blindspots and gaps

Knowing this, what are some of those permissions? What are the risks? And how can you mitigate those risks? Let’s dive in.

Defining Third-Party App Permissions

As I’m sure you are aware, every time an application is installed or integrated, users are asked to allow that application certain permissions. In the case of cloud email, you are most likely familiar with read or write permissions, wherein an application gains the ability to create an event on a user’s calendar, create an email message, or read from the calendar or inbox.

But there are thousands of permissions that can be configured for a given application, and while we will talk about the risks of vanilla read and write access, it is worth noting some of the more bizarre abilities an app can be granted.

Did you know that, on Microsoft 365, an integrated application can be granted the ability to respond as a particular user through chat apps? Essentially, an application can masquerade as any user and go send chat messages to any other user. Similarly, there are permissions allowing apps to join video conferences as individual users.

Now, both of these permissions have perfectly benign reasons to exist, allowing IT ticketing systems to respond as a helpdesk employee or allowing a notetaker app to join a video chat on behalf of its owner.

The issue, though, is what happens when these permissions are not allowed by organizational policy? What happens when a compromised user or malicious insider gains access to these over-permissioned apps? What happens when security can’t see that an app with these permissions was integrated or an existing app had its permissions changed to allow some of these functions?

Understanding the Risks of Using Third-Party Apps

The core risk around third-party app integration is that an over-permissioned app could allow malicious actors to gain access to sensitive data. But there are a few ways that this can happen that are all worth noting. App attacks can be the primary threat vector or an accidental side door into the cloud email platform.

Consent phishing, as an example, is a type of payloadless phishing attack, which serves a user a link that by all accounts is legitimate, taking the user to a permissions page for an app from a verified publisher. Of course, this app is not from a verified publisher and is instead attacker-owned. Once permissions are granted for that app, the threat actors behind it have access to the victim’s corporate account and can begin to exfiltrate data.

On the other side of the fence, for applications already integrated into the cloud email platform, there is an entirely different risk. As mentioned earlier, security teams often lack visibility into app permission changes. In fact, roughly one-third of security practitioners report being unable to see SaaS app security settings.

Considering the powers an app can be granted, this is a significant issue. Not every application a user installs is legitimate, and many of those applications request unnecessarily broad data access. Even if the endpoint isn’t a threat actor compromising the data in the application, there may be compliance and privacy implications that could cause reputational damage rather than financial (although the two are firmly intertwined).

While determining app permissions is often on the shoulders of IT or the line of business owner for a given application, security needs to have a hand on the steering wheel—or at least be in the passenger seat with a hand on the emergency brake.