Year of the Bounty Desktop: Bugs From Binaries

Year of the Bounty Desktop: Bugs From Binaries

Speakers: Parsia Hakimian, Microsoft

Conference: Bug Bounty Village

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

Overview

In "Year of the Bounty Desktop: Bugs From Binaries," Parsia Hakimian of Microsoft challenges the conventional focus of bug bounty hunting, urging researchers to look beyond traditional web applications and explore the often-overlooked attack surface of desktop applications. While many bug bounty programs explicitly deem desktop applications out of scope, Hakimian demonstrates that these applications frequently interact with in-scope backend endpoints and present unique vulnerabilities that can lead to high-impact findings, including remote code execution (RCE). The talk provides practical methodologies, tool recommendations, and real-world examples from his own research, highlighting how to identify, exploit, and chain vulnerabilities in desktop software.

Hakimian's presentation serves as a compelling case for diversifying bug hunting strategies. He illustrates how desktop applications, by their very nature, introduce complex inter-process communication (IPC) mechanisms, custom protocol handlers, and local services that can be exploited. Through detailed technical breakdowns of vulnerabilities found in applications ranging from Burp Suite's AI features to PlayStation Now and Visual Studio Code, he reveals how seemingly minor issues can escalate into critical security flaws when chained together. The talk emphasizes that patience, binary analysis, and an understanding of client-side interaction models are paramount to uncovering these hidden gems.

The significance of this talk lies in its ability to demystify desktop application security research for bug bounty hunters. By providing concrete examples and actionable advice, Hakimian empowers researchers to expand their scope and discover vulnerabilities in a domain often left unexplored. His insights into methods like proxying desktop app traffic, decompiling binaries, and understanding web-to-app communication protocols offer a roadmap for those looking to pivot or add desktop security to their repertoire, ultimately leading to more impactful bug reports and a more secure software ecosystem.

Background

▶ Watch: Introduction: Desktop apps in bug bounty scope (0:00)

The landscape of bug bounty hunting has historically been dominated by web applications. Researchers typically focus on HTTP/HTTPS traffic, server-side logic, and common web vulnerabilities like XSS, SQLi, and authentication bypasses. This narrow focus often stems from clear program scopes that explicitly define web services and associated APIs as targets, while desktop applications are frequently categorized as "out of scope." This creates a perception that investing time in desktop application analysis is unproductive for bounty hunters.

However, Hakimian argues that this perspective misses a critical point: while the desktop application itself might be out of scope, the endpoints it communicates with are almost always in scope. Furthermore, desktop applications, especially those designed for seamless user experience, often employ complex communication mechanisms that introduce new classes of vulnerabilities not found in purely web-based environments. These include custom protocol handlers that allow browsers to launch applications, and local HTTP or WebSocket servers used for inter-process communication (IPC).

Prior work in this domain, particularly regarding web-to-app communication, has laid some foundational understanding. Hakimian specifically references a series of blogs by Eric Lawrence, a member of the Edge team and the creator of Fiddler, whom he considers a leading expert on web-to-app communication. Hakimian also points to his own 2020 talk, which covered many basic concepts. The problem, as Hakimian highlights, is that despite these resources, the specific vulnerabilities and chaining techniques he discusses are often novel and require a deeper dive into the application's internal workings, moving beyond surface-level network traffic analysis. His motivation for exploring this space was a desire to escape the "burnout" of repeatedly hunting for the same types of web vulnerabilities, seeking new challenges and attack surfaces.

Key Findings

▶ Watch: How to proxy Burp AI: certificate challenges (3:30)

Parsia Hakimian's research into desktop application vulnerabilities yielded several key findings that challenge conventional bug bounty hunting wisdom and expose significant attack vectors:

• Desktop Apps as Gateways to In-Scope Endpoints: Even when desktop applications are technically "out of scope," they frequently interact with backend APIs and services that are in scope. Intercepting and analyzing this traffic can reveal vulnerabilities in the backend, or in the application's handling of data from those endpoints.
• The Power of Chaining Simple Vulnerabilities: Isolated, low-severity issues like open redirects or local file overwrites often gain critical importance when chained together. Hakimian repeatedly demonstrates how combining multiple seemingly benign flaws can lead to remote code execution (RCE) or other high-impact outcomes.
• Web-to-App Communication is a Critical Attack Surface: Mechanisms designed for seamless integration between web browsers and desktop applications (e.g., custom protocol handlers, local HTTP/WebSocket servers) are prone to security oversights. These interfaces often fail to implement robust validation or origin checks, making them susceptible to manipulation by malicious websites.
• Binary Analysis is Essential: Relying solely on network traffic is insufficient. Decompiling application binaries using tools like Ghidra or NSpy is crucial for understanding internal logic, discovering hidden functionalities, and identifying internal API routes or configuration settings that are not exposed through external documentation or network requests.
• Insecure Defaults in Frameworks: Frameworks like Electron, while powerful for cross-platform development, historically had insecure default settings (e.g., nodeIntegration: true). These defaults, when unaddressed in older or poorly configured applications, can transform client-side scripting into RCE.
• Don't Report Prematurely: A significant lesson learned is to resist the urge to immediately report a "first-stage" vulnerability (e.g., becoming an admin, open redirect, local file overwrite). Instead, these should be used as stepping stones to discover more impactful vulnerabilities, maximizing the bounty and demonstrating a deeper understanding of the system's weaknesses.

Technical Deep Dive

▶ Watch: Deep dive into Burp AI's agentic functionality (6:00)

Hakimian's talk provides a comprehensive technical exploration of desktop application vulnerabilities, moving from initial traffic interception to binary analysis and sophisticated exploit chaining.

Proxying Desktop Application Traffic: The Burp Suite AI Example

A fundamental step in analyzing any application is to intercept its network traffic. For desktop applications, this often involves configuring a proxy like Burp Suite. However, Hakimian encountered a specific challenge with Burp Suite's own AI features, which communicate with ai.portswigger.net. When attempting to proxy this traffic through a second instance of Burp, he observed SSL certificate errors.

The root cause was that Burp Suite, being a Java application, ships with its own Java Runtime Environment (JRE) and, consequently, its own Certificate Authority (CA) store. This means that adding the Burp CA certificate to the system's certificate store is insufficient for applications using their bundled JRE.

Solution:

To overcome this, Hakimian used the keytool utility, which is part of the JRE. The keytool command allows management of Java keystores and truststores. By using keytool -importcert -file <burp_ca.der> -keystore <jre_path>/lib/security/cacerts -alias burp, he was able to add Burp's CA certificate directly into the JRE's cacerts file. The caveat, as he notes, is that this process needs to be repeated after every Burp Suite update, as upgrades often overwrite the JRE.

Impact:

With traffic successfully intercepted, Hakimian could analyze the communication between the Burp client and the Burp AI proxy. He discovered that Burp's "Explore issue" and "AI login recorder" features were sending sensitive context (issue details, request/response, page screenshots, element text, interactability) to the AI service. Crucially, the AI was acting as an agentic AI, sending commands back to the Burp client (e.g., "send this request to repeater," "click on this," "insert this"). This revealed that the AI functionality was essentially a sophisticated proxy, not directly interacting with OpenAI or similar services. This deeper understanding allowed him to devise a method to reroute all Burp AI traffic to his own OpenAI-compatible endpoint, effectively "leaking" and manipulating the prompts used by Burp's AI.

Hidden WSDL and Admin Promotion

In another scenario, Hakimian analyzed a desktop application and discovered a hidden WSDL (Web Services Description Language) endpoint. WSDL, often associated with SOAP web services, describes the functionality offered by a web service, similar to how an OpenAPI specification describes a REST API, but using XML instead of JSON.

By interacting with this undocumented WSDL endpoint, he found a vulnerability that allowed him to promote an existing user to an administrator role and even change a user's password to an empty or single-character string. His initial mistake was reporting these findings individually, which resulted in a lower bounty ($1500) and a quick patch.

Lesson Learned:

Hakimian emphasized a critical lesson from his past in game and console hacking: when you gain privileged access (like becoming an admin), don't report it immediately. Instead, use that access to explore further. In this case, being an admin could have allowed him to discover more severe vulnerabilities, such as creating multiple administrators or finding XSS payloads in user profiles that could lead to broader impact.

Binary Analysis with Ghidra and Go mux

To understand the internal workings of desktop applications, especially those that run local services, binary analysis is indispensable. Hakimian highlighted Ghidra, a free and open-source reverse engineering tool from the NSA, as his primary choice for decompiling binaries into readable C code.

He demonstrated this by analyzing a local application that used Go mux, a popular HTTP router for Go applications. By decompiling the Go binary, he could identify all defined HTTP routes and their associated handler functions. Instead of manually sifting through the code, he used a simple regular expression to extract all strings between double quotes, which efficiently revealed all the application's internal routes. This technique is invaluable for discovering undocumented API endpoints or hidden functionalities exposed by local services.

Web-to-App Communication: Protocol Handlers

One of the most common and often vulnerable mechanisms for web-to-app communication is through protocol handlers. These allow web browsers to launch desktop applications when a specific URL scheme is encountered (e.g., mailto:, ftp:, apphandler:).

Discovery:

Hakimian recommended two key resources: Eric Lawrence's blog series on web-to-app communication and NirSoft's URL Protocol View tool. The latter can enumerate all registered protocol handlers on a Windows machine, revealing the associated application and how parameters are passed to it. He observed a test VM with 140 protocol handlers, many of which passed parameters directly to the application executable.

Vulnerability Chaining Example:

He discovered a vulnerability in a .NET application. Using NSpy (a .NET assembly editor and decompiler), he uncovered a hidden switch in the decompiled code, undocumented but present. This switch, when passed via the protocol handler, allowed the application to take two XML parameters: a remote script source and a local output file path.

• Stage 1: The app could fetch a remote file (the script source) from the internet and write its contents to any local file on the user's machine, provided the user had write access to that path. This, by itself, is a local file overwrite, similar in impact to an open redirect – not high-severity on its own.
• Stage 2 (Argot's Trick): To escalate this, Hakimian leveraged a technique by researcher Argot: overwriting a HTML Application (HTA) file. HTA files are essentially HTML files that can execute arbitrary script (like VBScript or JScript) with local system privileges, often used for helper applications. They are highly permissive in format, allowing for embedded garbage data while still executing valid scripts.
• Stage 3 (RCE): By crafting a malicious HTA file (e.g., calc.hta) that included a script to pop calc.exe, and then using the file overwrite vulnerability to place this HTA file in the Windows startup folder (e.g., C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup), he achieved remote code execution on the next system reboot or user login.
• Username Bypass: A challenge was determining the user's specific username for the startup folder path (%USERPROFILE%). Standard environment variables are often encoded by browsers or rejected by applications when passed via protocol handlers. Argot's clever solution was to target the Administrator's startup folder (C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup), as every Windows machine has an Administrator account. This provided a reliable path for RCE, albeit for a less common user.

Web-to-App Communication: Local HTTP/WebSocket Servers

Many modern desktop applications, especially those built with frameworks like Electron or CEF (Chromium Embedded Framework), run local HTTP or WebSocket servers for Inter-Process Communication (IPC). This enables seamless interaction between different parts of the application or with the browser.

Zoom Example:

Hakimian cited the well-known Zoom vulnerability (discovered by Jonathan). Zoom installed a local HTTP handler. When a user clicked a Zoom meeting link, the browser would contact this local HTTP server, which would then launch the Zoom app and join the meeting without any user prompt. A critical flaw was that this local HTTP server often remained active even after the Zoom application was uninstalled, leading to a persistent reinstallation vulnerability.

PlayStation Now Example (Chaining for RCE):

Hakimian's first bounty in this area involved PlayStation Now, a streaming application built with a combination of Electron (for the UI) and Qt (a C++ framework for backend logic).

• Initial Discovery: He found that PlayStation Now ran a local WebSocket server on port 3219.
• Same-Origin Policy (SOP) Bypass: Crucially, while the browser's Same-Origin Policy generally restricts JavaScript from one origin from reading resources from another, WebSockets are not strictly bound by SOP for connection initiation. This meant that any malicious JavaScript running in a user's browser could establish a connection to the local PlayStation Now WebSocket server.
• Vulnerability 1 (Open Redirect): The WebSocket messages contained commands, including one that instructed the Electron app to navigate to a specified URL. This effectively created an open redirect within the Electron application – a low-severity bug on its own.
• Vulnerability 2 (Electron nodeIntegration): The Electron framework, in its older versions, had a default setting called nodeIntegration set to true. When nodeIntegration is enabled, JavaScript running within the Electron app's browser window can directly access Node.js APIs, including the ability to spawn child processes (e.g., require('child_process').exec('calc.exe')).
• Chaining for RCE: The full exploit chain was:

1. A user visits a malicious website.
2. Malicious JavaScript on the website connects to the local PlayStation Now WebSocket server (bypassing SOP for WebSocket connection).
3. The JavaScript sends a command via the WebSocket to the Electron app, instructing it to navigate to a URL controlled by the attacker (the open redirect).
4. This attacker-controlled URL serves a web page containing malicious JavaScript.
5. Because nodeIntegration is true in the vulnerable Electron app, this malicious JavaScript can execute arbitrary Node.js commands, leading to Remote Code Execution (e.g., popping calc.exe).

This chain earned him $15,000.

Visual Studio Code WSL Remote Example:

Hakimian applied similar logic to Visual Studio Code's WSL Remote extension. This extension allows users to develop in a Linux environment within WSL while using the VS Code GUI on Windows. The communication between the Windows GUI and the WSL server also uses a WebSocket.

• Vulnerability: A malicious website could connect to this local WebSocket and send commands to the VS Code instance. One such command could create an instance of Node Inspector, a Node.js debugger.
• Impact: Attaching to a debugger instance inherently grants remote code execution, as debuggers provide facilities to execute code in the target process.
• Bounty Outcome: Despite the clear RCE, this bug received a bounty of zero from MSRC, highlighting the sometimes inconsistent nature of bounty programs.

Demo / Proof of Concept

▶ Watch: Rerouting Burp AI traffic to your own AI (7:00)

Parsia Hakimian demonstrated the real-world impact of these chained vulnerabilities through two distinct proof-of-concept scenarios, highlighting the critical nature of desktop application security.

The first demonstration involved the PlayStation Now application. The scenario began with the user running PlayStation Now on their machine. The attacker's vector was a malicious website. When the user navigated to this website in their browser, the site's embedded JavaScript initiated a connection to the local WebSocket server running within the PlayStation Now application. Leveraging the discovered "navigate to URL" command and the nodeIntegration: true setting in the Electron component, the malicious JavaScript instructed the PlayStation Now app to open an attacker-controlled web page. This page, loaded within the Electron context, then executed Node.js API calls to spawn calc.exe, resulting in the Calculator application popping up on the user's screen. The speaker described this as "anticlimactic" visually, but underscored its profound security implications, demonstrating full remote code execution initiated from a web page.

The second demonstration, though not visually shown in the same detail due to the talk's time constraints and its "zero bounty" outcome, conceptually replicated the RCE on Visual Studio Code's WSL Remote extension. In this scenario, a user running VS Code with the WSL Remote extension would again visit a malicious website. The website's script would then establish a connection to the local WebSocket server that facilitates communication between the Windows VS Code GUI and the WSL backend. Through this WebSocket, the attacker's script could force the VS Code instance to create and attach to a Node Inspector (debugger) instance. As attaching to a debugger inherently grants control over the debugged process, this would lead to remote code execution within the context of Visual Studio Code. While the immediate visual might be less dramatic than calc.exe popping up, the ability to execute arbitrary code within a development environment like VS Code presents an extremely high-severity security risk.

Defensive Implications

▶ Watch: Vulnerability example: Hidden WSDL for admin promotion (7:50)

The research presented by Parsia Hakimian offers critical insights for developers, security engineers, and users regarding the security of desktop applications.

For Developers and Security Engineers:

1. Strict Input Validation for Protocol Handlers: All data passed via custom protocol handlers must be treated as untrusted input. Implement rigorous sanitization, encoding, and whitelist-based validation to prevent command injection, path traversal, or unexpected behavior. Avoid directly concatenating user-supplied input into file paths or command-line arguments.
2. Secure IPC for Local Services: Applications using local HTTP or WebSocket servers for Inter-Process Communication (IPC) must implement robust security controls.

• Origin Checks: For WebSockets, strictly validate the Origin header to ensure only trusted web pages can connect.
• Authentication/Authorization: Implement authentication mechanisms for local services, even if they're only intended for local access. This could involve unique tokens, API keys, or OS-level access controls.
• Strict Message Validation: Validate the structure and content of all messages received by local services. Avoid exposing overly powerful commands or functions.

1. Electron/CEF Best Practices:

• Disable nodeIntegration: The nodeIntegration setting in Electron should always be set to false unless absolutely necessary, and if so, only for trusted, isolated contexts. This is the default in newer Electron versions, but older applications or custom configurations must be checked.
• contextIsolation: Enable contextIsolation to prevent malicious scripts in the renderer process from accessing Node.js primitives or Electron APIs exposed in the preload script.
• Sandbox Renderer Processes: Utilize Electron's sandbox capabilities to limit the privileges of renderer processes.
• IPC Communication: Use secure IPC channels for communication between the main and renderer processes, ensuring all messages are validated and sanitized.

1. Binary Hardening and Obfuscation: While not foolproof, obfuscating binaries and removing unnecessary symbols can make reverse engineering more challenging for attackers.
2. Comprehensive Uninstallation: Ensure that application uninstallers thoroughly remove all components, including local HTTP/WebSocket servers, protocol handler registrations, and configuration files, to prevent lingering vulnerabilities (as seen in the Zoom example).
3. Avoid Custom CA Stores: When bundling a JRE or similar runtime, avoid custom CA stores if possible. If necessary, ensure that the bundled CA store is regularly updated and only contains necessary, trusted certificates.
4. Threat Modeling Desktop Interactions: Conduct thorough threat modeling specifically for web-to-app communication flows and local IPC mechanisms. Consider how a malicious website or a compromised local process could interact with the application.

For Users and System Administrators:

1. Keep Software Updated: Regularly update all desktop applications and operating systems. Vulnerabilities like the nodeIntegration issue in Electron are often patched in newer versions.
2. Exercise Caution with Links: Be wary of clicking on links that automatically launch desktop applications, especially if they come from untrusted sources or unexpected contexts.
3. Monitor for Unusual Activity: Be vigilant for unexpected application launches, process executions (like calc.exe), or network connections originating from desktop applications.
4. Least Privilege: Run applications with the least necessary privileges. If an application requires administrative access, understand why and consider alternatives if possible.

By adopting these defensive strategies, organizations and users can significantly mitigate the risks posed by vulnerabilities in desktop applications, closing attack vectors that are often overlooked in the pursuit of web-based bounties.

Key Takeaways

• Desktop applications are a rich, often overlooked, attack surface for bug bounty hunters, offering unique vulnerabilities distinct from traditional web applications.
• Chaining seemingly low-impact vulnerabilities (e.g., open redirects, local file overwrites) is crucial for escalating to high-severity issues like Remote Code Execution (RCE).
• Web-to-app communication mechanisms, such as custom protocol handlers and local HTTP/WebSocket servers, are common sources of critical bugs due to insufficient input validation and origin checks.
• Binary analysis tools like Ghidra and NSpy are indispensable for understanding application internals, discovering hidden functionalities, and identifying internal API endpoints not visible through network traffic alone.
• Don't report low-severity findings prematurely; use them as stepping stones to uncover deeper, more impactful vulnerabilities and maximize bounty potential.
• Insecure defaults in application frameworks (e.g., Electron's nodeIntegration: true) can lead to RCE when not explicitly disabled or properly configured, highlighting the importance of secure development practices.

About the Speaker(s)

Parsia Hakimian is a security researcher currently working at Microsoft. He describes himself as an independent researcher, with much of his disclosed work stemming from his personal investigations before joining his current employer. Hakimian has a background in game and console hacking, which has instilled in him a philosophy of deep exploration rather than immediate reporting of initial findings. He is a seasoned speaker at DEF CON, having presented in 2018 (his first ever talk), virtually in 2020, and again in 2023. His talks often reflect his passion for uncovering overlooked vulnerabilities and his desire to challenge conventional security research methodologies. He explicitly states his motivation for exploring desktop applications stems from a personal desire to avoid "burnout" from repetitive web application bug hunting, finding the complexities of desktop security research "fun" and intellectually stimulating.