1922357 - (CVE-2024-9956) A vulnerability in Firefox mobile allows attackers to trigger fido:/ links, hijacking FIDO2 accounts by tricking victims into authenticating malicious requests, bypassing 2FA, and taking over accounts.

Status: RESOLVED FIXED

(Firefox for Android :: WebAuthn, defect, P2)

Description

[MasterSplinter]

Attachment: firefox-passkey.zip

A vulnerability in Firefox mobile allows attackers to trigger fido:/ links, hijacking FIDO2 accounts by tricking victims into authenticating malicious requests, bypassing 2FA, and taking over accounts.

In Firefox mobile an attacker page can trigger navigation to a fido:/ link that was generated on a different origin for a webauthn authentication, this will trigger on the victim's mobile device the same passkey overlay requesting authentication as though they had scanned the QR code. This is because fido:/ URIs are treated as deep links by the base OS. This allows an adjacent network attacker to take over a victim's account (or bypass 2FA) for an RP where they have registered FIDO2 credentials on with the following steps:

• The attacker obtains the victim's username (either via enumeration of the webauthn registration endpoint) or in any other way depending on the attack
• The attacker automates the steps required to start a webauthn authentication on the selected RP as well as grabbing the fido:/ out of the QR code, using a headless browser
• The attacker places himself in an adjacent network range to the victim and sends his attacker controlled page to the victim
• Once the victim clicks on the link the automated steps defined earlier a run and the fido:/ link is triggered in the victim's browser
• The legitimate FIDO2 request is accepted by the victim as he relies on the knowledge that his RP's account must be safe as this is a different origin
• The victim's device completes the authentication which is however happening on the attacker's controlled device, allowing the attacker to login with the victim's credentials.

While the attack is similar to proxying a QR code directly and tricking the victim into scanning it an completing the authentication request, the attack complexity using the presented approach drops rapidly, this because it only requires the victim to be phished on only one device and breaks the security boundary of: "An RP's webauthn authentication request can only be started from approved origin".

I am not certain if this is an issue that should be addressed at a browser level or if the mobile OS should validate which applications are allowed to trigger a fido:/ deep-link. However I do not see the need from a browser perspective to be able to trigger such a deep-link from any origin as that breaches a clear security boundary. I would love to hear your thoughts about this.

Additionally chaining this with the bug previously reported about content spoofing, it is possible for an attacker to completely forge a PassKey authentication that looks legitimate. Bug is found here: https://bugzilla.mozilla.org/show_bug.cgi?id=1916379

PoC

The PoC can be simplified by simply decoding a webauthn QR code from a chromium based browser, embedding the fido:/ link in a page and then using a secondary device to visit that page and clicking on the link.

To better showcase this I have attached a zip file containing a Go program that automates the attack showcased. The program has the following dependencies:

• Must be run on a Unix based system with BLE
• chromium-browser or google-chrome must be installed (used for the headless browsers steps)
• imagemagick tools (used for grabbing the QR code from the headless browser popup)

To reproduce the attack:

• Pick a mobile device which supports passkeys
• Head over to https://webauthn.io (used as poc) and create an account using the device as passkey
• Run the program with go run . -email {email used for victim account}
• Visit the malicious webserver (listening on port 8000) with the device and click on the link in the page.

In the zip file, a video demo is included as well, showcasing the victim's view on the bottom right.

Impact

An attacker within BLE range of its victim can obtain a valid FIDO2 authentication on any RP desired and use the victim's device to complete such authentication. This allows him to take over accounts directly and/or bypass 2FA protections on the RP, breaking the security boundary that explicitly states that one origin cannot trigger a webauthn auth request (or registration) for a different origin.

Comment 1

[Andrew McCreight [:mccr8]]

John, could you take a look? I'm not familiar with the requirements of this protocol.

Comment 2

[Daniel Veditz [:dveditz]]

I am not certain if this is an issue that should be addressed at a browser level or if the mobile OS should validate which applications are allowed to trigger a fido:/ deep-link.

The OS should not restrict apps. Browsers themselves, like Firefox, support QR readers, and it could also be quite legitimate coming from a password manager type app. There's no way for the OS to know when it's legitimate and when it's not.

However I do not see the need from a browser perspective to be able to trigger such a deep-link from any origin as that breaches a clear security boundary. I would love to hear your thoughts about this.

My first instinct is to agree with you about that.

I then have a slight nagging doubt because, In theory, a web app could implement something like a QR reader. Opening a fido: link might be a perfectly legitimate thing in that case. Seems unlikely? A site implementing WebAuthn debugging or development tools is maybe more realistic, but pretty niche. Rare enough we don't have to care? Or restrict a workaround to nightly ("developer") builds?

Comment 3

[Daniel Veditz [:dveditz]]

Attachment: firefox-passkey.mp4

The video unpacked for convenience.

Comment 4

[MasterSplinter]

In theory, a web app could implement something like a QR reader. Opening a fido: link might be a perfectly legitimate thing in that case

Yes this indeed is not something that the OS should have to restrict but the browser. I do not think the QR code scanning webapp is a realistic requirement, why implement your own scanning solution but then rely on the OS as the authenticator? A more likely solution is a mobile app that scans the QR code and implements the BLE protocol from scratch to become its own authenticator.

I believe this to be quite a serious finding and it breaches the most important security requirements of PassKeys and their "unphishable" characteristics. Additionally the content spoofing bug makes this chain look like a normal webauthn authentication, where actually an adjacent network attacker is taking control over the victim's account on any chosen RP that uses PassKey.

Comment 5

[Daniel Veditz [:dveditz]]

I don't understand the difference between what I see on my Android device when I scan a QR code to log in, and what the victim in your movie sees. When I scan the fido link from the QR code I see the "Connecting with your device" toast first, then I get a fingerprint prompt ("use your biometric to continue") that clearly says "Use passkey for webauthn.io".

In the movie, after the "open in another app" the first thing that comes up is a "Skip the QR code next time" prompt that I never see. THEN the "Connecting with your device" prompt comes up in the movie. A fingerprint prompt does come up, but the text says "CHANGE VERIFICATION METHOD" which I assume is because you agreed to the "skip the QR code" choice. I never see a confirmation prompt that explicitly names webauth.io as the site you're going to submit the passkey to. I understand that in your example you've navigated the victim to webauthn.io and we assume you've socially engineered them to be OK with signing in, but I still want to see that confirmation. Without that you could come up with any number of scams that make the user think they're confirming something innocuous when they're actually entering the passkey for their bank. If I'm out and about minding my own business I don't care how good your scam is, there is no way I'm submitting the passkey for any site important to me when I didn't initiate the transaction.

I even tried changing the in-page Authentication setting on webauthn.io to User Verification "Discouraged" and still my phone made me confirm the choice. Of course an attacker couldn't make a real site do that even if it worked, I just wanted to rule that out as the reason for the difference

Is this a difference in Android version? device vendor? I'm guessing yours is a stock Google Android emulator. My device is a Samsung which does change the stock Android UI in lots of ways, but I thought the WebAuthn dialogs were implemented in Google Play Services and might have been outside the scope of Samsung "OneUI" customizations. In any case they looked exactly like the ones in your movie

Comment 6

[Daniel Veditz [:dveditz]]

I do not think the QR code scanning webapp is a realistic requirement

"realistic" or not, there sure are a lot of them!

• https://webqr.com/
• https://scanqr.org/
• https://qrscanner.net/
• https://qreader.online/
• https://www.qrstuff.com/scan
• https://4qrcode.com/scan-qr-code.php
• https://www.the-qrcode-generator.com/scan
• https://dnschecker.org/qr-code-scanner.php (what the heck does that have to do with DNS?)
• https://products.aspose.app/barcode/recognize/qr

Comment 7

[Daniel Veditz [:dveditz]]

I don't care how good your scam is, there is no way I'm submitting the passkey for any site important to me when I didn't initiate the transaction.

I mean I wouldn't if given a fighting chance because the dialogs are clear about what site I'm logging into.

Comment 8

[MasterSplinter]

(In reply to Daniel Veditz [:dveditz] from comment #6)

I do not think the QR code scanning webapp is a realistic requirement

"realistic" or not, there sure are a lot of them!

• https://webqr.com/
• https://scanqr.org/
• https://qrscanner.net/
• https://qreader.online/
• https://www.qrstuff.com/scan
• https://4qrcode.com/scan-qr-code.php
• https://www.the-qrcode-generator.com/scan
• https://dnschecker.org/qr-code-scanner.php (what the heck does that have to do with DNS?)
• https://products.aspose.app/barcode/recognize/qr

These are simple QR code scanner applications, they have nothing to do with PassKey so I do not see how they are relevant to the finding I'm presenting.

(In reply to Daniel Veditz [:dveditz] from comment #7)

I don't care how good your scam is, there is no way I'm submitting the passkey for any site important to me when I didn't initiate the transaction.

I mean I wouldn't if given a fighting chance because the dialogs are clear about what site I'm logging into.

The finding is about a clear webauthn implementation requirement being bypassed: one origin should not be able to start an authentication process that it has not generated in the same origin.

Additionally I don't understand your approach to this, PassKeys are created because to this day people give out their credentials to sketchy origins, hence the passwordless technology to protect them. The finding is not about whether you specifically would fall for this attack, but whether a clear security boundary is being crossed, which it is, and how that can possibly affect users. I also want to point out that other browsers are already moving towards a safer implementation.

Comment 9

[Daniel Veditz [:dveditz]]

(In reply to MasterSplinter from comment #8)

The finding is about a clear webauthn implementation requirement being bypassed: one origin should not be able to start an authentication process that it has not generated in the same origin.

I already agreed with you that the browser itself should not send fido: links to an external app

Comment 10

[MasterSplinter]

I must've misunderstood your response, sorry about that. Let me know if there is any more information I can provide.

Comment 11

[Daniel Veditz [:dveditz]]

Chrome appears to have checked in fixes for this:
https://chromium-review.googlesource.com/c/chromium/src/+/5906286 (Android)
https://chromium-review.googlesource.com/c/chromium/src/+/5916492 (iOS)

Comment 13

[MasterSplinter]

Hi there! Is there any update on a fix for this? Do you require any more information from me?

Comment 14

[MasterSplinter]

Hi there! Just keeping you updated, Chrome has issued a CVE: https://nvd.nist.gov/vuln/detail/CVE-2024-9956, and the Chrome issue itself will be publicly disclosed the 13th January 2025. Due to the similarity of this finding in Firefox, the exploit PoC contained in that report can be used to exploit Firefox as well.

Comment 15

[MasterSplinter]

Hi there! Is there any updated on how this is planned to be fixed?

Comment 16

[MasterSplinter]

Hello, reaching out once again as both Google and Apple have issued a public advisory. I am planning to disclose this quite soon as well.

Regards.

Comment 17

[Daniel Veditz [:dveditz]]

John, redirecting the above 3 comments to you.

Jeff, since jmahon is no longer triaging this product I'm also redirecting the comment 13 question to you

Comment 18

[Daniel Veditz [:dveditz]]

I tried blocking this in necko by creating a network.protocol-handler.external.fido pref and setting it to false but that didn't work. These app-links are being handled in the front-end and bypassing that mechanism. I suppose that's related to why skhan added the see-also to bug 1685152 "Expose URI class".

Comment 19

[John Schanck [:jschanck]]

Attachment: Bug 1922357 - disallow the fido: URI scheme. r?boek

Comment 20

[Jeff Boek [:boek]]

:jschanck, patch looks good to me, let me know if you need any help testing it.

Hi there! Is there any update on a fix for this? Do you require any more information from me?
Nope!

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1cdaf6445ebe
disallow the fido: URI scheme. r=boek,geckoview-reviewers,calu,android-reviewers

Comment 22

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/mozilla-central/rev/1cdaf6445ebe

Comment 23

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:jschanck, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox136 to wontfix.

For more information, please visit BugBot documentation.

Comment 24

[John Schanck [:jschanck]]

Attachment: Bug 1922357 - disallow the fido: URI scheme. r?boek

Original Revision: https://phabricator.services.mozilla.com/D237313

Comment 25

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: A user could be tricked into opening a fido: link that should only be opened by scanning a QR code.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: n/a
• Risk associated with taking this patch: low
• Explanation of risk level: The patch blocklists a URL scheme that should not be used by Firefox.
• String changes made/needed: none
• Is Android affected?: yes

Comment 26

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/0cb8b3f24cc9

Comment 27

[Daniel Veditz [:dveditz]]

The reporter's blog post about this is published now that the Chrome bug is public: https://mastersplinter.work/research/passkey/

Because the Apple advisory (in 18.3) uses the same CVE as Chrome and the blog post, it will be less confusing if we use the same one.

Comment 28

[Daniel Veditz [:dveditz]]

Attachment: advisory.txt