AirDrop & Quick Share: Proximity DoS and Bypass Mechanics
Just caught the latest research on the six vulnerabilities affecting Apple's AirDrop and Google's Quick Share. It's a stark reminder that our wireless attack surface is often wider than we think. The researchers demonstrated that an attacker within radio range—armed with just a laptop and a standard wireless card—can trigger a DoS condition on a target device set to receive from 'Everyone.'
From a technical standpoint, this impacts the service discovery mechanisms. On macOS/iOS, this likely targets the awdd (Apple Wireless Direct Link) or sharingd processes. The ability to crash the service without user interaction suggests a buffer overflow or logic flaw in the packet handling of the initial handshake. The 'bypass checks' mentioned are even more concerning, as they imply an attacker might force a pairing or file transfer prompt that shouldn't appear under strict settings.
For those managing Apple fleets, you can verify if your devices are vulnerable by checking if the service is active and listening:
# Check if Sharingd (AirDrop daemon) is running
pgrep -l Sharingd
# Check current AirDrop discovery setting
defaults read com.apple.sharingd DiscoverableMode
While 'Contacts Only' is the standard advice, if these bypasses hold true, MDM policies forcing AirDrop to 'Off' in high-security zones might be the only safe play.
How is everyone handling this? Are you disabling proximity sharing entirely now, or is the convenience trade-off still worth the risk in your environment?
This is why we forced 'Contacts Only' via MDM years ago, but if there's a bypass for that setting, we might need to go nuclear and disable it completely.
For SysAdmins needing a quick PowerShell check to ensure AirDrop is disabled on Windows machines using Quick Share (via Phone Link), you can run:
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\CloudContent' -Name 'DisableWindowsConsumerFeatures'
Though honestly, the best defense here is physical security. If an attacker is within 10 meters with a malicious laptop, you have bigger problems than file sharing.
From a pentester's perspective, these 'proximity DoS' flaws are gold for causing distractions during physical engagement. If we can crash the sharing services on a victim's phone, we can divert their attention while we drop a USB rubber ducky or attempt a relay attack.
I wouldn't be surprised if we see a Metasploit module dropped soon that automates the malformed packet injection. If you are at a conference, just turn Bluetooth off entirely. The convenience of AirDrop isn't worth getting owned because you wanted a meme sent to you.
Interesting timing. We've seen spikes in sharingd crashes in our JAMF logs recently but attributed them to unstable beta builds. This news suggests we might have been seeing active probing or instability caused by these exploit attempts.
We are deploying a restrictions profile to block AirDrop for all users in the building. The command line check you posted is useful, but for bulk analysis of logs, we're using:
log show --predicate 'process == "Sharingd" AND eventMessage CONTAINS "error"' --last 1d
Recommend everyone check their logs for similar anomalies.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access