Chromium

Security Bug

Important: Please do not change the component of this bug manually.

Please READ THIS FAQ before filing a bug: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/faq.md

Please see the following link for instructions on filing security bugs: https://www.chromium.org/Home/chromium-security/reporting-security-bugs

Reports may be eligible for reward payments under the Chrome VRP: https://g.co/chrome/vrp

NOTE: Security bugs are normally made public once a fix has been widely deployed.

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

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

p.s. it was reviewed here: https://issuetracker.google.com/issues/370176231 and I was told to report it again here.

VERSION Chrome Version: 129.0.6668.70 + stable Operating System: iOS and Android

REPRODUCTION CASE

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

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. (The program is not attached here as it was said not to include a zip file, so the entire source is available at this link: https://nextcloud.mastersplinter.work/index.php/s/8MDPwR7RRBizJeY)

To better showcase this I have attached 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.

A video demo is included as well, showcasing the victim's view on the bottom right.

FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION Type of crash: [tab, browser, etc.] Crash State: [see link above: stack trace with symbols, registers, exception record] Client ID (if relevant): [see link above]

CREDIT INFORMATION Externally reported security bugs may appear in Chrome release notes. If this bug is included, how would you like to be credited? Reporter credit: mastersplinter