Full Report
PassKeys are a form of the WebAuthn CTAP specification to perform passwordless authentication. The idea is for a Client, such as the browser, to communicate with an authenticator, such as a mobile phone or USB device. In practice, "WebAuthn is just SSH (privkey-pubkey) for the web". There is a difficult problem though: if the passkey is on my phone and I want to login via the web browser, how do I do that? PassKeys contain a cross-device authentication flow with various methods. One of these is using Bluetooth low energy (BLE). Since these devices ensure close proximity, the idea is that authentication is now completely phish-proof. When doing cross-device login, WebAuthn authentication creates a QR code to scan. This is how the flow works: User scans the QR code. The mobile phone's PassKey manager processes this data. BLE connection is made. Browser generates a random challenge for the Authenticator to sign with the stored private key. Authenicator signs the challenge and sends it back. Browser sends everything to the backend website. FIDO intents, the URI found in the QR code, contain a blob with a bunch of serialized data. Since it contains a public key of the relying party, a timestamp, registered domains, and much more. Since this information is just a QR code, this means that FIDO intents can be triggered cross-origin. Why does this matter for security? Here's the attack scenario: Victim clicks on a link controlled by an attacker's page. Attackers' device visits the login page of the victim user and the website they want to exploit. They extract the FIDO link from the QR code using a headless browser and redirect the user to the page. Victims PassKey manager pops up for the attacked site. This is done by the website, and since there's no validation of FIDO URLs being popped. The attacker connects to the device user's phone/device via BLE with the session from the first step. The user approves the login attempt. Attacker is now logged in via the user's account. This attack requires physical access while the victim clicks on a user-controlled link. Since WebAuthn is baked into the browser, it's not possible to get the PassKey information from the website itself. Instead, I believe that the FIDO link is required to be clicked on in order to start the pairing process. Then, by connecting to the attacker's controlled device that has the session on it, we trick them into logging into the wrong website. To fix this issue, browsers made the FIDO:// URI no longer navigable by a page. Overall, great research into a new form of authentication!
Analysis Summary
# Vulnerability: PassKey Account Takeover via Cross-Origin FIDO Intent Navigation
## CVE Details
- CVE ID: CVE-2024-9956
- CVSS Score: **Not specified in the provided text.** (Severity is implied to be High due to account takeover capability.)
- CWE: **Not specified in the provided text.** (Likely related to insecure intent handling or cross-site request forgery implications.)
## Affected Systems
- Products: All major mobile browsers supporting the cross-device PassKeys flow via FIDO intents (which utilize the `FIDO://` URI scheme).
- Versions: All versions prior to the vendor patches addressing this issue via disallowing page-initiated navigation to `FIDO://` URIs.
- Configurations: Mobile environments relying on the QR code scanning/FIDO intent mechanism for cross-device PassKeys authentication where the initiating page controls the navigation that triggers the intent prompt.
## Vulnerability Description
The vulnerability resides in how mobile browsers process cross-device PassKey authentication when initiated via a QR code scan. This flow relies on a **FIDO intent (a `FIDO://` URI)** embedded in the QR code. This URI contains serialized data, including the Relying Party (RP) public key and registered domains.
The flaw allowed an attacker-controlled webpage, leveraged via a headless browser to preemptively extract the FIDO link, to redirect the victim's browser to this `FIDO://` URI. Since there was no validation on the source origin initiating this navigation, the PassKey manager (authenticator prompt) would launch, seemingly for the targeted legitimate site. Crucially, the attacker who set up the initial session (via the headless browser) was able to establish a **Bluetooth Low Energy (BLE) connection** with the victim's device/phone, tricking the PassKey manager into signing a challenge intended for the attacker's controlled session rather than the legitimate site the user *thinks* they are logging into. This results in a complete Account Takeover (ATO) for the targeted service.
This attack requires the attacker to be within BLE range of the victim's device *after* the victim clicks a malicious link and the browser attempts to process the FIDO intent.
## Exploitation
- Status: **PoC available** (The researcher detailed the exact attack scenario and necessary setup, implying successful demonstration.)
- Complexity: **Medium** (Requires an attacker to be physically close (BLE range) to the victim after the victim clicks the link, and potentially requires setting up a remote session capture mechanism, although the article implies the first step is extracting the link via a headless browser *on an attacker-controlled device* gaining proximity.)
- Attack Vector: **Adjacent** (Requires physical proximity for the necessary BLE connection component during the authentication process phase.)
## Impact
- Confidentiality: **High** (Full account takeover possible.)
- Integrity: **High** (Attacker gains full control over the compromised account.)
- Availability: **Low** (The primary impact is unauthorized access, not service disruption, though credentials could be changed/abused.)
## Remediation
### Patches
- Browsers implemented fixes to prevent the **`FIDO://` URI scheme from being navigable directly by a web page**. This stops the initial step of the cross-origin-initiated intent flow.
### Workarounds
- Users should be wary of unexpected PassKey prompts arising immediately after clicking external links, even if the prompt appears to be for a trusted site.
- The core security assumption that PassKeys prevent phishing relied on preventing origin confusion, which this attack bypassed by manipulating the intent URI launch mechanism.
## Detection
- Indicators of Compromise: Unexpected launch of the PassKey manager prompt following navigation from an untrusted source.
- Detection methods and tools: Analyzing browser navigation logs for navigation attempts to proprietary URI schemes like `FIDO://` initiated by non-system-level processes or unexpected origins.
## References
- Vendor Advisories: Browsers teams reportedly fixed the issue quickly.
- Relevant links - defanged:
- hxxps://mastersplinter.work/research/passkey/