How-To

Are Fake Applications 'Pwning' Your Business?

Whether you call them "Illicit consent grants" or "fake OAuth applications," these threats should be taken seriously, says Paul Schnackenburg, who shows you just how to protect your organization.

• By Paul Schnackenburg
• 11/02/2020

There's a fairly recent threat to your organization and your data; Microsoft calls this "Illicit consent grants." Personally, I like "fake OAuth applications" better, but no matter the name, these are a genuine threat and what you don't know can hurt you.

In this article I'll look at what these applications are, how the threat manifests and what you can do about it with built-in features in Microsoft 365, as well as what Microsoft Cloud App Security brings to the table.

OAuth Permissions
Everyone with a smartphone has had the experience of installing an app from the store and being prompted for permissions -- "to work this app needs access to your profile, your emails and your savings account" (that last one is a slight exaggeration).

Microsoft also has a thriving ecosystem of third-party apps that live in Azure and enhance productivity in Office 365, Dynamics 365 etc. But it's possible (as several successful attacks over the last few years have shown) to create a malicious app and trick users into granting the requested permissions, perhaps through a link in a phishing email or a text message purporting to be coming from the IT department.

These apps rely on the OAuth 2.0 standard for access delegation which is intimately connected to OpenID Connect (OIDC) as the authentication layer on top of OAuth, not to be confused with OATH which is the initiative for Open Authentication.

The risk here is if the app looks legitimate (anti-malware, email hygiene or another security solution are popular choices) it only takes one user to grant the permissions and the attackers can now access whatever data they've been given. Resetting the user's password or enforcing MFA has no bearing on the access tokens the application now has. And even fairly low-level permissions such as read mailbox gives attackers fantastic insights to pivot further into the organization and eventually elevate their privileges.

One way that Microsoft has tackled this problem is to verify publishers, which ensures that the app is from the company it says it's from, rather than a similar sounding name. Currently there are over 700 publishers with more than 1300 app registrations covered. Note that while this makes it more obvious if the consent screen is from an unverified publisher (see the screenshot below), Microsoft does not test code of the app itself. There are however two more levels beyond verification, Publisher Attestation and Microsoft 365 Certification.

There are two types of permission request, one where a user grants permission to any data they have access to in Office 365, another where an administrator grants permissions to all company data in a tenant.

Here is an example of a user permissions screen, note that this app is requesting quite a few permissions that a malicious actor could do a lot with:

Defending Against the Threat
Dealing with this threat needs a multi-pronged approach -- first of all you need to include this in the security training for your users (if you allow them to install apps) and also your administrators who need to understand the risks. Second, you need to define an organizational policy around OAuth apps and then reflect those decisions in the technical controls you implement. Third, you need to investigate what apps are already in your directory and what permissions they have.

There are two levels of controls. If you have access to Microsoft Cloud App Security (MCAS) it gives you superior investigation and policy application capabilities (see below). If you don't, Azure Active Directory (AAD) provides some recently released capabilities.

Azure Active Directory
Let's start with your options around controlling the installation of new apps. As a global administrator, application administrator or cloud application administrator head over to the AAD portal, click on Enterprise applications and then Consent and permissions. Here you can turn off the ability for users to install/grant permissions altogether, let users consent to any app permissions (the default) or let users grant permissions for a selected/low impact permissions for apps from verified publishers only.

On the same screen you can also define what happens to apps for a group (think add-ins for Teams), where again you can block it outright, allow any group owner to install apps or only selected users.

If you pick the option to limit the permissions that users can grant, you're taken to the Permissions classifications section where you define what's low impact for your organization. You can pick from a set of five that Microsoft suggest or add from a long list of APIs and from the APIs that are already in use in your business.

If an app request more permissions than a user can grant, in the past they simply got an error message with the suggestion to contact their administrator, with no clue as to whom that could be. Now you have the option (in preview), under Enterprise applications - User settings, to configure a set of administrators that will receive the consent request (via email or in the portal) and can approve the request, deny it which won't stop future requests or block it, which will stop any further requests for this app.

Microsoft will prevent users from consenting to apps from unverified publishers after Nov. 8 2020.

Here's what it looks like for a user when the app is asking for higher permissions than they can grant:

You'll also want to investigate what applications have already been granted access in your directory and what permissions they have, head back to Enterprise applications -- All Applications -- pick one and select Permissions where you'll see Admin and User consent tabs.

Click Review permissions and select the scenario that applies: control access; the app has too many permissions; the app is suspicious and warrants investigation; or it's malicious and you want to get rid of it. Depending on which one you pick, you get options for revoking access, revoking permissions and revoking refresh tokens.

I think it's great that Microsoft is shining a spotlight on this insidious risk and have added new features to help us in IT manage the risk but be aware that in a large organization the workload of investigating the risk profile of each app, then approving or rejecting user requests for apps can be time consuming, not to mention going through each existing application's permissions one by one.

Cloud App Security
If your business has seen the wisdom of implementing a cloud access security broker such as MCAS you have more options for managing OAuth apps.

Login and head to Investigate -- OAuth apps. This will show you all the apps that have been granted permissions in your tenant. You can sort by three levels of permissions impact, specific permissions, as well as by user and community use. This last one is interesting as it looks across all MCAS deployments worldwide and an application that's common is unlikely to be malicious, whereas an uncommon or rare one warrants further investigation. Using these different conditions, you can build your own queries to sift through long lists of apps.

You can also approve or ban apps that are already in your tenant using policies in MCAS as well as build policies to manage future app installations.

Conclusion
Do not let this one slide. There is a risk that this lesser-known threat is already in your environment and you need to investigate as well as implement some controls to ensure that risks from future apps are mitigated. At least Microsoft provides some tools to get you started.