Using Cloud App Security against illicit OAuth consent grants

Posted by

On Thursday the 6th of December 2018 I had the pleasure to co-host a session with Ben Menesi. Ben is head of products at Ytria and they provide great tools for Office 365. Ben’s an ethical hacker as-well, which made our session very interesting.

Ben’s my co-author for this post and please check out his Twitter feed and LinkedIn profile to see what great other stuff he shares and cares about!

Our session was for SharePoint Saturday Geneva (yes, really) and covered the threats to Office 365.

As an ethical hacker, Ben made it quite difficult for me (the security guy) to present mitigation options for the different scenario’s. But I did manage. One of the scenarios was somewhat complicated. The scenario was about illicit consent grants.

Consent

The scenario has been around for some time. Here’s one of the first mentions: https://community.spiceworks.com/topic/2104688-heads-up-new-ransomware-strain-encrypts-cloud-email-real-time-video

In this scenario a user is asked to provide consent to an application. After consent has been provided, the application will act on behalf of the user and his/her permissions. In the more frightening scenarios, the users mailbox will become encrypted by ransomware.

More information on this attack can be found here:

To quickly demonstrate how to simulate this attack and how to set-up an MCAS policy to detect this, I created this video. In the video I use an Azure application, Postman and the Microsoft Graph to get an overview of SharePoint sites within a tenant. A very friendly scenario.

illicit content

But keep in mind that this scenario is very serious indeed. Also keep in mind that I’m demonstrating this on one machine. You need to realize that in the real-world, the authorization code would fall into the hands of someone with criminal intent…. Well, look and see….

Consent scenario

So. I tested this with two types of apps. One was created in my own tenant. The second one was created in a totally different and non-connected tenant. Both worked. As the video shows, using an app from a different tenant, I was still able to get to the list of SharePoint sites.

Do note that I was using a network sniffing tool. Normally the authentication code would be intercepted by some malicious web server on the net.

Here’s the OAuth flow (as documented in https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow). The authorisation code can be used to obtain the token. In my case, using Postman.

convergence_scenarios_native

There are several  mitigation options for this scenario. Educating your end-users is one of these. Other ones are detailed in the articles as mentioned above. In addition to these, you might want to look at disallowing your users from granting access to Office 365 information (Admin portal | Settings | Services & Add-ins | Integrated Apps) and look at the users settings for your Azure AD. See below.

Consent3

As an admin you might want to disallow users from consenting to any app. This is an option in the Azure AD Enterprise application user settings. If this is the case, any app will need administrator’s approval before being used. This is pretty secure, but will put certain strain on your administrators.

Consent4

Besides these, you can use Microsoft Cloud App Security, if available. In the video I created a policy in Microsoft Cloud App Security. And these are the steps I took.

Microsoft Cloud App Security

First of all, in the policy section, create an OAuth app policy.

MCAS OAuth

You can set the permission level of the app (low, medium and high) and if the app is known to MCAS. This is the Community use option. If it is a common app, then it might not be a problem. But I’ve set this policy to Uncommon and Rare – because this should detect any malicious app.

MCAS OAuth 2

Based on these criteria you can set alerts (even using Flow – see my other blog for that). But more importantly, you can revoke the app.

MCAS OAuth 3

After having activated this policy, both my little apps were blocked and could not be activated again.

MCAS OAuth 4

An error-message tells us that the app has been disabled (blocked).

MCAS OAuth 5.png

BUT…..

MCAS seems to offer a protection layer against unauthorised OAuth apps. But it took some time for the policy to be activated. This also means that it took some time for the app (from the different tenant) to be blocked. In the meantime you may already have some users which are effected.

But, I must admit, MCAS did block any access by this app from that time on.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s