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: Or Yair, Security Research Team Lead, SafeBreach

Conference: REcon 2025

YouTube: https://www.youtube.com/watch?v=yF_MkHk-phQ

Overview

Google's Quick Share — the AirDrop equivalent for Android and Windows — turned out to harbor a chain of vulnerabilities serious enough to achieve unauthenticated remote code execution on a victim's Windows machine. In this REcon 2025 talk, Or Yair and his colleague Cohen from SafeBreach walked through how they reverse-engineered Quick Share's Protobuf-based protocol, built custom tooling to communicate with Quick Share devices, ran a protocol fuzzer, and ultimately chained eight distinct vulnerabilities into a full end-to-end RCE attack that required no interaction from the target beyond normal software use.

The research was motivated by Google's aggressive push to pre-install Quick Share on Windows PCs through partnerships with manufacturers like LG, announced at CES 2024. A large, pre-installed attack surface with minimal prior research and a first-time Windows implementation was an obvious target for scrutiny.

Background

▶ Watch: Introduction: Quick Share file transfer protocol overview (1:07)

Quick Share (formerly Nearby Share) is Google's proximity-based file transfer solution, analogous to Apple's AirDrop. For four years it has existed on Android; a Windows version arrived roughly a year before this research. The application leverages multiple transport technologies — Wi-Fi Direct, Wi-Fi Hotspot, Bluetooth, WebRTC, and NFC — all managed through an underlying API called the Nearby Connections API.

Prior security research on Nearby Connections API had been conducted exclusively on Android, had not produced any CVEs, and predated the Windows client entirely. Additionally, much of Quick Share's code is available in open-source repositories, providing a useful starting point.

The research team had a clear primary goal: find the first remote code execution vulnerability in Quick Share for Windows.

Protocol Architecture

Before attempting any exploitation, the researchers needed to understand Quick Share's undocumented protocol. Their first step was to locate the fundamental send and receive functions — specifically, the read and write methods belonging to a class called BaseEndpointChannel, which serves as the base class for all transport-layer communication handlers.

Each received packet is deserialized into an OfflineFrame — a Protobuf object that acts as the envelope for essentially all Quick Share communication. To instrument this, the team wrote a tool called QuickSniff: a DLL injected into the Quick Share Windows process that hooks the read and write functions, deserializes every packet into an OfflineFrame, and prints it textually for analysis.

A Quick Share session follows this sequence:

1. Connection Request → initiator opens the channel
2. UK2 Client Init / Server Init / Client Finish → Ukey2 cryptographic handshake establishing encryption (using Google's Ukey2 library)
3. Connection Response → both devices signal acceptance
4. Paired Key Encryption → proprietary packets (inside PayloadTransfer) enforcing device visibility modes
5. File Introduction → metadata about the file being sent
6. Accept → responder approves the transfer
7. PayloadTransfer → the raw file data

Device visibility modes control which devices may send files: _Everyone_, _Contacts_ (only Google contacts), or _Your Devices_ (only devices linked to the same Google account).

Key Findings

▶ Watch: Attack surface: forcing Wi-Fi connection via rogue AP (20:59)

The team ultimately discovered eight vulnerabilities across Quick Share's Windows implementation. The most significant findings that fed into the RCE chain were:

1. File Acceptance Bypass (CVE disclosed): Sending a PayloadTransfer packet containing the raw file immediately — without the FileIntroduction / Accept handshake — successfully writes the file to the victim's Downloads folder, bypassing user consent and all device visibility mode restrictions.

1. Forced Wi-Fi Connection to Rogue Access Point: Quick Share supports a Wi-Fi Hotspot bandwidth upgrade, in which one device sends an SSID and password and the other connects to it. On Windows, when the victim device connects to the attacker's rogue Wi-Fi hotspot, it routes all internet traffic through that connection. Unlike the Android implementation (which Google had already mitigated), Windows honors the hotspot for internet traffic, enabling full man-in-the-middle interception.

1. Multiple Reproducible Crashes: The WinAFL-based fuzzer (using DynamoRIO for instrumentation and libprotobuf-mutator for structure-aware mutation) found four reproducible crashes. While not directly exploitable in isolation, they became critical components in the attack chain.

1. Reproducible Timeout / Continuous File Lock: The fuzzer identified a logic flaw in the path where Quick Share checks whether a file about to be received already exists in the Downloads folder. A crafted packet forces Quick Share into a state where it continuously opens a specified file from the Downloads folder in an endless loop — effectively keeping a file handle permanently open.

Technical Deep Dive

▶ Watch: Critical finding: persistent Wi-Fi connection hijack (28:45)

Fuzzing Infrastructure

The fuzzing setup used WinAFL with DynamoRIO instrumentation. To avoid breaking the Protobuf wire format, the team used libprotobuf-mutator, which mutates only the semantic fields of the structure. Each fuzzing iteration covered an entire Quick Share session — approximately ten packets — with one randomly selected packet mutated per iteration. While throughput was low, it was sufficient to produce actionable results.

From Business Logic to an RCE Chain

Rather than continuing to refine the fuzzer, the team pivoted to hunting business logic vulnerabilities. This pivot proved immediately fruitful.

Link 1 & 2: Persistent Man-in-the-Middle

The Wi-Fi hotspot bandwidth upgrade causes Quick Share to disconnect from the current Wi-Fi network and join the attacker-controlled access point. On Windows this lasts at most 30 seconds before Quick Share reconnects to the original network.

To make the connection permanent, the researchers simply crashed Quick Share immediately after the victim connected to their rogue AP. Quick Share does not restore the original Wi-Fi connection if it crashes. Furthermore, Quick Share's installer creates a scheduled task that runs every 15 minutes to check whether Quick Share is running and restarts it if not — meaning Quick Share will relaunch within 15 minutes, but the Wi-Fi connection remains on the attacker's AP indefinitely.

Result: the attacker gains a permanent man-in-the-middle position with full visibility of the victim's internet traffic.

Link 3: Identifying Downloaded Executables via Metadata

Despite HTTPS encryption, two metadata elements leak enough information to identify what the victim is downloading:

• Server Name Indication (SNI): The TLS ClientHello message contains the destination domain in plaintext, even over an encrypted connection. As the MITM, the attacker sees all domains the victim visits.
• Transfer Size: A file download typically occupies a single TCP session. The approximate byte count transferred from server to client closely matches the file's actual size, because encryption adds only modest padding.

The team constructed domain path mappings: sequences of domains visited in the course of downloading specific installers. For example, downloading Notepad++ involves a redirect chain from notepad-plus-plus.org → github.com → objects.githubusercontent.com. By tracking the full domain sequence and the total bytes transferred, the attacker can confidently identify the specific installer being downloaded — e.g., if a victim visits code.visualstudio.com and downloads ~95 MB, the conclusion is VS Code Setup.exe.

Link 4: File Overwrite via File Acceptance Bypass + Continuous File Lock

Chrome's download process works as follows:

1. At download start, Chrome determines the final filename (checking for duplicates in Downloads).
2. Chrome writes the download to a .crdownload temporary file.
3. On completion, Chrome renames the temporary file to the final filename.

The attack idea: send a malicious file with the same name as the expected final filename just before Chrome performs the rename. The researchers accomplished this by intercepting the last TCP segment of the download at the MITM layer — holding it back so that Chrome has not yet renamed the file — and then immediately sending their malicious file using the File Acceptance Bypass to place it in the victim's Downloads folder with the target filename.

Naively, Chrome simply overwrites the malicious file when it finally renames its download. The critical final piece was the Continuous File Lock vulnerability: immediately after placing the malicious file, the attacker exploits Quick Share's reproducible timeout to force Quick Share to continuously open that exact file. With the file perpetually held open by Quick Share, Chrome cannot overwrite it.

The result: Chrome's download process reports success in its UI, the .crdownload temporary file is deleted, but the malicious executable remains in the Downloads folder under the correct name. When the user clicks the completed download in Chrome's downloads window, they execute the attacker's code.

Demo / Proof of Concept

▶ Watch: Vulnerability: path traversal via domain-chained file transfers (34:14)

The researchers demonstrated the complete RCE chain live in two scenarios using real-world installers:

Spotify installer: The attacker sets up a hotspot, finds the victim (a machine called "test machine"), forces it to connect to the rogue AP, and immediately crashes Quick Share. The victim's PC routes traffic through the attacker. When the victim browses to Spotify's website and downloads the installer, the attacker intercepts the download, identifies it by domain and size, withholds the final TCP packet, places a malicious executable named SpotifySetup.exe, and locks it with the timeout exploit. Chrome completes the "download" and the malicious binary runs.

Notepad++ installer: Identical technique, demonstrating that multi-hop redirects (through GitHub's CDN) can still be tracked by following the full domain path chain.

Both demos culminated in the attacker's payload executing on the victim machine, displaying a "you've been pwned by SafeBreach Labs" message.

Defensive Implications

▶ Watch: Escalating the attack: achieving code execution via Chrome (39:31)

Google patched the reported vulnerabilities. The researchers disclosed responsibly and published a GitHub repository with their tooling and proof-of-concept code.

For defenders and users:

• Keep Quick Share updated. The patched versions fix the file acceptance bypass and the Wi-Fi connection persistence issues.
• Download software from official stores or package managers where possible, reducing reliance on browser downloads to the filesystem.
• Be suspicious of unexpected Wi-Fi network changes. An abrupt disconnection from a known network followed by connection to an unfamiliar AP may signal an active attack.
• Monitor scheduled tasks for unexpected entries, particularly those that auto-restart applications with broad network access.
• HTTPS metadata is not fully opaque. SNI and transfer size remain visible even to MITM attackers. Applications that need to conceal download identities should consider ESNI/ECH and padding.

From a software engineering standpoint, the research highlights the risks of:

• Implicit trust in protocol sequence. Quick Share assumed that the accept handshake would always precede the file payload; violating that assumption had no server-side enforcement.
• Unchecked cross-concern interactions. Bandwidth upgrade negotiation, crash recovery, and file-write operations were designed independently and combined into an exploitable chain.
• Generic, thread-heavy, asynchronous code. The complexity of Quick Share's internals made it difficult to reason about race conditions and state machine invariants.

Key Takeaways

• Google Quick Share for Windows contained at least eight vulnerabilities discovered in a single research engagement, including a complete unauthenticated RCE chain requiring no victim interaction beyond using a browser.
• Business logic vulnerabilities can be more immediately rewarding than fuzzing alone. The team found their most impactful bugs within days of pivoting away from the fuzzer.
• Protocol sequence enforcement must be server-side. A file transfer application that trusts the client to follow the handshake before sending data has a fundamental design flaw.
• Chaining low/medium severity bugs into critical impact is a powerful research and attacker strategy. None of the individual bugs — file bypass, MITM, crash, file lock — constituted a standalone RCE; the chain did.
• HTTPS metadata leaks (SNI + transfer size) enable precise identification of downloaded software by a network-level attacker, a capability that carries significant practical implications.

About the Speaker(s)

▶ Watch: Patch analysis: unexpected surprises in Google's fix (44:39)

Or Yair is the Security Research Team Lead at SafeBreach, with more than seven years of experience in security research. His background spans Linux, embedded systems, and Android environments; for the past four-plus years his primary focus has been vulnerability research on Windows. The QuickShell research was conducted jointly with his colleague Cohen, who was an equal contributor to all phases of the project.