The potential dangers that lurk in massive multi-tenant infrastructures were illustrated by a weakness in an Office 365 API discovered in early July 2016 by researchers at Cogmotive, an ISV specializing in reporting and analysis of Office 365. After Cogmotive reported the vulnerability to Microsoft, it was quickly fixed and Cogmotive was thanked through Microsoft’s Online Services Bug Bounty program. All’s well that ends well.
The vulnerability came to light in the preview version of the new Office 365 Admin Center. Like all of the other ISVs in the reporting space, Cogmotive obviously has an interest in understanding the kind of reports Microsoft includes in the Office 365 Admin Center (Figure 1) so that they can create some clear blue water between the Admin Center and their product. The researchers noticed that Microsoft used a new and undocumented API when a report was exported and decided, like any good researcher would do, to find out what happened.
Figure 1: Office 365 Admin Center Reports
When you export a report from the Office 365 Admin Center, the portal calls the API to run in the reports.office.com domain. The request to access and export the report data is authenticated using OAuth2, which is the default authentication mechanism used between the different services that make up Office 365. The output is report data in CSV format.
The researchers experimented with some code to use the new API in an attempt to understand how it worked and to determine whether it might be able to extract some additional value from the Office 365 reporting data mart. They created a simple Azure AD application to use the Office 365 management API with the permissions shown in Figure 1.
Figure 2: Permissions for the test Azure AD application
To test the API, they created a PowerShell script that accepted the GUID identifying an Office 365 tenant as input and then called the Azure AD application to generate an OAuth bearer token that is then used to authenticate against the API.
To identify it within the Office 365 multi-tenant environment, each tenant is assigned a unique GUID. To discover what that GUID is for a tenant, you can follow Microsoft’s advice or access the URL (insert your tenant domain to replace “yourtenant.com”):
Different browsers display the results in different ways. However, you’ll see the tenant GUID displayed for the various endpoints, such as the authorization endpoint shown below:
The script and application worked as expected and retrieved reporting data for the tenant. The next test was to authorize the application to run against another tenant and see if that worked. It did and data could be retrieved for that tenant too. They could retrieve a CSV-formatted list of usernames, display names, email addresses, the Office 365 licenses assigned to accounts, and various statistical reporting information for the tenant (Figure 3). By changing the URL passed to the API to different endpoints, they could also retrieve the names and URLs of all the SharePoint Online site collections and OneDrive for Business sites in the tenant.
Figure 3: Reading reporting data for a tenant
Being curious people, the researchers then ran the application against a tenant that had not authorized its use. Instead of the expected “Access Denied” error, access was granted to that tenant’s reporting data. Testing against other tenants to determine whether they had made a mistake in what they had done, the researchers were able to access reporting data from any tenant they settled upon. Had they been so inclined, they could have exploited the vulnerability to extract data from the tenants belonging to major Fortune 500 companies. Apart from being illegal, such testing is prohibited by Microsoft under the terms of their Online Services Bug Bounty terms, which state:
“…you are allowed to and encouraged to create a small number of test accounts and/or trial tenants for the purpose of demonstrating and proving cross-account or cross-tenant data access. However, it is prohibited to use one of these accounts to access the data of a legitimate customer or account.”
The testing conclusively proved that a vulnerability existed in the API. After considering the matter for a while, the Cogmotive team believed that the evidence supported a hypothesis that the OAuth implementation within the API failed to check that applications requesting access to tenant data actually had the necessary permissions.
Obviously, any vulnerability in an API is bad. One that exposes potentially sensitive user data carries additional consequences for a cloud service provider because different jurisdictions around the world can take action against a service provider if information under their control is leaked. For example, the European Union’s general data protection regulation can consider names and email addresses of employees as personal data. Given the way that email addresses are used today as identifiers to access many cloud services, the loss of email addresses and other personal attributes like display names could be especially serious if the data ended up in the hands of hackers. To recognize the seriousness of these situations, if such a breach occurred after the regulation comes into force in May 2018, Microsoft could be fined up to 2% of their annual worldwide revenue of the previous year before the incident. That could be a nice round $2 billion fine.
In this case, no evidence exists that any such breach occurred. Microsoft moved to address the problem very quickly after Cogmotive provided the Microsoft Security Response Center (MSRC) with the evidence outlined above. Cogmotive has discovered vulnerabilities in Office 365 APIs before, so the team there was familiar with the process that individuals and companies should follow to advise Microsoft about security vulnerabilities. Microsoft maintains an honor roll of those who have assisted in the eradication of security vulnerabilities in Microsoft Online Services.
All software is prone to vulnerabilities. It is, after all, just code written by fallible human beings. It can be difficult to anticipate all of the problems that need to be handled in the code that supports the operations of a massive environment like Office 365. However, it seems like this was not a condition that should have been overlooked as any API that can expose sensitive data belonging to a tenant must ensure that the requests it handles are properly authenticated and authorized. Fortunately, the issue was identified and reported by the diligent folks at Cogmotive, who deserve all our thanks for helping to make Office 365 a little safer.
Follow Tony on Twitter @12Knocksinna.
Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros”, the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle.