BingBang: How A Simple Developer Mistake Could Have Led To Bing.com Takeover
This blog provides a high-level overview of the vulnerability and its impact. For a technical deep dive, please refer to our technical blog.
Introduction
Wiz Research has identified a new attack vector in Azure Active Directory (AAD) that compromised Microsoft’s Bing.com. The attack vector is based on a common AAD misconfiguration, exposing misconfigured apps to unauthorized access.
The researchers found several Microsoft applications vulnerable to this attack, one of which was a Content Management System (CMS) that powers Bing.com. This allowed them to take over Bing.com functionality, modify search results, and potentially enable the Office 365 credential theft of millions of Bing users. These credentials in turn granted access to users’ private emails and documents.
Wiz Research named this attack “#BingBang.” The exploitation of the vulnerability was simple and didn’t require a single line of code.
All issues were responsibly disclosed to Microsoft upon discovery. Microsoft rapidly fixed its vulnerable applications and modified some AAD functionality to reduce customer exposure.
To check whether your environment has been affected, please refer to the “Customer Remediation Guidelines” section of our technical blog.
BingBang attack flow
Part 1: Logging in to a sensitive Bing.com interface
As part of Wiz Research efforts to investigate novel cloud risks and attack vectors (e.g. ChaosDB, OMIGOD, etc.), our researchers examined Azure Active Directory and discovered a risky configuration.
What is Azure Active Directory?
Azure Active Directory (AAD) is a cloud-based identity and access management service. AAD is the most common authentication mechanism for apps created in Azure App Services or Azure Functions. You might be familiar with the AAD sign-in page:
What risky configuration did Wiz Research discover in AAD?
AAD provides different types of account access: single-tenant, multi-tenant, personal accounts, or a combination of the latter two. A multi-tenant app allows logins from any user belonging to any Azure tenant. In a multi-tenant app, it is the developer’s responsibility to check the user’s original tenant and provision access accordingly. If they do not properly validate this information, any Azure user in the world could log in to the app.
This Shared Responsibility architecture is not always clear to developers, and as a result, validation and configuration mistakes are quite prevalent.
Discovering the vulnerable Bing application
After recognizing these issues and their potential impact, the researchers started scanning for vulnerable applications (multi-tenant apps lacking proper validation) on the internet. The results were shocking – approximately 25% of the multi-tenant apps they scanned were vulnerable.
Most surprisingly, the list included an app made by Microsoft itself, named “Bing Trivia.”
Because this app was misconfigured, the researchers were able to log in to it with their own Azure user. They then found a Content Management System (CMS) linked to Bing.com.
Part 2: Modifying Bing.com search results
To verify that this CMS was indeed controlling Bing’s live results, they selected a keyword in the CMS and temporarily altered its content. They chose the “best soundtracks” search query, which returned a list of highly recommended movie soundtracks.
They then proceeded to change the first result, “Dune (2021),” to their personal favorite, “Hackers (1995),” and pushed it to production. Their new result, complete with their title, thumbnail, and arbitrary link, immediately appeared on Bing.com:
This proved that they could control arbitrary search results on Bing.com. A malicious actor landing on the Bing Trivia app page could therefore have tampered with any search term and launched misinformation campaigns, as well as phished and impersonated other websites.
Part 3: Stealing Office 365 credentials from Bing users
After Wiz researchers realized they could modify Bing.com, they decided to test Cross-Site Scripting (XSS) viability.
What is a Cross-Site Scripting (XSS) attack?
Cross-Site Scripting (XSS) attacks are a type of injection in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code to an end user through the website.
The researchers added a harmless XSS payload to Bing.com and saw that it ran as expected, so they quickly reverted their changes and immediately reported their findings to Microsoft.
While working with Microsoft on the report, the researchers started investigating the impact of the XSS they found, and discovered they could utilize it to compromise the Office 365 token of any Bing user.
Bing and Office 365 are integrated: Bing has a “Work” section that allows users to search their Office 365 data. To implement this functionality, Bing communicates with Office 365 on the logged-in user’s behalf. Using this same feature, the researchers crafted an XSS payload that stole Office 365 access tokens from users:
With a stolen token, a potential attacker could access Bing users’ Office 365 data, including Outlook emails, calendars, Teams messages, SharePoint documents, and OneDrive files. The tests were limited to the researcher’s own user; no tests were performed on other Bing.com users.
A malicious actor with the same access could’ve hijacked the most popular search results with the same payload and leaked the sensitive data of 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.
BingBang attack flow
Takeaways – the challenges of securing cloud applications
The cloud accelerates innovation via the flexibility of its infrastructure. This speed also brings changes and new risks. In this case, with only the click of a button, a user can accidentally expose a sensitive service to the internet.
In light of that risk, the Bing vulnerability we have discovered is a reminder that a simple developer mistake can have critical implications, potentially disrupting one of the world’s most popular websites – one of the internet’s key pillars.
As cloud builders, the agility with which we operate makes us prone to mistakes, which is why we should anticipate the next inevitable incident. Our resilience as security teams is dependent on how we catch and mitigate those mistakes. The prevention of accidental exposure should be a key pillar of any cloud security program:
-
Rapid detection – how quickly can you detect and monitor a new public endpoint in your organization?
-
Clear guardrails – how do you differentiate intended from accidental exposure? Guidelines should be clearly defined for approved exposure so that it can be properly configured and protected. Anything else should be considered accidental.
-
Adaptive automation – Is the detection and validation of your attack surface automated to keep up with the pace of changes in the cloud?
For specific mitigation steps for this type of exposure and further technical details you can refer to the technical blog.
We welcome your questions and feedback! Email us at research@wiz.io.
READ MORE HERE