QuickShell: Sharing is Caring About an RCE Attack Chain on Quick Share

QuickShell: Sharing is Caring About an RCE Attack Chain on Quick Share

Speakers: Ora, Security Research Team Lead, SafeBreach; Coin, Primary Contributor

Conference: Black Hat Asia

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

Overview

In this compelling presentation, Ora and Coin from SafeBreach unveiled "QuickShell," a sophisticated remote code execution (RCE) attack chain targeting Google's Quick Share application for Windows. Quick Share, Google's answer to Apple's AirDrop, facilitates seamless file transfers between Android devices and, more recently, Windows computers. The research highlighted in this talk reveals a series of critical vulnerabilities that, when chained together, allow an attacker to achieve RCE on a victim's Windows machine with minimal user interaction, effectively turning seemingly minor flaws into a potent exploit.

The motivation behind targeting Quick Share was multi-faceted. Google's recent expansion of Quick Share to Windows, coupled with announcements at CES 2024 about its pre-installation on leading PC manufacturers' devices, made it an increasingly attractive target. Furthermore, the researchers hypothesized that Google's relatively new foray into implementing diverse communication technologies and APIs on Windows might introduce new vulnerabilities. Despite some of Quick Share's code being open source, prior research on its underlying Nearby Connections API was scarce, outdated, and yielded no CVEs, presenting a ripe opportunity for novel security discoveries. The ultimate goal was ambitious: to achieve the first-ever RCE on Quick Share.

Background

▶ Watch: Introduction and motivation for Quick Share research (0:00)

Quick Share serves as Google's cross-platform solution for local file sharing, mirroring the functionality of Apple's AirDrop. It allows users to quickly and easily exchange files between Android devices and Windows PCs. The application is built upon the Nearby Connections API, a framework designed to enable Android applications to exchange data with nearby devices regardless of network connectivity. This API leverages Protobuff for efficient data serialization and uses the Google U2 library to differentiate between various applications utilizing the API, each identified by a unique service ID. The Nearby Connections API supports multiple connection strategies, including peer-to-peer, star, and cluster topologies, with Quick Share specifically utilizing the peer-to-peer (P2P) strategy for direct device communication.

Understanding Quick Share's proprietary protocol was the initial hurdle for the SafeBreach team. They began by identifying fundamental read and write functions within the base_endpoint_channel class, which process incoming and outgoing bytes. These bytes are parsed into offline frame objects, which serve as the base type for most packets exchanged within Quick Share. To facilitate protocol analysis, the researchers developed quick sniff, a custom tool initially implemented with Windbg and Pydbg, later refined into a DLL. This tool hooked the read and write functions, parsed intercepted bytes into textual offline frame objects, and provided invaluable insight into the protocol's structure during a file transfer session.

A typical Quick Share file transfer session unfolds in several stages:

1. Encryption Handshake: The initiator sends a connection request followed by a UK2 client init packet. The responder replies with a UK2 server init packet, and the initiator concludes with a UK2 client finish packet, successfully exchanging encryption keys to secure subsequent communication.
2. Connection Acceptance: Both devices send a connection response packet, signifying their acceptance of the connection and establishing a connected state.
3. Proprietary Communication: This phase involves Quick Share's specific implementation over the Nearby Connections API, primarily focusing on payload transfer and bandwidth upgrade negotiations.
4. Visibility Mode Enforcement: Both devices exchange paired key encryption and paired key result packets. Through experimentation, the researchers determined these packets enforce Quick Share's device visibility modes (e.g., "everyone," "only contacts," "only devices linked to the same Google account"). All modes, except "your devices," require physical acceptance by the receiver via a file introduction dialogue.
5. File Introduction and Transfer: The initiator sends a file introduction packet with file metadata. The responder is prompted with an acceptance dialogue. Upon acceptance, an accept packet is sent back to the initiator, which then transmits the actual file via a payload transfer packet.

From a user perspective, this involves selecting a recipient, accepting the file prompt on the receiving device, and the file appearing in the downloads folder. This intricate protocol flow, particularly the reliance on user acceptance and visibility modes, became a key area for the researchers to target.

Key Findings

▶ Watch: Introducing 'Quick Sniff' for protocol analysis (3:40)

The research journey began with automated fuzzing of the Quick Share Windows application, employing win AFL for its straightforward infrastructure and Dynamo Rio for instrumentation. To maintain the validity of Protobuff structures while mutating values, the team utilized lib protobuff mutator. Despite being slow and encountering initial obstacles, the fuzzer eventually yielded four reproducible, albeit unexploitable, crashes. More notably, it uncovered a reproducible timeout condition that could force Quick Share into a loop, continuously attempting to open a chosen file from the victim's downloads folder. While not immediately exploitable for RCE, this unique behavior would later prove crucial.

Recognizing the limitations of fuzzing for their ultimate goal, the team shifted to a manual logical vulnerability search, a decision they humorously noted they wished they had made sooner. This approach quickly bore fruit, leading to the discovery of two critical vulnerabilities:

1. File Acceptance Bypass: The researchers questioned Quick Share's complex, multi-threaded architecture. What if the payload transfer packet containing the file data was sent immediately, bypassing the entire file introduction packet and accept packet sequence? This experiment resulted in a complete bypass of the acceptance requirement. An attacker could directly place a file in the victim's downloads folder without any user interaction. Crucially, this bypass also circumvented all device visibility modes, allowing files to be dropped even if the victim's device was set to receive files only from linked Google accounts. This vulnerability was demonstrated by planting a malicious.txt file on a victim's phone configured for "same Google account only" visibility, with no prompt or acceptance required.

1. Forcing Rogue Wi-Fi Connection (Man-in-the-Middle Capability): Quick Share's bandwidth upgrade negotiation feature allows it to switch communication technologies (Wi-Fi, Bluetooth, Wi-Fi Direct, WebRTC) to optimize transfer speed. One such option is to create a Wi-Fi hotspot on one device and provide the other with the SSID and password to connect. While previous research had shown this could be used for a 30-second man-in-the-middle (MITM) attack on Android (sniffing internet traffic), Google had since mitigated this on Android by preventing internet access through such hotspots. However, testing on Windows revealed a critical oversight: **Windows devices still routed their internet traffic through the attacker-controlled Wi-Fi hotspot for approximately 30 seconds.** This provided a temporary but significant MITM capability.

At this point, the researchers had discovered eight distinct vulnerabilities, with the file acceptance bypass being the most critical for placing arbitrary files. However, direct RCE remained elusive. The challenge was to transform these "standard stones"—the ability to write files to a specific folder, brief MITM, crashes, and the file-opening loop—into a "deadly drone" capable of remote code execution.

Technical Deep Dive

▶ Watch: Detailed explanation of Quick Share's encryption handshake (5:00)

The true ingenuity of QuickShell lies in its unconventional assembly of these seemingly disparate vulnerabilities into a cohesive RCE chain. The pivotal insight was realizing that the victim's downloads folder, to which the attacker could write files without approval, is the same location where web browsers save downloaded executables. If an attacker could overwrite a legitimate, user-initiated download with a malicious executable before the user ran it, RCE would be achieved. This required solving two main problems: identifying the name of the downloaded executable and overwriting it reliably.

The first step in building the RCE chain involved extending the limited 30-second MITM window provided by the rogue Wi-Fi vulnerability. A simple yet effective solution emerged: crash Quick Share immediately after the victim connected to the attacker's Wi-Fi hotspot. Quick Share only disconnects from the alternate Wi-Fi network once the file transfer session concludes. By crashing it, the session never formally ends, leading to a forever-lasting Wi-Fi connection and, consequently, an extended MITM window. The impact of the crash on further exploitation was minimal, as Quick Share creates a scheduled task that restarts the application every 15 minutes, ensuring it's available for subsequent attack stages. This established the first two critical links: persistent rogue Wi-Fi connection and Quick Share's eventual restart.

With a stable MITM in place, the next challenge was identifying the names of executables downloaded by the victim's browser. Even though HTTPS encrypts the main content of web traffic, crucial metadata remains visible to a man-in-the-middle. The researchers leveraged two key pieces of information:

1. Server Name Indication (SNI) Extension: The TLS (Transport Layer Security) protocol, which underpins HTTPS, begins with a Client Hello message. This message includes the SNI extension, indicating the domain the client intends to communicate with. This allowed the attacker to determine the specific websites the victim was accessing, even for encrypted traffic.
2. Approximate Size of Data Transfer: While encryption might add padding, the overall approximate size of a downloaded file remains consistent. Executable files are typically significantly larger than other web resources, making large downloads easily identifiable.

By combining the SNI (domain) and the approximate size, the attacker could accurately guess the name of a downloaded file. For example, if 95 MB were downloaded from code.visualstudio.com, it was highly probable that the latest VS Code installer was being downloaded. To further refine this technique, the concept of "domain paths" was introduced. Many download buttons don't directly link to the executable but redirect through several domains (e.g., Notepad++ redirecting from notepad-plus-plus.org to github.com and then to objects.githubusercontent.com). By monitoring the sequence of domains accessed within a limited timeframe until a large download started, the attacker could precisely deduce the exact installer being downloaded. This sophisticated MITM technique formed the third link in the RCE chain, enabling the attacker to detect downloaded executable names.

The final and most intricate step was overwriting the ongoing download with a malicious file. The researchers first analyzed Chrome's download flow:

1. Chrome checks if the target filename already exists in the downloads folder.
2. If it exists, a suffix (N) is added (e.g., installer (1).exe). Otherwise, the original filename is used.
3. The file is downloaded to a temporary file with a .crdownload extension (e.g., installer.exe.crdownload).
4. Upon completion, the .crdownload file is renamed to the decided final name.

The initial idea was to inject a malicious file with the decided final name in the middle of this process, hoping Chrome would fail to rename its .crdownload over it. However, this presented a timing issue: accurately guessing the filename requires knowing the approximate size, which typically means waiting for the download to finish.

The breakthrough came from revisiting the fuzzer's "unexploitable" reproducible timeout vulnerability – the one that forced Quick Share to continuously open a chosen file. The refined attack flow became:

1. The attacker, acting as a MITM, intercepts and holds the last TCP packet of the legitimate download. This signifies to the attacker that the download is complete and the size is known, allowing for precise filename guessing, but the client (Chrome) still perceives the download as ongoing.
2. At this precise moment, the attacker uses the previously discovered file acceptance bypass to send their malicious executable, named identically to the legitimate download, to the victim's downloads folder.
3. Immediately after sending the malicious file, the attacker triggers the fuzzer-discovered reproducible timeout vulnerability, forcing Quick Share into a loop that continuously attempts to open the newly placed malicious file. This action locks the malicious file, making it inaccessible to other processes.
4. The attacker then releases the held TCP packet, allowing Chrome to complete its download. Chrome proceeds to delete its temporary .crdownload file but fails to rename it to the final name because the attacker's malicious file (with that name) is locked by Quick Share.
5. Crucially, Chrome's user interface reports the download as successful. When the victim clicks on the "downloaded" file in Chrome's download window, they inadvertently execute the attacker's malicious payload. This ingenious combination of vulnerabilities finalized the remote code execution chain.

Demo / Proof of Concept

▶ Watch: Discovery: enforcing device visibility modes (7:00)

The culmination of this research was a powerful demonstration of the QuickShell RCE chain. The demo showcased the attack from both the attacker's and victim's perspectives.

First, the attacker's machine was shown, configured as a Wi-Fi hotspot. The custom attack tool was initiated, searching for nearby Quick Share victims and identifying a "Test Machine." Once selected, the victim's device was seen to disconnect from its legitimate Wi-Fi network and connect to the attacker's malicious "Test AP." As designed, Quick Share on the victim's machine crashed, ensuring a persistent MITM connection.

The victim's perspective then illustrated the RCE. The attacker's tool began displaying the domains the victim was accessing via SNI. The victim navigated to the Spotify website, intending to download the latest Spotify installer. The downloads folder was initially empty. As the download commenced, the attacker's process identified the download based on its domain path and size. Upon the download's "completion" (from the victim's perspective, though the malicious file was in place), the victim clicked the downloaded installer. Instead of the legitimate Spotify installer, a popup appeared stating, "You have bonded by Safe Breach Labs," confirming the successful execution of the attacker's payload.

A second example reinforced the attack's reliability, demonstrating the same RCE against a Notepad++ installer download. The victim downloaded the installer, clicked it, and was again greeted by the "Safe Breach Labs" message. This demo vividly illustrated how the chained vulnerabilities could subvert user-initiated actions to deliver an RCE.

Defensive Implications

▶ Watch: Complete Quick Share file transfer protocol flow (8:00)

The SafeBreach team reported their findings to Google, who cooperated fully and issued three CVEs for the vulnerabilities: CVE-2024-22287, CVE-2024-22288, and CVE-2024-22289. While Google's initial fixes addressed most issues, the researchers discovered a few surprises and bypasses, highlighting the iterative nature of vulnerability patching.

One denial-of-service (DoS) vulnerability found by the fuzzer was caused by invalid UTF8 continuation bytes in filenames. The researchers provided an example using a null terminator. Google's initial fix merely verified that filenames did not start with null terminators, overlooking the broader root cause. This specific fix was easily bypassed by using other invalid UTF8 continuation bytes, allowing the remote crash to be re-triggered.

A more significant bypass was found for the critical file acceptance bypass vulnerability. Google's fix involved identifying and deleting "unknown files" from the disk at the end of a file transfer session, rather than preventing their initial write. The researchers hypothesized that these "unknown files" were identified by a specific payload ID. They crafted an attack where two different files (with different names and content) were sent within the same file transfer session, but critically, both were assigned the same payload ID. As a result, Quick Share only deleted one of the "unknown files," leaving the other malicious file on the disk, thus achieving a complete bypass of Google's initial fix. Google subsequently addressed these bypasses, demonstrating their commitment to resolving the reported issues.

Beyond specific patches, this research offers crucial lessons for defenders and software vendors:

• Don't Underestimate "Minor" Bugs: The seemingly "unexploitable" DoS vulnerability that allowed crashing Quick Share, and the 30-second MITM, were not RCEs on their own. However, they were absolutely critical components in establishing the persistent MITM connection, which was foundational to the entire RCE chain. Vendors should avoid dismissing bugs as too minor if they could serve as building blocks in a larger, more complex attack.
• Broader Security Perspective: Focusing solely on common programming mistakes like memory corruption bugs can lead to overlooking significant security risks. The QuickShell attack highlights how logic flaws and even intended application behaviors (like bandwidth upgrade negotiation) can be abused to create devastating attack chains. A holistic security evaluation must consider how different features interact and how their intended functionality might be subverted.
• Input Validation Beyond Content: The UTF8 bypass emphasizes the importance of robust input validation, not just for content but also for metadata like filenames. Incomplete fixes that address specific examples rather than the underlying vulnerability can lead to easy circumvention.

Key Takeaways

• Unconventional Vulnerability Chaining: Even seemingly basic or unimpressive vulnerabilities, when creatively combined, can be transformed into powerful attack chains, demonstrating that "standard stones may sometimes be forged into deadly drones."
• Addressing Minor Issues Mitigates Larger Risks: Bugs perceived as low-severity (e.g., denial of service) can be crucial enablers for much more impactful attacks, underscoring the importance of fixing all known issues, regardless of initial perceived risk.
• Holistic Security Evaluation: Software vendors must adopt a broader security perspective, extending beyond traditional memory corruption bugs to scrutinize logical flaws and how intended features or behaviors might be exploited to introduce security risks.
• HTTPS Metadata is Still Valuable for Attackers: Despite the encryption of HTTPS traffic, crucial metadata like SNI and approximate transfer sizes can be leveraged in MITM scenarios to infer sensitive information, such as the names of downloaded files.
• Complexity Increases Attack Surface: Quick Share's complex, multi-threaded, and asynchronous architecture, combined with its integration of various communication technologies, provided ample opportunities for logical flaws and unexpected interactions to be exploited.

About the Speaker(s)

Ora is the Security Research Team Lead at SafeBreach, bringing over seven years of experience in security research across Linux, embedded, and Android environments. For the past four years at SafeBreach, Ora has primarily focused on Windows vulnerability research and third-party application security. Coin is recognized as a primary contributor to this QuickShell research, sharing credit for the extensive work involved in discovering and chaining these vulnerabilities.