A Security and Usability Analysis of Local Attacks Against FIDO2

A Security and Usability Analysis of Local Attacks Against FIDO2

Speakers: Tarun Kumar Yadav

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=kc2Pwl4v9cY

Overview

FIDO2, a cornerstone of modern web authentication, primarily focuses on defending against remote threats like phishing and password compromise. However, a critical gap exists in its security posture concerning local attacks. This research, presented by Tarun Kumar Yadav at the NDSS Symposium, delves into the overlooked vulnerabilities arising from malicious browser extensions, cross-site scripting (XSS), and physical hardware security key (HSK) cloning. The work systematically analyzes these local attack vectors, revealing fundamental flaws in FIDO2's design and implementation that allow adversaries to bypass its robust security mechanisms.

The study identifies four core flaws and demonstrates the feasibility of seven distinct attacks, four of which are novel, while three previously theoretical attacks are proven practical through implementation. Beyond technical exploitation, the research incorporates extensive user studies, unequivocally showing that current FIDO2 user experiences, error messages, and notifications are insufficient for users to detect these sophisticated local threats. The talk concludes by proposing an improved hash-based clone detection algorithm and providing actionable recommendations for both Relying Parties (RPs) and browser developers to enhance FIDO2's resilience against this under-researched class of attacks.

Background

▶ Watch: Introduction to local FIDO2 attacks and research scope (0:00)

The FIDO2 protocol, or Fast Identity Online, represents the state-of-the-art for two-factor, multi-factor, and passwordless authentication on the web. It leverages public-key cryptography via the WebAuthn API on client machines, allowing users to authenticate with various authenticators, including Hardware Security Keys (HSKs) and built-in platform authenticators like biometrics.

The protocol involves three main entities:

1. Relying Party (RP): The web application (e.g., facebook.com) that supports FIDO2. It communicates with the authenticator via the WebAuthn client.
2. Authenticator: The device (e.g., HSK) that securely stores the user's private key and generates login credentials upon user authorization (e.g., PIN or button press).
3. WebAuthn Client: Typically a web browser, it mediates communication between the RP and the authenticator, crucially reporting the RP's origin URL to the authenticator to prevent phishing.

FIDO2 comprises two main components: the WebAuthn browser API for RP interaction and the Client-to-Authenticator Protocol (CTAP) for secure communication between the client and external authenticators (USB, Bluetooth, NFC).

The registration process involves the user initiating registration, the RP sending a request (challenge, user info, RP info) to the WebAuthn client, which forwards it to the HSK along with the RP's origin. The HSK generates a new asymmetric key pair, prompts for user consent, and sends registration data (credential ID, public key, RP ID hash, counter, attestation signature) back to the RP for verification and registration. Authentication is similar, but the HSK performs an assertion by signing the response with the private key corresponding to the credential ID.

A critical security feature is clone detection. An HSK never releases its private key. However, physical cloning attacks have been demonstrated, such as NinjaLab's cloning of a Google Titan Security Key using a side-channel attack (requiring 10 hours and $12,000 in equipment), and Roth et al.'s cloning on Nordic nRF52832 chips via voltage glitching for just $5. To detect such cloning, both the HSK and RP maintain an account-specific counter. The HSK initializes and increments its counter with each authentication. The RP stores this counter and updates it upon successful authentication. A cloning attack is detected if the RP receives a counter lower than its currently stored value, prompting a user notification.

The research's adversary model considers two independent adversaries:

• Adversary A1: A malicious or compromised browser extension, or malicious web pages leveraging a vulnerable extension to compromise the FIDO2 WebAuthn API. A1 has access to plaintext FIDO2 communication, enabling MITM attacks. A1's goal is to achieve unauthorized, long-term access to a victim's account without detection, often through a short-duration, one-time attack.
• Adversary A2: An attacker who gains temporary physical access to the victim's HSK and successfully clones it. A2 cannot retrieve the private key or metadata but can create a functional clone. A2's goal is to bypass the FIDO2 clone detection algorithm and gain undetected access using the cloned device.

Through systematic analysis, the researchers identified four fundamental flaws that form the basis for the attacks:

1. Lack of confidentiality/integrity of FIDO2 messages accessible to browser extensions: Allows Adversary A1 to intercept, modify, and inject FIDO2 messages.
2. Broken clone detection algorithm: The existing counter-based mechanism is vulnerable to sophisticated cloning attacks by Adversary A2.
3. Potential for user misunderstanding from social engineering and notification/error messages: Current user experience (UX), error messages, and email notifications are often generic or misleading, making attack detection difficult for both A1 and A2.
4. Cookie life cycle: The long lifespan of "Remember Me" cookies, designed for usability, can be exploited by Adversary A1 to bypass 2FA.

Key Findings

▶ Watch: Detailed FIDO2 registration process (3:00)

The research uncovered several critical findings highlighting the susceptibility of FIDO2 to local attacks:

• Four Fundamental Flaws: The study systematically identified four core weaknesses:

1. The lack of confidentiality and integrity for FIDO2 messages exposed to browser extensions.
2. A vulnerability in the existing counter-based clone detection algorithm.
3. User misunderstanding exacerbated by generic error messages, email notifications, and social engineering.
4. The exploitable long lifespan of "Remember Me" cookies.

• Seven Practical Attacks: Leveraging these flaws, the researchers demonstrated seven distinct attacks:
• Mis-binding attack during registration (Attack 1): An attacker registers their HSK instead of the victim's.
• Double-binding attack during registration & authenticated session (Attack 2): An attacker registers their HSK alongside the victim's, or secretly in the background.
• Synchronized login (Attack 3): An attacker coerces the user to authenticate for an invisible, attacker-controlled login session.
• Man-in-the-Middle (MITM) (Attack 4): An attacker intercepts and manipulates authentication requests to create a login session on the victim's account.
• Signature algorithm downgrade (Attack 5): An attacker forces the use of less secure signature algorithms during registration.
• Cookie Lifecycle (Attack 6): An attacker steals long-lived "Remember Me" cookies to bypass 2FA.
• Bypassing clone detection algorithm (Attack 7): An attacker circumvents the counter-based clone detection or exploits its generic error messages.

Four of these attacks are novel, and three previously theoretical attacks are shown to be practical.

• Widespread Vulnerability to Malicious Extensions: An analysis of 246,345 Chrome extensions revealed that 115,881 (47%) possess activeTab or tabs permissions, sufficient to execute most of these MITM-style attacks by overriding WebAuthn client APIs. Alarmingly, 404 of these extensions have over one million users each, representing a massive potential attack surface. For cookie-stealing (Attack 6), 31,326 extensions had cookies permission, with 18,024 also having ://* permission to steal cookies from any RP; 102 of these had over one million users.
• User Undetectability: Two comprehensive user studies (n=80 online, n=20 in-lab) definitively proved that users, even when primed to detect attacks, consistently fail to identify malicious activity based on current FIDO2 error messages, email notifications, or UX cues. They attributed anomalies to system glitches, device errors, or user mistakes rather than attacks.
• Improved Clone Detection: A novel hash-based clone detection algorithm was proposed to address the vulnerabilities in the existing counter-based mechanism, offering a robust defense against stealthy cloning attacks while remaining backward compatible.

Technical Deep Dive

▶ Watch: FIDO2 counter-based clone detection explained (3:40)

The seven demonstrated attacks exploit the identified fundamental flaws in FIDO2's design and implementation, particularly concerning the accessibility of FIDO2 messages to browser extensions, the inadequacy of the clone detection algorithm, and poor user feedback.

Attack 1: Mis-binding attack during registration

• Exploited Flaws: Lack of confidentiality/integrity of FIDO2 messages (Flaw 1), User misunderstanding (Flaw 3).
• Mechanism: Adversary A1, via a malicious extension, intercepts the HSK response during a victim's HSK registration. A1 replaces the victim's public key with their own public key and substitutes the digital signatures with those generated using the attacker's private key. This causes the Relying Party to register the attacker's HSK instead of the victim's. The victim, upon later login attempts from a new device, would receive an error indicating their HSK was never registered, leading to confusion. The attack's feasibility is enhanced as many RPs, such as Facebook and GitHub, do not require attestation, which simplifies key replacement. If attestation is required, A1 would need a legitimate HSK of the same make/model and automate the key tap, which is achievable.

Attack 2: Double-binding attack during registration & authenticated session

• Exploited Flaws: Lack of confidentiality/integrity of FIDO2 messages (Flaw 1), User misunderstanding (Flaw 3).
• Mechanism:
• a) During registration: A1 first registers their malicious authenticator to the victim's account. Then, in the background, A1 sends a second registration request to register the victim's HSK to the same account. Both the victim and A1 can respond to their respective registration prompts. The victim logs in normally, unaware of the second, malicious HSK.
• b) During an authenticated session: More dangerously, A1 registers a malicious HSK to the victim's account without any victim involvement by sending a registration request and its response in the background while the victim is logged in. This establishes persistent access. A strong defense would be requiring authentication with an already-registered HSK before adding a new one, but the analysis showed four out of ten popular web services don't require any authentication, and five require only a password for this operation. Twitter uniquely prevents this by allowing only one HSK. Email notifications for new HSK registrations are often generic and identical, making it difficult for users to detect two registrations.

Attack 3: Synchronized login

• Exploited Flaws: User misunderstanding (Flaw 3).
• Mechanism: While the victim is logged into a website with their HSK, Adversary A1 generates a login request for another victim account (e.g., facebook.com) expecting HSK authentication. This second login is rendered in an invisible iframe. A1 bypasses cross-origin iframe restrictions by adding allow="publickey-credentials-get " to the iframe and a Permissions-Policy: publickey-credentials-get= header in the response from the target RP. The user is then coerced into performing the user presence test (e.g., tap HSK) for the invisible login, believing it's for their current site or a failed attempt. Browsers display the domain for authentication prompts, but users frequently overlook this. This attack uses the victim's HSK without registering the attacker's, leaving less forensic evidence. If passwordless authentication is enabled, A1 doesn't even need a stolen password.

Attack 4: MITM (Man-in-the-Middle)

• Exploited Flaws: Lack of confidentiality/integrity of FIDO2 messages (Flaw 1), User misunderstanding (Flaw 3).
• Mechanism: This is a practical demonstration of the previously theoretical parallel session attack for FIDO UAF. When a victim visits an RP (e.g., facebook.com), A1 manipulates the authentication process. If the victim is logged in, A1 can forcibly log them out by removing session details. A1 generates a session from their own device and initiates an authentication request to the victim's account. A1 intercepts the victim's authentication request, replaces it with their own device's request, obtains the victim's signature using the victim's HSK, transfers the response to their device, and creates a login session on the victim's account. If the victim had an existing session, A1 re-injects those details to maintain the victim's login. If not, A1 can temporarily share their session or use a variant of Attack 3, prompting the user to tap their HSK twice—once for the victim's session, once for A1's.

Attack 5: Signature algorithm downgrade

• Exploited Flaws: Lack of confidentiality/integrity of FIDO2 messages (Flaw 1).
• Mechanism: During registration, A1 modifies the list of signature algorithms sent by the RP to the WebAuthn client, leaving only the least secure algorithm. While all ten web services analyzed use secure signing algorithms, seven still support RSASSA-PKCS1-v1_5 using SHA-256, which has known vulnerabilities (e.g., Bleichenbacher's attack) allowing arbitrary message signing if insecure exponents are used. Although currently theoretical, downgrade attacks often become exploitable years later as algorithms become outdated, highlighting a latent threat in FIDO2.

Attack 6: Cookie Lifecycle

• Exploited Flaws: Cookie life cycle (Flaw 4).
• Mechanism: RPs use "Remember this device" cookies to enhance usability by reducing 2FA prompts. Adversary A1 can steal these long-term session cookies. An analysis of 246,345 Chrome extensions found 31,326 with cookies permission, and 18,024 of those also have :// permission, enabling them to steal cookies from any* RP. 102 of these extensions have over a million users. The researchers demonstrated this by logging into Facebook with 2FA, enabling "Remember this device," then copying the 'datr' cookie (which can last approximately two years) to another browser. They successfully authenticated with just a password, bypassing 2FA. This well-known cookie-stealing attack, when combined with FIDO2, allows A1 to bypass 2FA without needing the hardware authenticator.

Attack 7: Bypassing clone detection algorithm

• Exploited Flaws: Broken clone detection algorithm (Flaw 2), User misunderstanding (Flaw 3).
• Mechanism:
• a) Lack of informative error message: When Adversary A2 authenticates with a cloned HSK, the RP should detect it due to a lower counter value. However, experiments simulating cloned HSKs on ten RPs showed most displayed generic error messages (e.g., "Security key authentication failed" or "Couldn't connect to your security key"). None explicitly stated a cloning attack. This leads users to reattempt login, which can eventually succeed as the counter increments on the HSK. Users don't understand the real cause and may switch to less secure authentication methods.
• b) Stealthy device cloning attack (Novel): Assuming the user's HSK and the RP have an account-specific counter x. A2 clones the HSK (also counter x). A2 then increments the counter on the victim's original HSK by y using dummy authentications. The victim's HSK counter becomes x+y, while the cloned HSK and RP counters remain x. A2 can now log in to the user's account up to y times without detection. When the victim eventually logs in, they won't trigger an error if x+y is greater than x plus A2's login count. The RP's counter will then update to x+y, providing A2 a window of undetected access.

Demo / Proof of Concept

▶ Watch: Four fundamental FIDO2 security flaws revealed (5:00)

To demonstrate the practical feasibility of these seven attacks, the researchers built a prototype of a malicious Chrome extension. This extension compromises the WebAuthn client by using content scripts to intercept and modify FIDO2 communication. Specifically, it overrides Chrome's navigator.credentials.create API function with a custom handler on every webpage. This handler then modifies or replaces the original FIDO2 request or response with a malicious one, enabling the execution of attacks like mis-binding, double-binding, and signature algorithm downgrade.

The scope of potential real-world impact was assessed by analyzing the permissions requested by 246,345 Chrome extensions extracted by CRXcavator:

• 115,881 Chrome extensions (47% of the total) use activeTab or tabs permissions, which are sufficient to execute a MITM attack by overriding WebAuthn client APIs. Alarmingly, 404 of these extensions have over one million users each, indicating that a single compromised extension could launch attacks against millions.
• For cookie-stealing (Attack 6), 31,326 extensions possess cookies permission, and 18,024 of these also have :// permission, allowing them to steal cookies from any* Relying Party. Again, 102 of these have over one million users.

While prior research by NinjaLab and Roth et al. demonstrated the feasibility of obtaining an HSK clone (Adversary A2), this work focused on demonstrating how to bypass the FIDO2 clone detection algorithm once a clone is acquired.

The researchers also investigated the applicability across different browsers. The tabs/activeTabs permissions operate uniformly, enabling all attacks except for the synchronized login (Attack 3). Attack 3 specifically requires the publickey-credentials-get API, which is supported by Chrome, Edge, and Samsung Internet, but is still experimental in Firefox. All attacks were successfully tested on Firefox except Attack 3. Furthermore, all browser extension-based attacks (except Attack 3) were confirmed to be exploitable through Cross-Site Scripting (XSS), although Attack 3 would require an XSS-based attacker to employ other techniques for header injection.

It is important to note that despite demonstrating the feasibility, the static and dynamic analysis of 152,526 real Chrome extensions found no evidence of these specific FIDO2 attacks occurring in the wild as of the research period. This highlights the proactive nature of the research, aiming to address vulnerabilities before widespread exploitation.

Defensive Implications

▶ Watch: First attack: Mis-binding during FIDO2 registration (6:00)

The research provides critical insights for strengthening FIDO2 against local attacks, leading to an improved clone detection algorithm and practical recommendations for RPs and browsers.

Improved Clone Detection Algorithm

Given the vulnerability of the current counter-based clone detection algorithm to stealthy cloning attacks (Attack 7b), the researchers propose an improved hash-based clone detection algorithm for account-specific counters. This algorithm aims to prevent and detect such attacks while maintaining backward compatibility with FIDO2 and avoiding false positives from lost or delayed messages.

On the HSK (Algorithm 1):

1. During registration, the HSK saves a hash of the challenge it receives, denoted as hashC.
2. During subsequent authentication requests, the HSK includes the previously saved hashC in its response.
3. Immediately after sending the response, the HSK updates its hashC by hashing the current authentication request challenge.

On the Relying Party (RP) (Algorithm 2):

1. The RP maintains a linked list of hashed challenges it has sent to the HSK, called hashList.
2. During registration, after sending the challenge, the RP adds hash(request.Challenge) to hashList.
3. During authentication, after sending the challenge, the RP also adds hash(request.Challenge) to hashList.
4. Upon receiving an authentication response from the HSK, the RP searches hashList for the hashC value included in the HSK's response.
5. Clone Detection:

• If the RP does not find resp.hashC in hashList, a cloning attack is detected.
• If resp.hashC is found, the HSK is legitimate. The RP then removes all items from the head of hashList up to and including the matching hashC. This sliding window approach gracefully handles lost or delayed messages.

Security Claim: This algorithm ensures that if a cloned device authenticates, it will submit an older hashC that the RP will detect as out of sequence or missing from its hashList, triggering an alert. Conversely, if the original HSK authenticates after a clone, it will also submit an older hashC from before the cloning, leading to detection. An attacker cannot bypass detection by guessing random challenge hashes, as this is computationally infeasible (1 in 2^256 probability), providing a robust defense against stealthy cloning.

Recommendations

Based on their findings, the researchers offer several recommendations for RPs and browser developers:

For Relying Parties:

1. Include and Highlight Nicknames, Make & Model in Email Notifications: RPs should send a notification to the account owner after every HSK registration. This notification should prominently display the nickname, make, and model of the HSK, along with the total number of registered HSKs. This would significantly help users detect the registration of an unrecognized HSK (Attack 2) and potentially Attack 1 if the adversary uses a different HSK.
2. Require HSK Authentication Before Adding a Second HSK: To prevent malicious HSK registration in the background (Attack 2b), RPs should require authentication with an already-registered HSK before allowing a new HSK to be added. If a user loses their HSK, they would first need to remove the lost HSK using less secure authentication methods (like a password) during an already logged-in session. This ensures either the attacker cannot register their HSK, or the victim detects the removal of their HSK.
3. Provide More Specific Context in Error Messages: To mitigate Attack 7a, device cloning error messages should explicitly state: "The device is cloned," "Remove the cloned device from your account," and "Register another HSK." For mis-binding attacks (Attack 1), informative error messages explaining that a different key than the registered one was used would help users detect the issue or resolve it if they have multiple HSKs. Researchers should engage users to design and evaluate the effectiveness of such messages.

For Browsers:

1. Improve UX and Notifications: Browsers should explore more effective ways to alert users of potential attacks, especially for synchronized login (Attack 3) where users often miss the domain displayed in authentication popups or misinterpret multiple taps. This could involve more prominent warnings or clearer contextual information during authentication prompts.

These recommendations aim to address the identified flaws by enhancing user awareness and strengthening protocol-level defenses, making it significantly harder for local attackers to succeed undetected.

Key Takeaways

• FIDO2, while strong against remote threats, is vulnerable to local attacks from malicious browser extensions, XSS, and physical HSK cloning.
• Four fundamental flaws were identified: FIDO2 message integrity/confidentiality accessible to extensions, a broken clone detection algorithm, user misunderstanding from poor UX, and exploitable cookie lifecycles.
• Seven distinct attacks, including four novel ones, were demonstrated as practical, showing how attackers can mis-bind, double-bind, force synchronized logins, MITM, downgrade algorithms, steal long-lived cookies, and bypass clone detection.
• User studies overwhelmingly confirmed that current FIDO2 error messages, email notifications, and UX are insufficient for users to detect these sophisticated local attacks.
• An improved hash-based clone detection algorithm is proposed to robustly defend against stealthy HSK cloning attacks.
• Relying Parties and browser developers must implement better email notifications (with HSK details), require existing HSK authentication before adding new ones, and provide specific, actionable error messages to enhance FIDO2's security.

About the Speaker(s)

Tarun Kumar Yadav is a researcher who presented this detailed work on the security and usability analysis of local attacks against FIDO2 at the NDSS Symposium. His research focuses on critical security aspects of modern web authentication protocols, particularly FIDO2, with an emphasis on identifying and mitigating vulnerabilities arising from client-side compromises and physical attacks. His work contributes significantly to understanding the practical implications of these threats and proposing concrete defensive measures.