QuickShell: Turning Standard Logic Flaws into a Deadly RCE Chain\n\nModern file-sharing applications often trade security for convenience, and Google's Quick Share (formerly Nearby Share) is no exception. At Black Hat Asia, researchers Or Yair and Shmuel Cohen revealed how they successfully bridged the gap between 'minor' logic bugs and a full Remote Code Execution (RCE) chain on Windows. This post dives deep into the QuickShell attack, explaining how a combination of Protobuf fuzzing, Wi-Fi hijacking, and browser download manipulation can compromise a system.\n\n### The Target: Google Quick Share\nGoogle's expansion of Quick Share to Windows marked a significant increase in attack surface. Because the application interacts with low-level networking APIs and handles incoming files from untrusted sources, it presents a unique target for research. The underlying architecture uses the Nearby Connections API, communicating via Protobuf packets and securing sessions with the UKEY2 encryption library. Understanding this protocol was the first hurdle in the research.\n\n### Technical Deep Dive: The Vulnerabilities\n\n#### 1. Bypassing the Handshake\nUnder normal circumstances, Quick Share requires a user to accept a file transfer. However, the researchers discovered that the application's state machine was flawed. By skipping the file introduction packet and sending a payload transfer packet immediately, they could force a file into the Downloads folder without any user interaction or notification. This vulnerability bypassed all visibility settings, including 'Contacts Only' and 'Your Devices.'\n\n#### 2. Rogue Bandwidth Upgrades\nQuick Share attempts to optimize transfer speeds by switching from Bluetooth to Wi-Fi. The researchers found they could force a victim's device to connect to a rogue Wi-Fi access point by sending a malicious bandwidth upgrade request. While Android has mitigations to prevent internet routing through these hotspots, Windows does not, allowing the attacker to become a Man-in-the-Middle (MITM) for all system traffic.\n\n#### 3. Identifying Downloads via SNI and Size\nSince most web traffic is HTTPS, the researchers couldn't see the content of the victim's downloads. However, they utilized two metadata leaks: Server Name Indication (SNI) and Payload Size. By monitoring the domains being accessed (e.g., code.visualstudio.com) and the approximate size of the encrypted stream, they could accurately guess exactly which installer the user was downloading.\n\n### The RCE Chain: The QuickShell Attack\nThe final RCE chain is a masterclass in creative exploitation:\n1. Connect & Crash: The attacker forces the victim to connect to their rogue AP and then crashes the Quick Share service. This prevents the system from reverting to the original Wi-Fi, while a Windows scheduled task ensures the service restarts shortly to continue the attack.\n2. The Hijack: The attacker waits for the victim to download a popular executable. Once the download completes, the attacker holds the final TCP packet to delay the browser's completion notification.\n3. The Swap: The attacker pushes a malicious executable with the same name via the file acceptance bypass.\n4. The File Lock: To prevent Chrome from overwriting the malicious file with the legitimate one, the researchers used a timeout bug to make Quick Share repeatedly open the malicious file, creating a file lock. Chrome, unable to rename its .crdownload file, fails the operation but leaves the attacker's file in the folder.\n5. Execution: The user, seeing a successful download in Chrome, clicks the icon and executes the attacker's malware.\n\n### Mitigation and Defense\nGoogle has since released patches for these vulnerabilities, including CVE-2024-38208, CVE-2024-38209, and CVE-2024-43644. Key defenses implemented include better verification of file IDs and preventing unauthorized bandwidth upgrades. Users should ensure their Quick Share for Windows is updated to the latest version and be wary of unexpected Wi-Fi network switches during file transfers.\n\n### Conclusion\nThe QuickShell research demonstrates that vulnerabilities don't have to be 'impressive' memory corruptions to be critical. By chaining logic flaws—each seemingly minor on its own—the researchers achieved the ultimate goal of RCE. As defenders, this highlights the need to look beyond simple crash logs and consider how intended features can be weaponized in unexpected sequences.