CVE-2024-9956 – PassKey Account Takeover in All Mobile Browsers
mastersplinter.work
mastersplinter.work
Safari: fixed in 18.3 (Jan 2025)
Firefox: fixed in 136 (March 2025)
Chrome: fixed in 130.0.6723.58/.59 (Oct 2024)
Wow - only Google seemed to really prioritize fixing this / had the processes and manpower to get a fix out quickly.
Mozilla’s bug report is still locked down but Google’s is open: https://issues.chromium.org/issues/370482421
I would have guessed they'd be the quickest, but I wouldn't have guessed they'd be months ahead of the others.
but it's not public, perhaps someone can tell us when it was opened.
https://learn.microsoft.com/en-us/deployedge/microsoft-edge-...
https://msrc.microsoft.com/update-guide/en-US/vulnerability/...
To me it seems that WebauthN/PassKey was a significant project where all of the clever and highly paid engineers from the big corporations took part.
How can they overlook such an attack vector? Especially when the main selling point for the new technology is "resistance against phishing"?
Even MS has in their FAQ: Are "Q: passkeys phishing resistant? A: Yes, passkeys are phishing resistant" [1]
[1] https://support.microsoft.com/en-us/windows/passkeys-frequen...
Because secure engineering is extremely hard? That's two really quite uncharitable replies from you in this topic now, and IMHO it's really unwarranted. One of the worst smells for secure engineering is the insistence of the people involved that they'd never make a dumb mistake like "that other" group did.
Basically nowhere is humility more of an asset than in this world.
Compare this with passwords, where the protocol is fundamentally phishable, with partial mitigations requiring user discipline (e.g. only ever using password manager auto-fill) and a lack of local or remote vulnerabilities.
This is a "I'm going to phish a very specific person's wallet in meatspace" attack, not a "I'm going to remotely phish anyone on the internet's wallet".
(It's also an attack we've already got mitigations rolled out in major browsers and more planned.)
Because the whole process is design-by-committee on crack, the solutions don't tend to be technically very good. But they don't need to be, because they're not trying to solve a technical problem, they're trying to solve a business problem.
The solutions they come up with are always ugly and broken at first, and don't account for all the needs of everyone (remember, only the most important's needs get met first), so they eventually churn out a fixed version and that becomes the version everyone ends up using long term.
WebAuthn/Passkeys/FIDO/etc aren't even one solution or standard. They're a cobbled together patchwork of different pre-existing standards with some extra pixie dust mixed in. Almost everyone agrees that the users and implementers are who loses out when these things are pushed. But a couple giant businesses have an easier time solving their problems, which are large-scale security problems. And all the rest of us use it, because we tend to defer to large powerful authority figures, and we don't know what the hell else to do.
Whatever universal solution is pushed will continue to suck balls, because there are too many different use cases, and no single solution will ever work well for all of them.
What has worked, is working, and will continue to work, is to simply support a variety of different security mechanisms independently, and allow users to install a password manager which wrangles it all for them, across different use cases, sites, applications, devices, organizations, etc.
> Passkeys are like digital keys ...
But Joe User doesn't yet know what a "digital key" is, not yet anyway, so this is at best a forward reference.
> The public key is registered with the website or application.
Joe has no idea what "registered" means in this context.
The passkey is being compared to a digital version of a physical key, the brass object used to unlock doors.
Phishing resistant is different than phishing proof.
Passkeys remain phishing resistant, even in light of such an attack.
Can today's "water resistant" smartphone be dropped into a swimming pool with no ill effects? I don't know. But "resistance" as a marketing term is often far overblown, even with strict product standards in place, and for cryptography/authentication there is zero consumer protection or transparency.
Any accountability for service providers is usually lip service anyway. Read your software licenses: there are no warranties, for any purpose, ever.
The problem here is that browsers allow redirecting users to the installed passkey implementation/"backend" in the same way that camera and dedicated QR scanner apps legitimately use to initiate cross-device authentication via (what used to be called) caBLE, right?
In other words, the attacker primes the user for an upcoming authentication on-device authentication, but in reality initiates an off-device authentication to their own device.
And the fix is presumably to not accept off-device authentication intents over anything that's not a QR scan, or at least filter them out in the browser?
It was a little rough at first, but support is pretty good now. The only real concern is I don't know how to export passkeys out of 1Password if that were needed.
That'd make it a non-starter for me.
Bluetooth was a mistake.
How so? Unless you grant Bluetooth permissions to apps (that then start broadcasting identifiers) or explicitly make your device discoverable, this shouldn't really be a thing.
> What's the point of leaving it on all the time when most of the time it's just going to drain your battery and open you up to being tracked or exploited.
Just people with a wearable have at least one Bluetooth device connected to their phone at all times. Bluetooth headphones are also very popular.
We need hardened and privacy-protecting Bluetooth stacks, not blaming people for using their phones as designed and advertised.
https://www.nytimes.com/2013/07/15/business/attention-shoppe...
In what way is a modern Bluetooth device (let's assume both classic and LE) uniquely identifiable, other than for the caveats mentioned above? 2013 was indeed over a decade ago.
https://www.geoplugin.com/resources/geofencing-beacons-advan...
https://www.rfidjournal.com/news/long-range-ble-transmits-at...
https://easytechsolver.com/what-stores-use-bluetooth-beacons...
https://www.nytimes.com/interactive/2019/06/14/opinion/bluet...
> We need hardened and privacy-protecting Bluetooth stacks, not blaming people for using their phones as designed
Phones are explicitly designed to collect and leak as much of your personal data as possible. Nobody us going to implement hardened bluetooth stacks that protect you because that defeats the whole purpose. We're lucky they allow us to disable bluetooth at all. They've already changed airplane mode to continue using wireless and bluetooth even when enabled. Any useful features of bluetooth you might use with your phone is probably just bait to get to leak more of your data. They've removed headphone jacks to force your hand, but most people could at least make sure that bluetooth isn't enabled while it isn't in active use.
What benefit would phone manufacturers have from their devices being trackable via Bluetooth, or if it's not themselves, who is paying them for it?
Also, I'd love to see an answer to my original question: How exactly do you track a stock iPhone or Pixel with Bluetooth enabled? Neither transmit a persistent identifier, and none of the technologies linked change anything about that. They require explicit cooperation of an app on the device side, which is gated behind a prompt on both iOS and Android.
Your last link actually suggests the opposite: Bluetooth beacons allow apps to position themselves more accurately indoors and then do with that information whatever they want – if you grant that permission in the first place.
In Google's case, they use bluetooth to track the location of android users and the bluetooth devices near them. In addition to data collection, it helps their "Find my Device" network. I suspect Apple's system also uses bluetooth to identify nearby apple devices and beacons.
Obviously phone manufactures are primarily self-interested, but part of that also means offering extensive data collection opportunities to third parties such as app and accessory developers to attract people to their platform.
> Also, I'd love to see an answer to my original question: How exactly do you track a stock iPhone or Pixel with Bluetooth enabled?
While I don't have a pixel or an iphone, it does appear that there are ways to passively track these devices via bluetooth:
https://www.theregister.com/2021/10/22/bluetooth_tracking_de...
https://cec.gmu.edu/news/2025-02/find-my-hacker-how-apples-n...
Yes, these services being enabled by default isn't great, but if you're claiming that there's any data collection or intentional device broadcasting happening beyond that, i.e. at the base OS level, I'd be happy to see evidence of that (as I would also find that very concerning).
Regarding antenna/transmission chain/baseband fingerprinting: These are indeed concerning, and I hope there will be countermeasures available at some point. But these should theoretically affect all radio technologies, right? In that case, turning off (just) Bluetooth would not help much, given that phones have at least one other permanently enabled radio. It's a different story for devices that have only Bluetooth, of course.
Also according to my experience there is no "permission for bluetooth", it all falls under "Phone" or whatever other permission on Android.
Such a (by definition unidirectional) Bluetooth LE advertisement can easily be received and relayed over arbitrary distances.
https://chromium-review.googlesource.com/c/chromium/src/+/59...
Edit: QR code scans are actually allowed to open such links.
(It doesn't entirely solve it, you can be extremely unlucky with a radio bounce or a surprisingly quiet Bluetooth radio band at transmission time. Surprising because Bluetooth is somewhat intentionally in one of the noisiest radio bands we've allowed to be extremely noisy.)
And even then you'll quickly run into problems when the attacker's receiver has better antennas in better locations than e.g. the user's laptop.
The problem here seems to be that implementations don't check whether a QR code has, in fact, been legitimately scanned at all.
Basically, there would need to be some device-specific private key included in the QR code which the authenticator could check somehow, but that trust needs to be established first somehow
One potential mitigation I could imagine is browsers actively trying to prevent FIDO QR codes from being rendered in web pages, but that's pretty difficult to stop
This is, of course, something that an attentive user can likely detect, as the browser can prevent web pages from mimicking the QR code workflow exactly, but a) webauthn is supposed to prevent this from happening, as the 'line of death' has proven to be a poor barrier, and b) there's no good way for the authenticator scanning the QR code to identify this line of death reliably.
https://textslashplain.com/2017/01/14/the-line-of-death/
(And, of course, the designers of this interface knew this could be an issue, which is why BLE is involved at all: so that this kind of attack can't just be done entirely remotely. But BLE is a bad way of identifying a particular device compared to, say, plugging in a USB port. Especially also imagine compromised IoT devices...)
At least that much seems reasonable to detect (e.g. by blocking FIDO URLs from being opened in browser, but also by the FIDO URL handler verifying whether the caller is a camera application or a browser).
One of the tricks is going to be avoiding Bluetooth logins in the long run. Microsoft has mentioned interest in finding better ways to better flow keys cross-platform. Also, BLE logins should be rare in general if handled well (BLE login once and only once on a different platform to add a key for that platform directly to the site) and we shouldn't be training users to expect "login via QR code" as the "norm". (Of course, yes, that's also a training situation with a lot of human failure modes.)
Whether that's catastrophic or not will vary case by case and depends on what exactly you're securing with the key.
That's what I was trying to get at: Are any websites using this legitimately to communicate with local applications? If so, isn't that a pretty big fingerprinting and attack vector (how are websites authenticating themselves to these local applications and vice versa)?
Edit: Also any local network equipment probably uses local ips a lot, they often have web UIs that have legitimate use cases for this.
Sure, but that trust is about me, an owner of this particular localhost, interacting with it, not trust some.website.on.web to have an unchecked communication with it.
Another attack vector is public DNS names that resolve to local IPs as well, like "lvh.me". I block these with a local dnsmasq instance and the "stop-dns-rebind" setting.
Still not sure if this catches everything, probably not. I really wish browsers would just block all of this by default and ask for permission.
uBO LAN list blocks those as well, only except strict 1st-party connections, i.e if `lvh.me` is used as connections on other domains (including different subdomains), it will be blocked.
Consider the airport attack. Rather than trick me to log with my social credentials, you could prompt me to sign up for a new account on hotspot.xyz. After I enter my email, tell me that the account exists and prompt to log in with passkey.
Now the attacker kicks off the connection targeting my Google credentials. Rather than a fake login screen, they present me with a QR code. From the user perspective, there’s nothing obvious to tell me this is a passkey flow with Google and so I wrongly assume that my passkey must be in my mobile keychain. I scan the QR code and get prompted to approve the login. If I read the block of text on my phone, I will see a mention of the RP (Google.com) but I’d guess most users aren’t looking that closely.
When all is said and done, my hotspot login attempt failed and I’m completely unaware that I just logged into Google on your behalf.
How much was this bounty if there was any? Looks like a 7.8 severity CVE [0].
This is similar to how you can't access HID (and by extension CTAP2 or U2F) or CCID (and by extension smart cards such as OpenPGP cards) over Web USB.
Let’s say that you rely on the passkey implementation in your password manager and have that installed directly on your laptop. When you hit the legitimate site, your password manager prompts for user verification and to approve the login.
When you hit the phishing site and have the QR code pop up, it’s the first indication that something is wrong but the attacker doesn’t have your session yet. Your laptop is not listening for a BLE connection. That only occurs when you scan the QR from your phone and complete the authentication flow there.
In other words, it’s totally opt-in at log in time to use BLE and protecting yourself just means deciding it’s not a feature you trust. If you still aren’t comfortable though, the next move would probably be to just disable Bluetooth on one side or the other.
For example, in the case of SMS-OTP, the credential is (access to) the registered phone number, yet I'd still call an attack that successfully intercepts one OTP in time to use it a successful phishing attack.
I also echo some of the other critiques, which are that passkeys are advertised as phishing resistant and not phishing proof. I do understand that the average user may not grasp the nuance, but you leaned pretty hard into the idea that phishing them should be impossible.
One last recommendation. While I do think this is quite clever and a plausible attack scenario, this relies on the out-of-band authentication scenario. Assuming I’m sitting in the coffee shop or airport and click your link, I’m not going to reach for my phone to scan the QR. I’m going to investigate deeper why the passkey isn’t working directly. If you’re lucky, I’ll assume the site has a bug in passkey authentication and fall back to more phishable creds (if the site has both).
I don’t necessarily think of this as a flaw in your attack, rather that it might muddy the waters for readers that are less familiar and don’t realize that this mode is most commonly used when you are authenticating from a non-default device or made the conscious choice not to use a synced passkey.
I'm not sure I understand what you mean here with: > I’m not going to reach for my phone to scan the QR
The whole point of the attack is that it can be delivered without you having to scan the QR code, exploiting the fact that browsers allowed (patched) navigation to fido:/ links, initiating the BLE communication to a malicious device that is relaying the communication to the legitimate site, stealing a session. Let me know if that clears up the confusion.
As for phishing resistant/ phishing proof, to some is the same thing, nothing is "anything"-proof so I did not pay too much attention to the wording. Also I just wanted to stress the fact that although some theorized attacks were present, I had not seen anything put in practice before, which is what motivated me to prove it was not impossible.
Thanks for the feedback, will be making changes to the blog to clear up some the the things you have outlined here :)
Applies to cryptography, authentication and so many things.
Definitely not impossible, but still a very different threat level.
Also, this vulnerability is very patchable; password phishing is incredibly hard to prevent.