DEF CON Ten now-fixed bugs in Google’s Quick Share for Windows could have been exploited to wirelessly write new files onto victims’ PCs without their approval, and ultimately execute code remotely on those victims’ machines by chaining together a handful of other vulnerabilities.
SafeBreach security research team lead Or Yair and senior security researcher Shmuel Cohen demonstrated the remote code execution (RCE) attack, dubbed QuickShell, and at DEF CON today discussed the work that went into this project: Namely, probing Quick Share’s communication protocol, fuzzing and then manually searching for vulnerabilities, and eventually creating a full RCE chain.
After sharing their findings with Google, the web giant issued two CVEs in June that cover the 10 Quick Share holes SafeBeach uncovered. Those are CVE-2024-38271, a denial of service flaw that earned a 5.9-out-of-10 CVSS severity rating, and CVE-2024-38272, an authorization bypass bug with a 7.1 CVSS score.
Google has fixed all of the flaws, and SafeBreach confirmed the RCE chain is no longer possible to pull off. Google did not want to comment.
As part of addressing the RCE issue on Windows – which is quite involved and non-trivial to exploit, but very interesting to see play out – Google fixed a bug that allowed attackers to force-push files to nearby Windows and Android devices via Quick Share.
Inside the code
Quick Share, similar to Apple’s AirDrop, is a peer-to-peer file-sharing tool that lets people send and receive files between nearby devices. It uses various communication protocols including Bluetooth, Wi-Fi, Wi-Fi Direct, Web Real-Time Communication (WebRTC), and Near-Field Communication (NFC). Plus, it uses Google’s Nearby Connections API to discover and exchange data with nearby devices.
Quick Share today is the result of Google’s previous AirDrop-like Nearby Share program merging with Samsung’s Quick Share in January this year.
The app is available not just for Android but also Windows, so you can use it to transfer files between mobile devices and PCs. Bear in mind that for two devices, be they phones or computers, to exchange files via Quick Share, both ends must consent to the transfer: The sending user has to offer a file, and the receiver has to accept it via the user interface.
“It’s a pretty complex project to do on Windows,” SafeBreach’s Cohen told The Register. “It involves various communication methods, and the whole thing becomes very complex. And as a security researcher, you always like to look at complex programs or designs, because complex means that it probably will have bugs in there.”
Fuzz’n’logic
After studying the various protocols involved in the file-sharing process, the duo decided to create a fuzzing tool to probe Quick Share for Windows. While this did lead to some reproducible crashes, it didn’t provide them with a hoped-for usefully exploitable bug. It was possible, for example, to repeatedly crash Quick Share on Windows by sharing a file with a filename containing invalid UTF-8 characters, which by itself might be good for pranking someone.
“It did allow us to crash Quick Share,” Yair said of the fuzzing, “and one of them forced Quick Share into endlessly opening a single file in the Downloads folder. So we can name a file in the victim’s download folder, and that will open, close, open, close, repeatedly, the same file, forever.”
Next the researchers moved onto searching for logic vulnerabilities in the code. Quick Share’s communication protocol code “is extremely generic, full of abstract and base classes and a handler class for each packet type,” the two note in a write-up due to be shared in step with their DEF CON presentation today.
As we noted, normally a recipient has to agree on screen in the app to get a file over the air from a sender. Here’s how that exchange is supposed to work under the hood, according to the duo:
However, the code was structured in such a way that it inadvertently allowed the pair to just send a PayloadTransfer packet directly to the app to perform a transfer, skipping the introduction and accept packet stages entirely, and bypassing the need for any acceptance from the responder. The software – both the Windows and Android versions, we note – would just automatically take the file and save it. Miscreants could use this to push data, even highly illegal content, to a target’s device.
This also worked regardless of the discovery mode the app was configured to use – whether the app was visible to everyone or not – and even if the app was configured to only accept files from the user’s contacts. You can watch a demo for this file transfer acceptance bypass below.
SafeBreach’s team also was able to use Quick Share to force a target device to connect to a Wi-Fi network of their choosing for about 30 seconds, after which time Quick Share returned the machine to its original Wi-Fi network. This mechanism is provided so that, if possible, the app can upgrade the connectivity between two devices to speed up file transfer. It allows Quick Share to use Wi-Fi for that transfer rather than a slower wireless protocol.
During that time, an attacker could try to man-in-the-middle the victim’s wireless traffic, though nearly everything is encrypted in transit at the application layer at least these days, and as there was only about 30 seconds to do something nefarious, you may well think this was a dead end.
Next, they did find a path traversal attack that — ironically — was possible to Quick Share’s code responsible for removing path traversal strings. But while this allowed the researcher to create a file outside of the downloads folder, the code required the file name to start with “Downloads” and the file had to always be in the user’s folder. So still no RCE.
By now they had 10 vulnerabilities that could do the following, according to the pair:
The power of creative thinking
“The hardest part was actually not technical at all. It was just pure creativity,” Yair said. “We tried to think: How can we escalate these vulnerabilities into something greater? And we came up with this flow.”
That flow, linking five lesser bugs to achieve RCE, first involved extending the Wi-Fi hijacking attack beyond 30 seconds and keeping the victim’s PC on the attacker-controlled network. They accomplished this by making the victim’s computer join the malicious network, then immediately crashing the app with one of the earlier denial-of-service vulnerabilities, and taking advantage of the fact that Quick Share creates a Windows scheduled task that every 15 minutes checks if the app is running. If it’s not running, the task restarts Quick Share.
So, use Quick Share to make the target join a bad network, crash their Quick Share so it doesn’t flip the user back to the previous network, wait for the scheduled task to start Quick Share anew, and now the attacker has their victim on a persistent attacker-controlled Wi-Fi connection. That miscreant now, in this position, has time to intercept the victim’s internet traffic and meddle with it.
Next for this clever but admittedly involved RCE, the attacker needs to wait for the victim to download (say) an application installer from the internet via the rogue network. Even if this installer program is downloaded using a HTTPS connection, it’s possible for the network eavesdropper to figure out the program the user wants from the hostname of the remote download server. During the unencrypted handshaking at the start of the connection, the server’s full hostname – such as code.visualstudio.com – is visible to the snoop.
To guess the program being fetched, the duo looked at not just the hostname but also how big the download is. If you know, for instance, that a 123MB installer .exe is available from (say) amazingeditor.example.com and you as the Wi-Fi eavesdropper see your victim downloading 123 or so megabytes from that server using their browser, you can bet they’re fetching that installer. The pair explained:
And finally, at just the right moment, the attacker tricks the victim’s Quick Share into overwriting the executable being fetched and saved by the browser to the user’s downloads folder, replacing the legitimate .exe with a malicious one by force-sending a file with the exact same name. It helps that Quick Share and, say, Chrome use the same folder for downloads.
“It will prevent anyone from deleting this file or modifying it,” Cohen said. “So say the [victim’s browser] tries to overwrite our file with the original, let’s say a Spotify installer, it will fail to overwrite our file but it will notify the victim that everything is OK, and Spotify is being downloaded, and you can click here to run it.”
Of course the victim won’t really be running Spotify when they open the program, but rather some malicious code of the attacker’s choosing, and then it’s game over.
Complicated, but do-able, and in any case, now patched. Overall, the team said it found and had Google fix the following:
- Remote Unauthorized File Write in Quick Share for Windows
- Remote Unauthorized File Write in Quick Share for Android
- Remote Forced Wi-Fi Connection in Quick Share for Windows
- Remote Directory Traversal in Quick Share for Windows
- Remote DoS in Quick Share for Windows – Endless Loop
- Remote DoS in Quick Share for Windows – Assert Failure
- Remote DoS in Quick Share for Windows – Assert Failure
- Remote DoS in Quick Share for Windows – Unhandled Exception
- Remote DoS in Quick Share for Windows – Unhandled Exception
- Remote DoS in Quick Share for Windows – Unhandled Exception
SafeBreach says it worked closely with the Chrome maker to resolve the vulnerabilities, and added that the Googlers were cooperative and receptive to their responsible disclosure. We imagine the infosec biz will at some point publish its write-up about this research here, where it hosts its other advisories. ®