Executive summary
Wiz Research discovered a new attack vector in Azure Active Directory that exposed misconfigured applications to unauthorized access.
These misconfigurations are fairly popular, especially with Azure App Services and Azure Functions. Based on our scans, about 25% of multi-tenant applications turned out to be vulnerable.
We found several high-impact, vulnerable Microsoft applications. One of these apps is a content management system (CMS) that powers Bing.com and allowed us to not only modify search results, but also launch high-impact XSS attacks on Bing users. Those attacks could compromise users’ personal data, including Outlook emails and SharePoint documents.
All issues were reported to the MSRC team. It fixed the vulnerable applications, updated customer guidance, and patched some AAD functionality to reduce customer exposure. MSRC’s blog can be found here.
To check whether your environment has been affected by this misconfiguration, please refer to the “Customer Remediation Guidelines” section of the blog.
BingBang attack flow
Introduction
From Amazon Cognito to Google Firebase or Microsoft Azure Active Directory, there are many cloud-based identity providers on the market serving various business needs. The complexity of each IdP facilitates misconfigurations, which can potentially be leveraged by threat actors to compromise organizations’ production environments.
In this blog post, we will demonstrate how Microsoft itself fell prey to AAD’s configuration challenges, and inadvertently exposed internal applications to external attackers. These applications allowed us to view and change various types of sensitive Microsoft data. In one particular case, we were able to manipulate search results on Bing.com and perform XSS attacks on Bing users, potentially exposing customers’ Office 365 data such as emails, chats, and documents. This blog will also provide details about the misconfigurations, and how to detect and mitigate them in your environment.
Azure Active Directory (AAD)
Microsoft offers its own SSO service in Azure, AAD, which is the most common authentication mechanism for apps created in Azure App Services or Azure Functions. AAD provides different types of account access: single-tenant, multi-tenant, personal accounts, or a combination of the latter two. Single-tenant applications only allow users from the same tenant to issue an OAuth token for the app. Multi-tenant applications on the other hand, allow any Azure tenant to issue an OAuth token for them. Therefore, app developers must inspect the tokens within their code and decide which user should be allowed to log in.
In the case of Azure App Services and Azure Functions, we see a textbook example of Shared Responsibility confusion. These managed services enable users to add an authentication function with the click of a button, a seemingly smooth process for the application owner. However, the service only ensures the token’s validity. It’s not clear to application owners that it’s their responsibility to validate the user’s identity via OAuth claims and provision access accordingly.
With single-tenant authentication, the impact is limited to the application’s tenant – all users from the same tenant could connect to the application.
But with multi-tenant applications, the exposure is as wide as it gets – without proper validation, any Azure user will be able to log in to the application.
This complicated architecture is not always evident to developers, and the responsibility to validate the end-users’ tokens is unclear. As a result, configuration and validation mistakes are quite prevalent.
Upon recognizing these issues and their potential impact, we started scanning the internet for exposed applications. The results surprised us: 25% of all the multi-tenant apps we scanned were vulnerable to authentication bypass.
The following case study on the “Bing Trivia” application, which we have dubbed “#BingBang,” illustrates how Microsoft itself fell victim to misconfiguration pitfalls and exposed one of its most critical apps to any individual on the internet.
The BingBang case study
Part 1 – Reconnaissance
To measure how common this misconfiguration was, we started scanning Azure App Services and Azure Functions for exposed endpoints. The scan yielded many potentially vulnerable websites, so to narrow the scope of the research, we decided to focus on Microsoft’s own tenant.
We spotted several Microsoft apps, but the first domain that caught our eyes was bingtrivia.azurewebsites.net. Given Bing is a very popular product these days, anything related to it was of interest to us. To validate the exposure, we created a new user called “Wiz Research” in our own tenant and tried logging in to Bing Trivia with it.
Even though we did not belong to the Microsoft tenant, we successfully logged in and landed on the Bing Trivia home page.
We started to examine the page in front of us. At first glance it appeared a bit unremarkable – just a simple CMS with lots of sections crammed into it. To determine whether the system was intentionally open, we needed to understand its purpose.
Given the app was named “Bing Trivia”, we assumed it was intended for trivia content. However, upon browsing the app, we noticed several interesting sections related to core Bing content. One of these sections was the “Carousels” section, which contained a table with search result suggestions appearing on Bing. Another section showcased quizzes and background images, which appeared on the Bing.com homepage that same day. This raised the question – can this panel enable us to modify Bing’s search results?
Part 2 – Altering search results
To verify our ability to control Bing search results, we selected a carousel in the CMS and slightly altered its content. We wanted to make a small change, which would be easy to revert. We chose the “best soundtracks” query, which returned a list of highly recommended movie soundtracks; we then proceeded to change the first item, “Dune (2021),” to our personal favorite, “Hackers (1995),” and saved our edit.
To our surprise, our new result immediately appeared on Bing.com, complete with our new title, thumbnail, and arbitrary link!
This proved that we could control Bing’s search results, and as we would later confirm, this control extended to Bing’s homepage content as well.
In order to ascertain the breadth of the attack surface, we then decided to leverage this access and test XSS viability with a sample harmless payload. The payload also ran as expected, so we quickly reverted our changes and immediately reported our findings to Microsoft.
Part 3 – Attacking Bing users
While working with Microsoft on the report, we started investigating the impact of the XSS. We saw that Bing has a “Work” section that allows you to search your organizational directory; when inspecting this functionality, we realized it was based on the Office 365 API, with the business.bing.com hostname used by Bing for Office-related communications.
This really piqued our interest, since many organizations use Office 365 to store their most sensitive business data. One specific endpoint created JWT tokens for the Office 365 API, so we generated a new XSS payload via this endpoint:
We then tested this payload against our old injection point and retrieved a valid token from our “victim” user (in this case, our research account).
This token enabled us, as “the attacker”, to fetch the victim’s Office 365 data including Outlook emails, calendars, Teams messages, SharePoint documents, and OneDrive files. Here we can see the attacker’s computer, successfully reading emails from the victim’s inbox:
A malicious actor with the same access could’ve hijacked the most popular search results with the same payload and leak sensitive data from millions of users. According to SimilarWeb, Bing is the 27th most visited website in the world, with over a billion pageviews per month – in other words, millions of users could’ve been exposed to malicious search results and Office 365 data theft.
Additional vulnerable applications
In addition to the Bing Trivia app, we found several other internal Microsoft apps with similar misconfigurations and exposure to anyone trying to log in:
Mag News: A control panel for the MSN Newsletter, capable of sending arbitrary emails from a trusted Microsoft email to a huge audience.
CNS API: An API for Microsoft’s Central Notification Service, capable of reading and sending internal notifications to Microsoft developers.
Contact Center: An API for Microsoft’s Contact Center, controlling call center agents for Microsoft’s customer representatives.
PoliCheck: “PoliCheck” is an internal Microsoft tool that is used to check for forbidden words in Microsoft code. This application was essentially the centralized database for PoliCheck rules. Rules include words in over 100 languages, ranging from profanity and slurs to geopolitically and legally controversial issues.
Power Automate Blog: A WordPress admin panel, controlling a very active blog hosted on powerautomate.microsoft.com. This panel allowed us to create and edit posts with arbitrary HTML content, and publish them to a trusted Microsoft.com domain.
COSMOS: A file management system, managing over 4 exabytes (!) of Microsoft’s internal files. COSMOS categorizes files by Microsoft divisions and teams, and enables in-app file listing, reading, and editing.
All these issues have been reported to Microsoft. The Microsoft team fixed them in a timely manner and awarded us a bug bounty of $40,000, which we will donate. Although these services did not fall within the scope of the bounty program, the Microsoft team based their decision on the additional product and guidance improvements for AAD that stemmed from our findings.
Customer remediation guidelines
Am I affected?
The issues we identified in this research may affect any organization with Azure Active Directory applications that have been configured as multi-tenant but lack sufficient authorization checks.
Based on data from our scans, we assess that exposure is significantly more common across Azure App Service and Azure Functions applications, where validation responsibility is unclear to developers.
How do I detect these issues in my environment?
Administrators can use the Azure Portal to query their AAD service principals and look for any that are configured to allow multi-tenant access. These should appear under “App Registrations” or the “Authentication” section of each application’s page.
It is also possible to use the Azure CLI to query for multi-tenant applications:
az ad app list --filter "(signinaudience eq 'AzureADMultipleOrgs' or
signinaudience eq 'AzureADandPersonalMicrosoftAccount')" --query "[?web &&
web.homePageUrl].{AppName:displayName, AppID:appId, AppURL:web.homePageUrl}" To verify whether the application is vulnerable or not, use your web browser to sign in to your app with a user from a different Azure tenant than your own. If this login is successful, and your app is not meant to be exposed to other Azure tenants, the app is vulnerable.
Wiz customers can use either this query to spot all their potentially vulnerable assets, or this query to spot App Services and Functions specifically. We also recommend Wiz users to refer to our customer advisory for additional guidance.
How can I resolve these issues?
If your application doesn’t require multi-tenancy, simply go to your app’s page and switch to single-tenant authentication.
If you do need to grant external tenant access, you have multiple ways to remediate your exposure.
If your app needs to be available on a specific external tenant other than your own, you can require user assignment or use conditional access policies.
Otherwise, you will need to implement claims-based authorization logic by performing token checks within your application code. There is no one-size-fits-all solution, and you should consult with your engineering team to find the right solution for your app. However, it is recommended to consult the relevant Microsoft documentation beforehand.
How can I know if this issue has been exploited?
According to Microsoft, Azure Active Directory logs are insufficient to provide insight on past activity. The recommended solution is to view your application logs and look for any suspicious logins.
Takeaways
We see this issue as a case of cloud exposure. Cloud Service Providers allow users to expose many of their cloud resources externally with the click of a button. The same thing happened here, where users could check the wrong box and publicly expose their app by accident.
Moreover, users of Azure App Service and Azure Functions may not be fully aware of who is responsible for validating access tokens. Users who enable authentication via the Azure Portal may assume their application is fully secured. However, users must implement additional token validation and authentication in their application's code to ensure authentication security.
Summary
In this blog we have covered real-world examples of OAuth misconfigurations, with a focus on Microsoft’s own applications. Based on what we found, we have concluded that this issue is both easily exploitable and severely impactful. This is why we urge anyone who owns multi-tenant apps to scan their environment with the guidelines provided above.
Disclosure timeline
Jan. 31, 2023 – Wiz Research reported the Bing issue to MSRC
Jan. 31, 2023 – MSRC issues initial fix to Bing app
Feb. 25, 2023 – Wiz Research reported the other vulnerable applications to MSRC
Feb. 27, 2023 – MSRC starts issuing fixes for said applications
Mar. 20, 2023 – MSRC states that all the reported applications are now fixed
Mar. 28, 2023 – MSRC awards Wiz Research with $40,000 bug bounty
Mar. 29, 2023 – Public disclosure
Stay in touch!
Hi there! We are Hillai Ben-Sasson (@hillai), Shir Tamari (@shirtamari), Nir Ohfeld (@nirohfeld), Sagi Tzadik (@sagitz_) and Ronen Shustin (@ronenshh) from the Wiz Research Team. We are a group of veteran white-hat hackers with a single goal: to make the cloud a safer place for everyone. We primarily focus on finding new attack vectors in the cloud and uncovering isolation issues in cloud vendors.
We would love to hear from you! Feel free to contact us on Twitter or via email: research@wiz.io.
