Flaws in how 17 models of headphones and speakers use Google’s one-tap Fast Pair Bluetooth protocol have left devices open to eavesdroppers and stalkers.
Link to see devices impacted: https://whisperpair.eu/
Flaws in how 17 models of headphones and speakers use Google’s one-tap Fast Pair Bluetooth protocol have left devices open to eavesdroppers and stalkers.
Link to see devices impacted: https://whisperpair.eu/
But you need to be in close proximity (~15m max) to stalk a victim? You might as well just follow them around physically then. Perhaps when the victim is in a private location, eavesdrop on their conversation or locating their position within there, might be a possibility. But ear raping would, of course, constitute the most significant danger of all. Also WhisperPair, not WhisPair?
If you want to listen to their mic via bluetooth or whatever, yes. But there’s also this:
This already severely limits the pool of potential victims; but still a more practical exploit indeed. It’s almost as if this BLE tracking is a feature, rather than an exploit. And if you want to be notified of a device following you around, one has to perpetually enable BLE on their smartphone. But of course, headphone jacks are a thing of the past, and wireless is clearly the future. :)
By all means call out if I’ve misunderstood, but the tracking vulnerability isn’t that BLE (by design) makes devices visible to everyone within range, it’s that by binding an unclaimed device to an account you gain the ability to look up that device via Google’s service, rather than needing to be nearby - you can simply ask Google to call on its global network to find “your” device. In other words, there’s nothing stopping me from setting an alert when a given BT device is nearby, that’s spot on, but I can’t fire up Google to look up that device when I’m not nearby, or look up its location history.
And yes needing to have never been connected to an Android device definitely reduces the victim pool, but (and to address the other reply) I’m guessing it’d mean devices that have only ever been connected to iOS, Linux, Windows etc aren’t “claimed” and can still be enrolled by the attacker. It’s not about default creds, only having used devices that don’t enrol with Google is enough, as it leaves the device available to claim.
3.5mm ftw and all that, but I doubt all the parents of teenagers with potentially vulnerable devices will have much luck convincing their kids to switch!
I understand you’ve read the comment as a single thing, mainly because it is. However, the BLE part is an additional piece of critique, which is not directly related to this specific exploit; neither is the tangent on the headphone jack “substitution”. It’s, indeed, this fast pairing feature, which is the subject of the discussed exploit; so you understood that correctly (or I misunderstood it too…).
I’m however of the opinion, BLE being a major attack vector, by design. These are IoT devices that, especially when “find my device” is enabled (which in many cases isn’t even optional: “turned off” iPhones for example), do announce themselves periodically to the surrounding mesh, allowing for the precise location of these devices; and therefore also the persons carrying them. If bad actors gain access, to for example Google’s Sensorvault (legally in the case of state-actors), or would find ways of building such databases themselves; then I’d argue you’re in serious waters. Is it a convenient feature, to help one relocate lost devices? Yes. But this nice-to-have, also comes with this serious downside, which I believe doesn’t even near justify the means. Rob Braxman has a decent video about the subject if you’re interested.
It’s not even a case of kids not wanting to switch, most devices don’t even come with 3.5mm jacks anymore…
That’s literally any device. Goes all the way back to things like people setting up routers and not changing the default password so anyone else can get in. That’s just user error plain and simple.