Recon 2025

In our presentation, we unveil a comprehensive security analysis of Google's Quick Share application, formerly known as Nearby Share. Quick Share has facilitated easy file sharing for Android users over the past four years and was extended to Windows platforms a year ago. Google's initiative to preinstall Quick Share on Windows PCs, combined with a noticeable gap in recent security research on the application, and a wide a attack surface, motivated us to investigate its security posture

Our research began with dissecting Quick Share's Protobuf-based protocol. We developed a tool using CDB (the command-line version of WinDbg) and PyKD to hook into the application, allowing us to sniff and analyze the protocol’s packets. Additionally, we created a fuzzer using WinAFL combined with libprotobuf-mutator to automate the testing of Quick Share's handling of the protocol’s messages.

While our fuzzer uncovered several crashes in the Windows application, they seemed non-exploitable. This led us to pivot towards searching for logic vulnerabilities, a decision that yielded significant results. Overall combining the our manual research and fuzzing results, we discovered ten vulnerabilities across both the Windows and Android versions of Quick Share, with an additional 2 vulnerabilities which are bypasses:

1. Remote Unauthorized File Write in Quick Share for Windows - An attacker can place a file in a victim’s Downloads folder without the need for the victim to press “Accept”.
   This can be done even while the victim device is set to receive files only from “Your Devices” or “Contacts” (Vulnerability in the code, not the protocol)
2. Bypass of the fix for the first Remote Unauthorized File Write in Quick Share for Windows
3. Remote Unauthorized File Write in Quick Share for Android- An attacker can place a file without creating any notification in a victim’s Downloads folder without the need for the victim to press “Accept”.
   This can be done even while the victim device is set to receive files only from “Your Devices” or “Contacts” (Vulnerability in the code, not the protocol, the code is not the same as the one in Windows)
4. Remote Forced Wifi Network Connection in Quick Share for Windows - An attacker can force a victim device to upgrade its medium to WIFI_HOTSPOT and connect to the attacker’s Wifi network without the need for the victim to press “Accept”. This can be done even while the victim device is set to receive files only from “Your Devices” or “Contacts”. After a maximum timeout of about a minute, the victim device returns to its original WiFi AP. However, this process can be repeated endlessly. This allows the attacker to become a MITM and manipulate or monitor packets in unencrypted protocols that the victim is using (HTTP, FTP, etc…). If the attacker uses HTTPS, there is still information disclosure since TLS Client Hello packets mention the domain that the victim is trying to access. As apposed to the Quick Share for Android app, the Quick Share for Windows app uses the new WiFi network for internet connection and not just a local connection
5. Remote Directory Traversal in Quick Share for Windows - An attacker can write a file or create a directory in the parent directory of the directory that is configured to be the Downloads directory of the Quick Share app.
   The default case would be writing a file to the “C:\Users\<User>\” Directory. The prefix of the file name or directory name would have to start with “Downloads”, for example - “C:\Users\user\Downloadsfile” (notice missing “\” after “Downloads”)
6. Remote DOS in Quick Share for Windows - An attacker can force the Quick Share app to be stuck in an endless loop which continuously opens a file in the Downloads folder
7. Remote DOS in Quick Share for Windows - An attacker can crash the Quick Share app by sending a file name that starts with a null terminator (or any other byte that is not a valid UTF8 character or a valid UTF8 continuation byte)
8. Bypass of the fix for invalid UTF8 Remote DOS in Quick Share for Windows
9. Remote DOS in Quick Share for Windows - An attacker can crash the Quick Share app by sending a file name such as “…”. This kind of a name leverages the known DOS-to-NT path conversion issue in Windows (MagicDot research - BH Asia 2024), leading Quick Share to open the Downloads folder as a file, which crashes the app
10. Remote DOS in Quick Share for Windows - An attacker can crash the Quick Share app by sending a Quick Share packet of type CONNECTION_REQUEST with an empty “Endpoint ID”
11. Remote DOS in Quick Share for Windows - An attacker can crash the Quick Share app by sending a Quick Share packet of type PayloadTransfer of a file with the “Payload ID” set to “0”
12. Remote DOS in Quick Share for Windows - An attacker can crash the Quick Share app by initiating two connections while the same “nonce” field used in both times in the CONNECTION_REQUEST Quick Share packet and the “version” field of the CONNECTION_RESPONSE Quick Share packet set to "UNKNOWN_VERSION” in both times

Generally, with the 10 vulnerabilities we found, looking at Quick Share for Windows, we had the ability to:

• Place a file in a victim’s Downloads folder without approval (true for the user folder too, but was not useful), even when the victim is set to receive only from “Contacts” or “Your Devices”
• Force a victim to connect to our rogue WiFi AP and connect to the internet through it for about a minute
• Crash Quick Share
• Affect Quick Share to be stuck in an endless loop continuously opening a file

What we were thinking at first was - “If unencrypted communication was the standard, and if we would have the option to keep the victim connected to our rogue WiFi AP at all times, then it would be easy to manipulate sniffed data and affect the victim to run our code”.

However, since encrypted communication is today’s standard, we decided to bridge the gaps and find ways to achieve the same result. We first needed to find a way to make the connection to our rogue WiFi AP last.

The way we solved it was by immediately crashing the Quick Share app after it connected to our AP. Then, the victim device just stays connected, and after a maximum period of 15 minutes, the app starts again by a scheduled task created as part of the installation, and the WiFi connection is still not returned to the original AP.

At this point, we were able to constantly see the TLS/HTTPS traffic of the victim. With that being said, we knew that we can’t manipulate the traffic as it is encrypted. What we did realize is that we can write files to the very same directory where browsers place their downloaded files - the Downloads folder. If we could only guess names of executable files that are being downloaded by browsers and somehow overwrite them with our vulnerabilities, this would lead to Remote Code Execution.

This thought led us to come up with the new MITM HTTPS technique to guess downloaded file names. The technique allows attackers who see the HTTPS traffic of a victim to infer that a specific file is being downloaded with extremely high accuracy. This is how the it works:

Start of MITM technique explanation

An attacker has a dictionary that maps between a domain (or a list of domains) to information about a popular file that can be downloaded from that domain. This way, if the victim has a TLS HTTPS session that downloads data, even if encrypted, the downloaded file name can be guessed based only on the size of the encrypted downloaded data.

For example: In the dictionary, “code.visualstudio.com” points to information about “VSCodeUserSetup.exe” including name, size, etc. Surfing to “code.visualstudio.com” shows a big Download button that downloads the 93.6MB file “VSCodeUserSetup.exe” for Windows users. Therefore, it is extremely easy to guess that a victim downloads “VSCodeUserSetup.exe” when seeing access to “code.visualstudio.com” and a TLS session with at least 93.6MB of data being downloaded (might be a bit bigger because of encryption overhead & padding). The domains accessed by a victim can be seen by a MITM by looking for TLS Client Hello packets and their Server Name extensions.

Potentially, there’s a way to improve accuracy even more if desired. If for example a user that downloads “VSCodeUserSetup.exe” almost always goes through “visualstudio.com” before reaching “code.visualstudio.com”, then the dictionary contains a list of domains instead of one domain for better accuracy. The list would have “visualstudio.com” as the first element and “code.visualstudio.com” as the second. Then the condition for deducting that “VSCodeUserSetup.exe” was downloaded by the victim would be true only if the victim accessed “visualstudio.com”, then after a period of time limited by a timeout, accessed “code.visualstudio.com”, and then downloaded at least 93.6MB of data.
End of MITM technique explanation

So we accomplished our ability to detect names of downloaded files. However, we could not overwrite files, but only create new files. Therefore, we found a way to trick Google Chrome into deleting a successfully downloaded file and instead point to a malicious file with the same name that we placed in the victim’s Downloads folder. To do that, we developed a MITM tool that counts the data that a victim downloads over a single TLS session but holds the last data packet to the victim when it detects that the download was finished. Then, at that moment, while Chrome shows that the download is still ongoing, the tool detects the downloaded file name using the technique we introduced and sends a malicious executable with the same name to the victim’s Downloads folder. At this stage, we applied our ability to force the Quick Share app to continuously open a file on the file we sent.

Lastly, the tool releases the last data packet of the legitimate download and sends it to the victim. Once Chrome finishes the download, it tries to rename the “.crwd” temporary download file to the actual file name of the download but it can’t. That is because the Quick Share app has an open handle to a file with the same name. Eventually, this results in Google Chrome to delete the file it downloaded (the .crwd file) and report that the download was finished successfully. Clicking on the downloaded file in Chrome’s UI, causes our malicious executable to run instead of the legitimate executable.

The presentation we offer will include 3 demo videos:

• Demonstration of the full RCE attack chain showing how a victim downloads benign executables from benign websites (Spotify, Notepad++) and instead of running the benign executables runs a malicious executable from Google Chrome’s UI (downloads window).
• Demonstration of the first vulnerability that allows to send files without authorization
• Demonstration of the new vulnerability that allows to send files without authorization and is a bypass of the previous vulnerability

We created a Google Drive folder with 2 out of the 3 mentioned demo videos (there is one extra video that shows how a normal file transfer session looks like for comparison) - https://drive.google.com/drive/folders/1Qq3xLqW8sbC6dXC6XieGpNdlY3ZZJZO5?usp=sharing

Moreover, we will demonstrate the first vulnerability that allows sending a file without the receiver’s approval. Later on, we will also show another demo video of the new vulnerability that bypasses the fix.

All the vulnerabilities were disclosed to Google. The original vulnerabilities were reported to Google on January 31st. The 10 original vulnerabilities were all fixed and 2 CVEs were issued (CVE-2024-38271 & CVE-2024-38272). ****The new vulnerabilities that allow bypasses for two of the fixes were reported on August 1st, they were both fixed, and Google decided to issue one new CVE - CVE-2024-10668

The tools that we created for this research are described below:

1. QuickShellCommunication - A CPP project that allows to receive and send custom Quick Share packets to Quick Share devices. It contains multiple different tools:
   1. send_file_with_bypass.exe - Allows sending a file to a Quick Share device no matter if “Accept” was not pressed or the target device is set to receive files only from “Your Devices” or “Contacts”.
   2. send_file_with_bypass_after_fix.exe - Same like send_file_with_bypass.exe but bypasses the fix.
   3. force_wifi_connection.exe - Forces the target device (over bluetooth) to connect to the AP with the specified SSID & password and stay connected to it. Done by crashing the Quick Share for Windows app right after the WiFi connection was established.
   4. send_packets.exe - Allows sending a custom sequence of Quick Share packets provided in a file formatted according to our custom format. The format is very simple. It contains the quick share packets in their Protobuf serialized form as used by the normal Quick Share apps. Each packet is prefixed with four bytes that provide its size.
2. QuickShell - A Python project that implements the full Remote Code Execution chain (uses QuickShellCommunication). The tool searches for nearby Quick Share devices and offers the option to execute the chain against one of them. This tool also implements the explained HTTPS MITM technique.
3. pack_packets & parse_packets - A Python project that converts a Quick Share packets file (formatted according to custom format) to YAML files describing each packet textually, or the exact opposite operation (YAML files to a Quick Share packets file).
4. QuickSniff - A DLL project written in CPP that hooks the send & receive functions of the Quick Share Windows app in order to log any received or sent Quick Share packet in its textual key-value form.

These are the takeaways that we will present summarizing the session:

1. Standard stones may sometimes be forged into deadly drones - If you find vulnerabilities that don’t seem too impactful on their own or applicable for something greater, try to practice creative thinking to discover unconventional attack vectors that can be conquered by chaining the vulnerabilities. In our case, we managed to come up with a very unconventional attack vector (tricking a browser into falsely reporting a successful executable download to run our code remotely). Revealing this attack vector was extremely effective for leveraging the vulnerabilities to maximize their impact potential.
2. Turning to the defensive side - It's crucial for vendors and organizations not to underestimate seemingly simple bugs or known issues. When combined with other vulnerabilities or primitives, their impact can escalate significantly. Therefore, thorough evaluation and mitigation of even seemingly minor issues are essential to overall system security, and can potentially break impactful attack chains.
3. Our research emphasizes the importance of not fixating solely on memory corruption and fuzzing techniques when examining a program's security. While these methods are valuable, they may not always reveal exploitable vulnerabilities. By shifting focus to logical vulnerabilities, researchers can uncover overlooked issues that may ultimately lead to significant exploits.

For your convenience, we also created a presentation outline for the offered session:
First Slide - QuickShell: Sharing is caring about an RCE attack chain on Quick Share - The story of how we found a novel RCE attack chain in Quick Share

1. Speakers Introduction
2. Agenda
3. Why Quick Share?
   1. Press releases about Google introducing a new Quick Share app for Windows
   2. Various communication methods between devices, so many attack surfaces
   3. No other Google apps utilize such communication methods on Windows - Since as far as we know it’s Google’s first time using such APIs on Windows, it could be a place for errors
   4. No relevant research about Quick Share since 2019 (and only on Android)
   5. Some of the code is open source
   6. Destined to be pre-installed on Windows computers (mentioned by Google). Thus, vulnerabilities in Quick Share will affect Windows’ security in the future
4. Nearby Github Repo - Contains some of the code of Quick Share for Windows
   1. Finding the communication functions - send & receive
   2. Discovering that the protocol is Protobuf-based and finding the relevant protobuf files in the repo
   3. Creating an automatic tool with CDB (Windbg without UI) & Pykd to sniff the protocol’s packets and understand how it works
5. Protocol Overview
   1. Protobuf based protocol
   2. Analyzing the sequence of packets sent during a file transfer between two devices
      1. CONNECTION_REQUEST
      2. CONNECTION_RESPONSE
      3. Validation of the “Who can share with you” setting - Enforces “Contacts” and “Your Devices” modes
         1. PAYLOAD_TRANSFER of type PAIRED_KEY_ENCRYPTION
         2. PAYLOAD_TRANSFER of type PAIRED_KEY_RESULT
      4. PAYLOAD_TRANSFER of type INTRODUCTION - A type of PAYLOAD_TRANSFER packet meant to introduce a file and notify the receiver about an intention to send a file, waiting for approval from the receiver
      5. PAYLOAD_TRANSFER of type FILE- A type of a PAYLOAD_TRANSFER packet that sends the actual file to the receiver
      6. Optional (sometimes happens) - BANDWIDTH_UPGRADE_NEGOTIATION - Moving between various communication methods to improve transmission speed (providing SSID & password, MAC addresses, frequencies, etc…) and safely closing the prior connection only when the new one is fully established
6. Fuzzer Creation & Execution
   1. Infrastructure - WinAFL + libprotobuf-mutator
   2. Hooks and modifications to Quick Share for Windows to accept files automatically and more
   3. Stateless to stateful - How we fuzzed a Quick Share session instead of one Quick Share packet. We created our own format containing packets for an entire session and made WinAFL fuzz each one of the packets separately
   4. Successfully improving Quick Share’s speed. Unfortunately, it was too fast for the fuzzer with DynamoRio, creating a race condition leading to false crashes
   5. Discovered Crashes Overview - Not Exploitable
7. What we achieved so far and where we are aiming next - Moving to logical vulnerability search
8. File Transfer Acceptance Bypass
   1. Google’s design for handling different packet types - A handler for each type of packet
   2. Google’s code is filled with thread creations for many different tasks
   3. Conclusion - Let’s try to send a PAYLOAD_TRANSFER packet with the actual file straight away without introducing the file first. Maybe the handler will just be called and serve its purpose
   4. Worked! Sending to Quick Share for Windows & Android without the need for acceptance by the receiver and no matter if its mode is set to “Your Devices”/”Contacts”/”Everyone”
9. Forcing a WiFi connection
   1. BANDWIDTH_UPGRADE_NEGOTIATION of type WIFI_HOTSPOT - Moving to communicate over a suggested WiFi AP (Access Point), providing SSID, password, frequency, IP, and port to connect
   2. Past research in 2019 found Android devices to be vulnerable to an attack forcing them to transfer all internet communication through a rogue WiFi AP. Google today mitigates the risk and prevents Android devices from having an internet connection through such an AP (An AP that is the current AP of the device as a result of a BANDWIDTH_UPGRADE_NEGOTIATION)
   3. This mitigation does not exist on Windows! We can force a Windows machine with Quick Share to connect to our AP and see its traffic (returns to the original AP after about a minute)
10. Additional Crashes Found Explained (by our logical search)
11. Another result from the fuzzer - Causing Quick Share on Windows to continuously open a file in the Downloads folder in an endless loop
12. Still no RCE, What can we do?
    1. General Abilities We Have
       1. Place a file in a victim’s Downloads folder without approval (true for the user folder too, but was not useful), even when the victim is set to receive only from “Contacts” or “Your Devices”
       2. Force a victim to connect to our rogue WiFi AP and connect to the internet through it for about a minute
       3. Crash Quick Share
       4. Affect Quick Share to be stuck in an endless loop continuously opening a file
    2. Since encrypted traffic is the standard, forcing a victim to connect to our AP and manipulating its traffic does not lead to a generic RCE. However, let’s try to bridge the gaps anyway and start by making the WiFi connection last
13. Crashing the app right after a WiFi connection was forced - Affects the connection to last and Quick Share is later run by a scheduled task after 0-15 minutes
14. Crucial Insight - Quick Share and browsers place downloaded files in the same folder - the Downloads folder

15. If we could:

    • Know downloaded executable file names once they are downloaded
    • Overwrite files (and not just create new ones)

    Then this would lead to an RCE (Since we could potentially overwrite an executable downloaded file, leading a victim to run our executable instead)

16. New MITM technique for guessing popular executable file names during a download

    1. Monitoring accessed domains by looking at Server Name extensions in TLS Client Hello Packets
    2. Mapping domains (or a sequence of domains) to popular executables downloaded from the internet
    3. Counting TLS session data to determine which file is downloaded
17. What’s left? We need to overwrite the downloaded executable, but we still don’t have this ability
18. Instead of Overwriting - Trick Google Chrome
    1. As the MITM for the victim machine, hold the last packet of the download so the download won’t be finished
    2. Then, send a malicious executable with the same name using Quick Share
    3. Force the victim’s Quick Share app to open our sent file continuously, so it won’t be able to be deleted
    4. Chrome is not able to delete it and instead deletes its own temporary “.crwd” download file when it tries to rename it to the actual file name
    5. RCE!
19. Full RCE Chain Demo
20. Vulnerability Fixes & Bypasses
    1. File acceptance auth bypass - fix bypass - Instead of not creating unauthorized files in the first place, Quick Share creates them and then deletes them. To bypass the fix, we send the same packets that we sent for the original vulnerability. But, instead of sending one Payload Transfer packet of type File, we send two, with the same ID and different file names. As a result, Quick Share creates two files on the disk, but thinks that there’s only one unauthorized file that was sent and needs to be deleted. The result is that one of the files that we sent is left on the disk.
    2. Remote DoS - fix bypass - Even though we did report this vulnerability as one that is caused by invalid UTF-8 continuation bytes of file names that are provided in file transfers, the example that we provided is a file name that starts with NULL (which triggers the same exception). Google added only a check for null terminators instead of checking for a valid UTF-8 string
21. Takeaways
22. CVEs & Google’s Response
23. GitHub + Q&A

Finally, if you want a deeper technical read into this research, we invite you to read the full research paper - https://drive.google.com/file/d/1-4hLHDbaeRwshXyluMYwn9nznt-iC9xU/view?usp=drive_link