OAuth 2.0 Attack Vector on Cloud Assets
This article is related to a recent security event that was reported by Microsoft. Here is a synopsis of what happened – A group of hackers used OAuth consent framework as the attack vector and tried to gain access to organizational assets stored in Office 365. Microsoft had to take legal recourse to fight this cybercrime and reported this on July 07, 2020.
Since this is very much on the topic of OAuth 2.0 & related to my previous article, I will try to explain how this attack was executed and what are some key preventive actions that could be taken to avert such attacks.
Why is this important?
Business Email Compromise (BEC) or Email Account Compromise (EAC) is the most prevalent form of attacks that happens today. As per FBI’s 2019 Internet Crime Report, the single most factor that contributed to the financial loss for victims is BEC attacks. In fact, in 2019 alone, BEC accounts for a whopping $1.7 billion loss – which is nearly 50% of all the losses reported (to Internet Crime Complaint Center) in 2019.
How does this attack happen?
So without much ado let us look at the modus operandi of this type of attack. I have given below a step by step approach of what the attacker has done in this scenario:
- To begin with the attackers builds a web application and registers the app in Azure.
- Then as a step two they create a HTML email template that looks exactly like a Office 365 ‘document sharing’ template. (Remember the email you get when a user shares a document with you saying: “business_data.xlsx has been shared with you” with the link to the excel file?).
- Then as a step three, a phishing attack is launched using the HTML email template targeting organizational email users.
- The key here is to keep the “From” email address as non-suspicious. If I have to make something up, it could be something like “non-reply@Officeonline.com”. Voila! Looks genuine, right?
When a legitimate email user clicks on the shared excel link, internally this excel redirects the user to the web application and then the web application leverages the OAuth consent framework to gain access to the user’s secure assets – emails, documents etc.
Though this attack was reported & acted on by Microsoft, please understand that the attack vector is very generic and can happen to any solutions that you are using for your organization & this could be happening even if you have a secure in house or third party Identity and Access Management solution..
How does the web app gain the access to your data?
The web application will need to access Microsoft Graph API to access user’s office 365 data. Microsoft Graph API is a multi-tenant API that exposes the Office 365 API to any user who would like to consume data from Office 365. Graph API utilizes OAuth 2.0 authorization protocol to secure the API from unauthorized access. So the web application will have to do two things in order to access the API successfully.
- The web app must be registered in Azure AD (to get App ID & generate app secret).
- Then the application needs to create a “Authorization Code Grant” flow to the common v2.0 endpoint in Azure. For example, the request could look something like below:
GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id= &response_type=code&redirect_uri=http%3A%2F%2Flocalhost%2Fmulti-app%2F&response_mode=query&scope=https%3A%2F%2Fgraph.microsoft.com%2Fcalendars.read%20https%3A%2F%2Fgraph. microsoft.com%2Fmail.send&state=12365
That’s all that is required to get access to user’s data. Now you may be wondering, how do I get access to another tenant, if my web app is registered in my home tenant. In order to build an application and access some other tenant, the developer must take advantage of the multi-tenant web app option available in Azure AD. In other words, the attacker creates a web application in his own tenant and registers it as “multi-tenant app” in Azure AD. This would allow the application to be accessed not only by users of that home tenant but users from any Azure tenant could access this application.
Now the final point here is that when the user clicks the web application link (that is masqueraded in the email as some file link), the user is indeed prompted with the consent screen like below:
As you can see from the prompt above, the consent clearly says that “ This application is not published by Microsoft or your organization” – this clearly means that a third-party multi-tenant app is trying to access my Calendar data . However, most of the users simply click “Accept” without reading through the consent form in a rush to access the content. Well, that’s it and you stand compromised!
What to do to prevent these types of attacks?
The most fundamental and important thing here is to ensure that the users in your organization are trained to not click ‘Accept’ on any Consent Form by default. Security training to organizations is pivotal line of defense against these form of phishing attacks. The employees of organization thus become the most formidable firewall in any organization and this facet of security awareness and training should be given utmost importance.
The second part here is more of a request to Microsoft. Platform providers like Microsoft should provide an option for Global Tenant Administrators to gain more control & visibility of their data. It could be something like below:
- “Allow default access to third party applications in my tenant provided there is user consent?” (Yes/No)
- “Notify me when a new multi-tenant app tries to register in my tenant” (Yes/No)
- “Notify me when request is made to ‘Graph API’ (or any public facing API) requesting access to my organizational data” (Yes/No)
This will allow administrators to have more control over these types of scenarios and prevent such scenarios from happening or get alerted as soon as such an event takes place.
The third part is for API developers to understand the confidentialityof the data that is exposed through the API and ensure the scoping and permission aspect of OAuth is correctly implemented – For example, “org_api/get_user_PHI_data” should be scoped to include admin consent mandated on top of user consent for third party application (customer/vendor apps) access to this API. Even if the web API is secured by OAuth, lack of proper scoping and permission can expose the system to vulnerabilities (like the one described in this article).
Organizational data is a valuable asset for any organization and it takes a continuous collective effort from various stakeholders to ensure it stays secure.
Cheers!
