CVE-2024-9956 – PassKey Account Takeover in All Mobile Browsers

resfirestar · 2025-03-19T15:31:55 1742398315

The subheading "Phishing PassKeys credentials using browser intents" is inaccurate. The attacker does not get a credential, only a session.

chc4 · 2025-03-19T15:30:38 1742398238

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?

vlovich123 · 2025-03-19T15:07:59 1742396879

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

protimewaster · 2025-03-19T15:17:28 1742397448

> 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.

jbverschoor · 2025-03-19T15:23:03 1742397783

Perhaps they had the info before it was disclosed to the others?

programmarchy · 2025-03-19T15:24:36 1742397876

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?

（评论） (comments)

（评论）
(comments)