Last August, I shared a blog on my most recent research project with Shmuel Cohen called QuickShell: Sharing Is Caring about an RCE Attack Chain on Quick Share, which we initially presented at DEF CON 32 (2024). In it, we explained how we discovered 10 unique vulnerabilities in Google’s Quick Share data transfer utility, some of which we were able to assemble into an innovative remote code execution (RCE) attack chain against the Windows version. 

Google issued two CVEs and fixed all of the vulnerabilities discovered in our original research. As a follow-up, we set out to verify the implemented fixes and explore whether they would sufficiently prevent attackers from exploiting the Quick Share utility. We discovered issues with two of the fixes, one of which was for a critical vulnerability that allowed us to send a file directly to a Quick Share user’s device without their approval. 

Below, I’ll first provide a high-level overview of the original QuickShell research. Next, I’ll show how we discovered the fix issues and were able to bypass the file transfer acceptance. Finally, I will highlight the vendor response and the research implications.

QuickShell Background

NOTE: This section provides an overview of the original QuickShell: Sharing Is Caring about an RCE Attack Chain on Quick Share; readers familiar with it can skip to the following section. 

Google’s Quick Share is a peer–to-peer data-transfer utility for Android, Windows, and Chrome operating systems. It uses a variety of communication protocols—including Bluetooth, Wi-Fi, Wi-Fi Direct, Web real-time communication (WebRTC), and near-field communication (NFC)—to send files between compatible devices that are in close proximity to each other. 

While sending files from device to device sounds like an easy task in theory, it can be quite complex. We couldn’t help but wonder about the potential bugs that might be hiding in the Windows version, given this was Google’s first foray into developing a native Windows application that supports so many communication protocols and includes significant functionality outside its core competency of web services. Much of the application code for Quick Share for Windows is also in an open-source repository and the app may be pre-installed on many new Windows PCs in the near future, two additional reasons it may be an attractive target for malicious actors. 

Armed with this information, we set out to inspect the specific application-layer communication protocol implemented by the Quick Share application to support file transfers between nearby, compatible devices. By investigating how the protocol works, we were able to fuzz and identify logic within the Quick Share application for Windows that we could manipulate or bypass. As a result, we discovered 10 unique vulnerabilities that we were able to assemble into an innovative and unconventional RCE attack chain that allowed us to run code on Windows computers with Quick Share installed. 

The vulnerabilities included: 

1. Remote Unauthorized File Write in Quick Share for Windows
2. Remote Unauthorized File Write in Quick Share for Android
3. Remote Forced Wi-Fi Connection in Quick Share for Windows
4. Remote Directory Traversal in Quick Share for Windows
5. Remote DoS in Quick Share for Windows – Endless Loop
6. Remote DoS in Quick Share for Windows – Assert Failure
7. Remote DoS in Quick Share for Windows – Assert Failure
8. Remote DoS in Quick Share for Windows – Unhandled Exception
9. Remote DoS in Quick Share for Windows – Unhandled Exception
10. Remote DoS in Quick Share for Windows – Unhandled Exception

In line with SafeBreach’s commitment to responsible disclosure, we notified Google of our research findings in January 2024. Google issued two CVEs—CVE-2024-38271 and CVE-2024-38272—and fixed all of the vulnerabilities we identified.

Verifying the Google Fixes

In our follow-on research, we set out to verify the fixes implemented by Google in response to our original research and explore whether they would sufficiently prevent attackers from exploiting the Quick Share utility. While most of the vulnerabilities were indeed fixed properly, we encountered two surprises.

Fix for Remote DoS Vulnerability

First, we discovered that one of the Remote DoS vulnerabilities in Quick Share for Windows that triggered an unhandled exception was not fixed correctly. This initial vulnerability caused Quick Share to crash if a sent file name contained characters that were invalid UTF8 continuation bytes. The example that we provided to Google in the original research report was a file name that started with a null terminator (”\x00”). This example led Quick Share to crash with an exception clearly stating “Invalid UTF8 continuation byte.”

To fix this vulnerability, Google added code that verifies that file names do not start with specifically null terminators:

This fact, combined with the real root cause, led us to the conclusion that we could still exploit this vulnerability by using a file name that contains a different invalid UTF8 continuation byte. For example: “\xc5\xffFileName”.

Fix for Remote Unauthorized File Write Vulnerability

Second, we discovered we could bypass the fix for the Remote Unauthorized File Write in Quick Share for Windows vulnerability (CVE-2024-38272 – Auth Bypass in Quick Share). This was the critical vulnerability we initially discovered that allowed us to bypass the need for a file-transfer acceptance from the Quick Share user and instead send a file directly to their device without approval. This was true for all visibility modes, regardless of whether the target device was set to receive files from everyone, contacts, or “Your Devices.”

The fix addressed the issue by still having Quick Share write the files we sent using our original exploit, but delete them when the file transfer session was over. Google identified our files as “Unknown Files”:

This demo shows the Google fix in action. 

Since the “Unknown File” we sent would be written to disk but later deleted, we were curious how Quick Share would handle it if we sent two files in the same session. We were even more interested to see what would happen if we set the same “payload ID” for each of the files we sent in the same file transfer session. Our assumption was that it might confuse Quick Share into thinking that there was only one “Unknown File” to delete.

Upon inspecting the code that was inserted to fix the original vulnerability, our hypothesis was confirmed. We saw that there was only one file added to the “UnknownFilePathsToDelete” list in each session per a payload ID. So, we ran the exact same exploit that we ran for the original vulnerability, but instead sent two PayloadTransfer packets of type FILE. We set different file names and contents for the two packets, but set the payload IDs to be the same. That worked perfectly! As a result, Quick Share wrote the two files to the disk, but deleted just one, leaving one in the Downloads folder. We had successfully bypassed the fix and discovered another critical vulnerability.

This demo shows the bypass in action.

Vendor Response 

We reported our findings to Google in August 2024. They fixed each of the vulnerabilities and issued a CVE for the bypass we discovered: CVE-2024-10668.

Conclusion  

While this research is specific to the Quick Share utility, we believe the implications are relevant to the software industry as a whole and suggest that even when code is complex, vendors should always address the real root cause of vulnerabilities that they fix. For example, in this case, the root cause of the critical vulnerability we noted here was the fact that received files should not have been written to disk in the first place—this was not addressed by the initial fix. 

To ensure protection against these latest vulnerabilities, we recommend users ensure their Quick Share version is updated to 1.0.2002.2.

For more in-depth information about this research, please: 

• Contact your customer success representative if you are a current SafeBreach customer
• Schedule a one-on-one discussion with a SafeBreach expert
• Contact Kesselring PR for media inquiries 

About the Researcher

Or Yair is a security research professional with more than six years of experience, currently serving as the Security Research Team Lead for SafeBreach Labs. Or started his professional career in the Israel Defense Force (IDF). His primary focus lies in vulnerabilities in Windows operating system’s components, though his past work also included research of Linux kernel components and some Android components. Or’s research is driven by innovation and a commitment to challenging conventional thinking. He enjoys contradicting assumptions and considers creativity a key skill for research. Or has already presented his vulnerability and security research discoveries internationally at conferences such as Black Hat USA, Europe, and Asia, DEF CON, SecTor, RSAC, Troopers, BlueHatIL, Security Fest, CONFidence, and more.