Full Report
Explore how passkey implementation gaps undermine security when relying parties fail to validate the User Verified flag, reducing MFA to a single factor. The post Pass the Passkey: A Novel Attack Surface in Passwordless Authentication appeared first on Unit 42.
Analysis Summary
# Vulnerability: Authentication Bypass via Improper UV Flag Validation in Passkeys
## CVE Details
- **CVE ID:** CVE-2024-34538
- **CVSS Score:** 7.5 (High)
- **CWE:** CWE-287: Improper Authentication
## Affected Systems
- **Products:** Various FIDO2/WebAuthn Relying Party (RP) libraries and implementations.
- **Specific Affected Library:** `python-fido2` (Versions prior to 1.1.3).
- **Configurations:** Systems using passkeys that rely on User Verification (UV) but fail to explicitly validate the `uv` (User Verified) flag in the authenticator data during the authentication ceremony.
## Vulnerability Description
The vulnerability arises from a logic flaw in how Relying Parties (web services) process FIDO2 authentication responses. Passkeys are designed to be Multi-Factor Authentication (MFA) by requiring "User Verification" (e.g., biometrics or a PIN) on the local device.
The flaw occurs when an RP requests User Verification (`userVerification="required"`), but fails to verify that the `uv` flag is actually set to `1` in the signed `authData` returned by the authenticator. An attacker with physical access to a device (or via a "passkey malware" scenario) can use an authenticator that ignores the UV request and returns a valid signature without requiring a PIN or biometric. Because the RP does not check the bit flag, it accepts the single-factor "possession" as a multi-factor "biometric/PIN + possession" login.
## Exploitation
- **Status:** PoC available (Conceptualized and tested by Unit 42 researchers).
- **Complexity:** Low (If an attacker has access to the authenticator or can use a "silent" virtual authenticator).
- **Attack Vector:** Physical / Local (Requires access to the authenticator/device to initiate the login).
## Impact
- **Confidentiality:** High (Full account access bypasses intended MFA).
- **Integrity:** High (Ability to modify account data).
- **Availability:** Low (Does not inherently crash services).
## Remediation
### Patches
- **python-fido2:** Updated to version **1.1.3**, which now enforces the check of the `uv` flag if User Verification is required.
- **General:** Developers using other WebAuthn libraries should ensure their implementation follows the FIDO2 specification to verify the `uv` bit in the `authenticatorData` byte string.
### Workarounds
- **Strict Policy Enforcement:** Manually implement a check in the backend logic to ensure `authData.flags.uv === true` whenever the authentication policy requires it.
- **Attestation Filtering:** Only allow authenticators (AAGUIDs) known to strictly enforce hardware-level user verification.
## Detection
- **Indicators of Compromise:** Authentication logs showing successful logins where the requested `userVerification` was "required" but the resulting metadata (if logged) shows the `uv` flag as false.
- **Detection Methods:**
- Audit WebAuthn Relying Party code for calls to verify signatures that omit the verification of flags.
- Use security scanning tools to test WebAuthn endpoints with a modified virtual authenticator that returns `uv=0` when `uv=1` is expected.
## References
- **Unit 42 Research:** hxxps[://]unit42[.]paloaltonetworks[.]com/passwordless-authentication-security-risks/
- **FIDO Alliance Spec:** hxxps[://]fidoalliance[.]org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html
- **GitHub Advisory (python-fido2):** hxxps[://]github[.]com/Yubico/python-fido2/security/advisories/GHSA-8cf6-p9f3-4rf2