Demonstration – Illicit consent grant attack in Azure AD / Office 365

Disclaimer: All information contained within this post is common knowledge, given you grasp basic concepts of AAD default behavior, OAuth2 Authorizations and how Javascript works in browsers.  

Granting access to 3rd party apps is not a new concept in the age of Facebook and big consumer services. In this article, we demonstrate a similar scenario, but using a known enterprise applications ecosystem (Azure AD) The attack demonstrates that 3rd party app requesting access to your data might not be what it claims to be.

In the PoC we demonstrate attack, where a user clicks a link which redirects a user to the originally requested resources but pops up a permissions request in the middle, to extract user data to other service.  

How does it work?  

The attacker creates a multi-tenant app and adds non-admin requiring API permissions for the desired API’s. The attacker then delivers the link to end user, which after clicking the link only has to consent (Approve) the API permissions for the attacker.

The attacker has then access to user's mail. This happens because attacker exfiltrates in the background the Access Token and uses it against the Exchange Online API  Down below I describe why it might be hard for the user to discern good app from the bad app.

Why it works?

Multi-tenants apps by default have access to end users data unless your Azure AD Admin has disabled the particular defaults that enable this behavior.

PoC

• Create multi-tenant Azure AD Web-App/API + Azure Web App that delivers the JS. client side code to browser from Node.JS Web App
• I am using minified ADAL.JS as <script src in the code. Other than that, I’ve just added few custom functions to the code and studied a wide variety of existing Vanilla ADAL JS Apps in GitHub
  • https://secure.aadcdn.microsoftonline-p.com/lib/1.0.11/js/adal.min.js
• Figure out a way to deliver the link to the victim/victims in other AAD / Office 365 tenants
• I’ve opted to forge existing Microsoft Newsletter with link to malicious Azure Web App to
• When a user clicks the link, consent dialog is prompted.

• Consent – This as any other dialog, you would get prompted for when consent framework kicks in (This is where the confidence part happens)

The process is same for benign apps, so there is superficially nothing to separate the good app from the bad (except caution, which is often unheeded, if you consider how often a mobile application presenting similar dialog is approved for multiple permissions in a mobile phone)

• The user is redirected to the malicious app with seemingly benign OIDC-Flow (response_type=id_token)… no mention here of the OAuth2 Implicit Grant Flow (yet)

Redirecting...

• Hidden iFrame executes the OAuth2 Implicit Grant Flow, and gains Access Token to resource

• AJAX HTTP is used to post the Access Token as Payload to external exfil service
  • In case you wonder, that I’d left the function key there :)… Just try

• The user is redirected to the original link requested in the mail

• Token is copied by the malicious actor from Azure Functions where it was posted

• A Separate Powershell session running in some dark corner of the world is now searching users mail content for several keywords, and playing with the Access Token for the next 3600 seconds

<- Users timeline stops here

–> Perpetrators timeline begins here

See it live:

Evil side: