CVE-2024-9956 – PassKey Account Takeover in All Mobile Browsers
120 comments
·March 19, 2025vlovich123
bflesch
The involved engineers are most likely running around with a blushed-red face to this day, claiming "phishing resistance" in all the marketing materials but then having such a bug. I'd say the cover-your-ass (CYA) reflex was a big incentive for google engineers to fix it quickly.
acdha
This attack requires physical presence and visiting an attacker-controlled page. It’s absolutely a real threat and great work, but there are multiple orders of magnitude more people getting phished using weak MFA than by an attacker with control of a BLE device in their home or office.
lxgr
Phishing resistance isn't a binary property, it's a spectrum, and even with this vulnerability, that of passkeys is orders of magnitude higher than that of most other alternatives (including passwords, SMS OTP, TOTP etc.)
verst
Microsoft Edge had a release based on the relevant Chromium version on Oct 17, 2024. That is release 130.0.2849.46:
https://learn.microsoft.com/en-us/deployedge/microsoft-edge-...
https://msrc.microsoft.com/update-guide/en-US/vulnerability/...
protimewaster
> Wow - only Google seemed to really prioritize fixing this / had the processes and manpower to get a fix out quickly.
I would have guessed they'd be the quickest, but I wouldn't have guessed they'd be months ahead of the others.
gavinsyancey
Reading through the Chromium bug report, it looks like the reporter wasn't able to get in contact with Mozilla until February, so after they were aware it only took a month to fix the bug in Firefox. It's unclear when they started trying, and who's fault the delay is.
mastersplinter
I can't speak to the prioritization differences between the different browser teams, Chrome was definitely the best which isn't surprising considering their resources. Apple was also quite swift but I imagine it took them some time to decide where to deliver the fix, I myself wasn't sure if this is something that should be blocked at the OS level (the Authentication checking the intent origin) or browser. Mozilla is usually the slowest out of the three but they were still very professional.
jbverschoor
Perhaps they had the info before it was disclosed to the others?
crtasm
https://www.mozilla.org/en-US/security/advisories/mfsa2025-1... links the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1922357
but it's not public, perhaps someone can tell us when it was opened.
bflesch
Nice find.
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...
everybodyknows
I'd also ask: Why can't MS explain them coherently? From just the first two FAQ items:
> 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.
lxgr
Security engineers aren't infallible. This is a really clever channel confusion attack that presumably just nobody considered. It happens, unfortunately.
bflesch
Clever attack indeed - wouldn't have expected for this to be possible. I trusted the claims of Webauthn / Passkey being "phishing proof" without much consideration, because these claims came from highly respected companies. Unfortunately this is yet another example for "trust, but verify".
3np
Any professional should know this. Claiming any credential scheme is unphishable is not honest. Leading wider marketing with "phishing-resistant" is not far from that, knowing that the subtlety is lost on the public.
sunshowers
I'm curious if folks tried to use a model checker. Seems like a model checker might be able to identify cases in the spec where invariants are violated.
lxgr
I don't think that that would have helped here: The invariant ("URLs purportedly resulting from a QR code scan must only result from an actual QR code scan") essentially follows directly from a specific threat scenario that was missed.
ziddoap
>Even MS has in their FAQ: Are "Q: passkeys phishing resistant? A: Yes, passkeys are phishing resistant" [1]
Phishing resistant is different than phishing proof.
Passkeys remain phishing resistant, even in light of such an attack.
AStonesThrow
I don't know about today, but in the 1980s, "water resistant" for wristwatches meant that you could wash your car and the hose-spray wouldn't turn it into a brick.
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.
ajross
> How can they overlook such an attack vector?
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.
bflesch
I totally agree with you. That's why claiming your technology is "phishing proof" reflects badly on the people involved who are all supposedly experts in their field, and well-compensated on top.
WorldMaker
Most claims about Passkeys are "phishing resistant" not "phishing proof". This scenario is still more "resistant" than passwords: it requires a believable MITM proxy for a specific website that is also physically in someone's near-area network/personal-area network to pick up intentionally low powered Bluetooth LTE packets, and to click through a login flow that on most of these OSes/browser combos looks decidedly different ("remote login" instead of "real login"). Obviously that's still a threat model to consider, just as one should generally worry about logging into anything on a public Wifi, but the number of "ingredients" to get right on this phish attack is much higher than anything password related, and is much harder to scale (spearphish) because as amusing as it sounds to try to build a fleet of Raspberry Pis to blanket a public space it starts to get physically impractical.
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.)
lxgr
The protocol is; the implementations weren't, in this case. (To be fair, the specification didn't explicitly say "validate the origin of the pairing secret to actually be a QR code scanner", but that's still more of a missing (important!) implementation warning than a protocol design flaw.)
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.
0xbadcafebee
The way things like this are developed is not by "clever and highly paid engineers". They're developed by a cabal of businesses led by a standards body to try and wrangle all the competing interests into one solution for everyone's problems (lol jk, it's to solve the problems of the most influential organizations involved).
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.
wkat4242
They say phishing resistant. They don't say phishing proof. And this is not an easy thing to exploit.
lxgr
If I understand it correctly (I had some trouble wrapping my head around the exact attack vector):
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?
tadfisher
Correct, the Chrome fix at least was to block fido:/ URL navigation, so the victim can't get redirected to their passkey application with the phished URL.
burnte
Everything I hear about passkeys makes me glad I've stuck to strong passwords in a password manager and 2fa via tokens.
shepherdjerred
I've had a _really_ good experience with passkeys + 1Password. I vastly prefer it over a password + TOTP 2FA.
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.
rkagerer
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.
autoexec
This is just one more reason to keep bluetooth disabled on mobile devices. There have been other vulnerabilities with bluetooth itself, and bluetooth is constantly used to track people. 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.
lxgr
> bluetooth is constantly used to track people
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.
autoexec
> 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.
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.
lxgr
I'd agree that sometimes privacy can be orthogonal to the manufacturer's interests, but that sounds like a complete conspiracy theory that doesn't pass Occam's razor.
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.
dharmab
Over ten years ago retailers were already tracking customer's cell phones as they walked around the store to see what sections people walked through. Your phone constantly sends radio waves out that are identifiable to the individual device.
https://www.nytimes.com/2013/07/15/business/attention-shoppe...
lxgr
Could you be more specific?
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.
reportgunner
I don't use bluetooth much and I have no idea what the technical details are, but surely an attacker can find a way to either guess or determine what bluetooth devices your phone is paired to and then pretend to be that device. (like a keyboard)
Also according to my experience there is no "permission for bluetooth", it all falls under "Phone" or whatever other permission on Android.
latentcall
I have BT headphones in all the time and my phone doesn’t have a headphone jack.
reportgunner
Yeah I also have a phone without a headphone jack, I just bought a pair of usb-c wired headphones today for that reason.
Bluetooth was a mistake.
theragra
For tiny amount of users who care to this extent. To everyone else, bt is awesome. Headphones, hr sensors, smartwatches and fitness trackers etc etc
latentcall
Hm, I will look into those!
chc4
I don't use BLE PassKeys, but wouldn't the user also have to be paired with the attacker controlled BlueTooth device to get the connection request? Does the "The victim’s Authenticator connects to the attacker’s Client" step's authorization include pairing to a new device and not only allow a log-in with an already connected one?
lxgr
The QR code initiates pairing (at the FIDO level; I believe at the Bluetooth level there is actually no pairing required here).
chc4
The diagram in the post has the user device talking to the attacker device over Bluetooth, and the bug description explicitly says "An attacker within bluetooth range" - which heavily implies to me your device actually is pairing with the attacker device somehow! If already being paired with the attacker Bluetooth device is a prerequisite for this attack that's much less of a concern imo.
lxgr
As far as I can tell, no pairing (or indeed any kind of logical Bluetooth connection) is required in the protocol used. The (device containing the) authenticator broadcasts a Bluetooth LE advertisement, and the "client platform" (i.e. usually the browser) has to be able to receive its contents to prove physical proximity.
Such a (by definition unidirectional) Bluetooth LE advertisement can easily be received and relayed over arbitrary distances.
warp
IIRC caBLE ("cloud assisted bluetooth low energy") sidesteps the usual bluetooth pairing process by using out-of-band channels (QR codes, NFC) to exchange initial pairing information.
3np
"range" here refers to physical distance (adjusting for interference). No prior pairing required.
amluto
What prevents essentially the same attack from being done by making a (desktop / tablet or even wall-mounted-display) web page that shows a QR code that, when scanned by a victim device, triggers the authentication flow?
rcxdude
Indeed. That attack is a little more involved (requires having a BLE device in proximity and tricking the user into scanning a QR code outside of the normal browser flow), but it seems like the main issue is that there's no way for the authenticator to validate that the device that's actually being authenticated is the device that the user actually intends to authenticate.
lxgr
The device being authenticated is the one that I scan the QR code off of, isn't it?
The problem here seems to be that implementations don't check whether a QR code has, in fact, been legitimately scanned at all.
rcxdude
That's what the user intends, but there's no way for the authenticator to know whether the QR code it's scanning is actually from a webauth session on the device it's scanned it from, or simply proxied from another device: ultimately the QR code is just a bunch of pixels, and a web page can display arbitrary pixels.
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...)
charcircuit
The fix blocks fido links from anywhere, including QR code scans.
https://chromium-review.googlesource.com/c/chromium/src/+/59...
Edit: QR code scans are actually allowed to open such links.
amluto
Is there some handshake over BLE that allows a browser that speaks BLE and shows a QR code to trigger the FIDO flow but does not allow a QR code by itself to do so? If so, how? Remember, the attacker is presumed to control a BLE device in range of the victim’s authenticator.
charcircuit
I was mistaken. I'm not sure what would prevent a proxied QR code + proxied Bluetooth signal.
programmarchy
I’m missing something. If WebAuthn is “ssh for the web” then why would it matter if Bob was phished and logged into the fake crypto portal running on the raspberry pi? It’s not like the attacker now knows his private key. Is the danger that Bob also would share his crypto wallet keys with the fake site or something?
lxgr
By the analogy of SSH, this vulnerability is more of an exposed/incorrectly permissioned SSH agent Unix domain socket than a private key compromise.
Whether that's catastrophic or not will vary case by case and depends on what exactly you're securing with the key.
garaetjjte
Attacker is now logged in on the real crypto portal as Bob. SSH equivalent would be like connecting to malicious server with SSH agent forwarding enabled.
programmarchy
Okay, that makes sense. I thought they could just log in to a dummy site, not that it was proxying requests through to a real site. Yikes.
reportgunner
I suppose you can completely skip dummy sites when phishing for passkeys since the user doesn't know the password and therefore you don't need him to enter said password anywhere (which is why you needed a dummy site in the first place).
vlovich123
The attacker has access to whatever the passkey was protecting. It's like asking who cares about password phishing. And FWIW a crypto portal in front of something like Coinbase can obviously do a lot of damage since most people do not keep their crypto in their own personal cold storage.
chc4
The attacker controlled proxy is the one that logged in, and so captured a valid session for the user account that they can use afaik
gradientsrneat
This would be a nice ublock origin filter for Firefox Android. I installed one that blocks sites requesting localhost addresses, after I noticed some websites portscanning my localhost for "security".
saint_yossarian
For reference, uBO has a filter list called "Block Outsider Intrusion into LAN" which you can enable. That blocks all cross-site requests to local IP addresses, "localhost", and some other well-known locally-resolved hostnames.
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.
eipi10_hn
> Another attack vector is public DNS names that resolve to local IPs as well, like "lvh.me".
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.
saint_yossarian
Oh nice, I guess that's the rule using `cap_ipaddress` I see in there.
GTP
Interesting, can you share which kind of websites you noticed doing this?
Scoundreller
lxgr
I wonder why browsers even allow cross-origin access to localhost in that way, given all the risks involved.
cjcampbell
One devious thing about this attack is that the phishing site doesn’t even need to impersonate the site it’s attacking. I have password based logins on hundreds of sites and it’s plausible that I’ll eventually have passkeys on enough sites that I can’t keep track.
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.
rvz
What an excellent write up. Adding a Web Bluetooth API to the browser to then be later used for "secure" actions like passkeys or logins never made any sense to begin with.
How much was this bounty if there was any? Looks like a 7.8 severity CVE [0].
rcxdude
This issue is mostly seperate from Web Bluetooth: it'd be an issue even if that API didn't exist at all (though, of course, these APIs make it a little harder to use those interfaces for validating anything, though thankfully not that much harder because it's fairly easy to add some 'hey, this is really a browser and not a web page making this request' signal, as opposed to with QR codes, which are ultimately just a collection of pixels and it's the very-hard-to-evaluate context in which it appears on the device's screen which makes for that seperation.)
lxgr
FIDO is explicitly blocked in Web Bluetooth for exactly that reason: https://github.com/WebBluetoothCG/registries/blob/master/gat...
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.
mastersplinter
So grad you enjoyed it! Chrome awarded 6000 USD, very grateful for it and will fuel some more security research for a while :)
lostmsu
How can I disable Passkeys over Bluetooth? Given the severity of vulnerability and the "fix" just plugging one hole of potentially many more, I'd rather have it permanently disabled.
cjcampbell
You don’t necessarily have to disable anything, but choose not to use the secondary device authentication flow.
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.
lostmsu
It is hard to remember which websites have passkeys on laptop, and which only on the phone.
since not stated in the article and I started to get worried, this was reported last year.
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