CVE-2024-9956 – PassKey Account Takeover in All Mobile Browsers
53 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.
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.
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...
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".
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.
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).
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".
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.
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.
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.
resfirestar
The subheading "Phishing PassKeys credentials using browser intents" is inaccurate. The attacker does not get a credential, only a session.
lxgr
Arguably, "phishing a credential" doesn't necessarily have to mean full compromise of the credential itself.
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.
vlovich123
Which can be used to register your own passkey credentials obtaining an account takeover?
resfirestar
Sure, if you assume the session is scoped to allow registering a new passkey. Depends on how the application is configured. Regardless, getting the credential is different from getting a session.
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.
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
teeray
I wonder if this will enable creating a Firesheep-equivalent.
lxgr
This attack is very active, in contrast to Firesheep. The attacker needs somebody physically close to their Bluetooth device to additionally visit a site they control.
Definitely not impossible, but still a very different threat level.
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.
30aimaldonado
[flagged]
30aimaldonado
[flagged]
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