FIDO2 (Fast Identity Online) is a passwordless authentication method developed by FIDO Alliance to prevent Man-in-the-Middle (MiTM) attacks, Phishing attacks, and session hijacking attacks.
This FIDO2 authentication works using a physical or embedded key.
However, this secure passwordless authentication method has been discovered with a critical flaw that could allow attackers to perform MiTM attacks on FIDO2 devices and bypass the authentication.
Free Webinar on Live API Attack Simulation: Book Your Seat | Start protecting your APIs from hackers
When this authentication is bypassed, there is access to the user’s private area where several malicious activities can be performed, including removing the FIDO2 registered devices.
Passwordless Authentication Standard FIDO2 Flaw
According to the reports shared with Cyber Security News, FIDO2 works on a public key cryptography mechanism and WebAuthn authentication flow.
The client generates a private key and public key, which is then sent back to the relying party (Cloud application communication) for signature verification when signing in.
.webp)
The researcher conducted two attacks: session Hijacking and a Man-in-the-Middle attack on the IdP (Identity Provider).
When using FIDO2, users must either register a FIDO device at the relying party or make the browser perform a navigator.credentials.create() function.
.webp)
In turn, the FIDO device generates a private and public key for every single user and binds it to the domain origin.
The browser also validates this domain origin during the authentication process.
Moreover, the authentication steps involve the relying party calling the browser’s navigator.credentials.get() for every authentication request.
For each request, the browser calls the FIDO security key through CTAP (Client to Authenticator Protocol).
If the authentication is approved on the Authenticator by the user, a signature is generated using the security key, which is then verified by the RP using its public key.
.webp)
Nevertheless, during a phishing attack, the domain origin of the validated website is checked to ensure that it matches the registered origin.
If the origin does not match, the request will be dropped.
In case of a MiTM attack, certain prerequisites, like a trusted certificate on the victim, are required for the attacker to successfully intercept all the requests. However, this is prevented due to TLS.
Test Use Cases
Use Case 1: Yubico Playground
When FIDO authenticates the user, a cookie named “session” is generated, and there is a lack of validation on the device that generated the request.
This means that any device can use the cookie until it expires.
Further, acquiring this cookie also allows a threat actor to bypass authentication, reach the user’s private area, and remove the security key from the user’s profile.
.webp)
Use Case 2: Entra ID SSO
Entra ID SSO is capable of working with multiple SSO protocols.
Two of these were tested: Microsoft Applications over OpenID Connect (OIDC) protocol and an Example third-party application over the SAML protocol.
In both of these SSO authentications, a signed access token with an expiration time of 1 hour was passed via the POST attribute to the relying party.
However, the attacker can just get a signed token and use it at the right time frame to generate state cookies with longer times.
Additionally, the OIDC supports a refresh of tokens that can generate session tokens for an extended period.
Also, the Azure Management Portal application does not validate the token granted by the SSO.
Use Case 3: PingFederate
This is an umbrella application that supports multiple enterprise applications and uses several third-party adapters to perform authentication.
Combining these adapters form an authentication policy flow that contains several requirements to be met for successful authentication.
However, it has been observed that the relying party developer does not validate ODIC or SAML tokens, which could lead to successful MiTM attacks.
Mitigations
Researchers at Silverfort have recommended the following steps to mitigate these vulnerabilities:
- Use of Token Binding which allows applications and services to cryptographically bind their security tokens to the TLS layer
- Application developers are recommended to add binding to FIDO2 authentication if possible or limit the OIDC or SAML token to be used only once
- Application managers must require Token binding on FIDO2 authentication
- When designing an authentication mechanism, threat attribution must be understood appropriately and in critical cases, the direct approach is recommended to have more control over the session token.
On-Demand Webinar to Secure the Top 3 SME Attack Vectors: Watch for Free
