Table of Contents
What is application consent and why is it useful?
Application consent allows users to authenticate third party web apps and mobile apps to use their corporate user accounts. This can be a very useful feature, since it supports Single Sign-On and prohibits that users have a user account on each website.
Because many users still reuse the same (or similar) password often, so if a third-party web app gets compromised, so are the user accounts and credentials.
If this consent mechanism was purely used for authentication only, there wouldn’t be an issue. This consent mechanism, however, leverages the OAuth permissions-grant feature (part of the OAuth standard) that can also be used to allow one web app to access another web app on behalf of the user.
A nice example of this is https://draw.io. This web application allows you to create small Microsoft Visio-like diagrams and drawings, but does not provide storage capabilities itself.
When users consent, they grant the Draw.io web application access to all of the files on their OneDrive as well as on SharePoint sites (all the files they have access to). Draw.io will even request this access in offline mode, which implies that it continues to have access, even if the user is no longer logged on!
It leverages the OAuth mechanism so users can select their own cloud storage (in this case Google or OneDrive) and it tries to register itself with Entra ID as an enterprise application when a user consents to the application using his or her corporate Entra ID account.
So, while application consent is a nice and useful feature (and even helps to improve the security by providing a controlled single sign-on mechanism), it can also be very dangerous when used in the wrong way.
Why are threat actors using this mechanism now?
Threat actors have recently been using phishing attacks to get hold of corporate user accounts and their credentials. They then misuse those compromised accounts to attack customers and partners through new phishing mails or attack corporate (cloud) applications.
As a defence, many organizations have implemented multi-factor authentication (MFA). Consequently, many of the attacks have been blocked, since a password alone is no longer sufficient to compromise a user.
As a reaction, the threat actors have been leveraging legacy protocols (such as IMAP, POP3 and SMTP) that don’t support MFA and will still allow an attacker backdoor access to emails and other information in an Office 365 tenant. Again, many organizations have blocked these legacy protocols by now and closed this attack path in recent months.
Why doesn’t multi-factor authentication protect against attack?
The problem is that application consent (OAuth) is a feature of modern apps and it only becomes a vulnerability if users consent to untrusted or malicious applications… which they unfortunately do, if they are convinced to do so in a well-written phishing mail.
Multi-factor authentication is a mechanism to protect against credentials theft. OAuth-authorizations (the basis for application consent) take place after authentication and MFA does no longer play a role at that point.
Why is this not disabled by default?
As explained above, the application consent feature can be used for good and bad. As risks evolve over time, some features that are intended to protect users (by avoiding that users have credentials in multiple places) can be used against users, if the attack scenario is well-planned (in this case through phishing mails that convince the user to accept the application consent). Unfortunately, the users are often the weak point in the process and if they are not aware of threats, they will make the wrong decision when presented with the choice whether or not to accept a risk.
How to use the new admin consent request process
Microsoft has recently released a new process that allows users to forward the application consent request to an administrator, rather than accepting it themselves.
When configured, the user will be shown a dialog that highlights the risk as before (by enumerating all the access rights requested by the app), but instead of allowing the user to accept the consent, he or she can now only forward the request to an administrator, while stating the reason for needing this application. The administrator can then allow or reject the request on behalf of the user or even the whole organization.
How to identify and block invalid app consents using MCAS
Microsoft Cloud App Security (MCAS) provides you with an easy way to keep track of all the web apps your users already have consented to and lets you review and allow or block each one of them.
You can even create custom policies that automate this process and could for example automatically block any app that requests too many access rights, especially if the application is rarely used worldwide.
What should I do now?
Make sure you disable the “application consent by users” today, review all the existing permission grants to third party applications and enable the admin request process on your tenant.
The issues described in this blog clearly highlight the need for continuous security improvements and hardening of all existing and new services in cloud platforms.
In case you need assistance with setting this up correctly, reviewing and hardening your existing configuration or ensuring that you have secured your Microsoft 365 environment correctly, do not hesitate to contact us at [email protected].
