FIDO2 is a modern authentication group term for passwordless authentication. The Fast Identity Online (FIDO) Alliance developed it to replace the use of legacy known passwords and provide a secure method to authenticate using a physical or embedded key.  

FIDO2 is mostly known to protect people from man-in-the-middle (MITM), phishing and session hijacking attacks.  

In this article, I’ll take you through my research uncovering how to use MITM attacks to bypass FIDO2. First, I will outline a complete WebAuthn authentication flow, then walk through the protections of FIDO2. Then I will tackle famous attack techniques and provide real-life use cases. Lastly, I will discuss mitigations and what you can do to protect your enterprise.   

But first, some background

The FIDO2 authentication flow consists of the WebAuthn API specification for a client relying party (RP) – which is the cloud application communication – and Client to Authenticator (CTAP) protocol for hardware communication. The entire process is managed by the browser and consists of two authentication steps: device registration and authentication.  

It is constructed this way because FIDO2 is based on a public key cryptography mechanism. This is where the client generates a private and public key and sends the latter back to RP for signature verification upon sign in. FIDO can be applied as an authentication method for a single application or in a federation. For those who don’t know, a federation refers to a single sign on (SSO) for multiple unrelated applications managed by a single identity provider (IdP).  

FIDO2 security features 

FIDO2 is famous for its security features, mainly for preventing phishing, man-in-the-middle and session hijacking attacks.  

As part of my research, I wanted to see if FIDO2 is immune to these attacks – and I was surprised by the results. I started with session hijacking, an attack technique where the adversary steals a browser’s session to gain access to the user’s application and private data. The second attack I investigated was a man-in-the-middle (MITM) attack on the IdP, where an adversary eavesdrops, modifies and relays communications between two devices that believe they are transmitting directly to each other.  

Today, MITM is more difficult to accomplish thanks to TLS protection. Even so, there are many methods to achieve a MITM, including DNS /DHCP spoofing, ARP poisoning and SLAAC. In addition, state actors have been known to overcome and decrypt TLS by stealing an organization’s certificate. One example is by attacking Active Directory Certification Services. 

FIDO was designed to prevent these attacks. However, when implementing this modern authentication method, most applications do not protect the session tokens created after authentication is successful. I discovered many identity providers are still vulnerable to MITM and session hijacking attack types.  

To understand how this works, we need to go back to basics. 

Over time, the basics of web communication have hardly changed. HTTP protocol and its features are broadly used over the World Wide Web, including the use of GET and POST to transfer attributes between endpoints and cookies to keep a session state for a client. Web applications and SSO protocols such as OIDC and SAML rely on the HTTP protocol and are required to follow its guidelines to keep a client state. Over the years, security over user sessions has improved in terms of how it is kept locally by the browser and how the application calculates it. However, these changes are not enough.  

How exactly does FIDO2 protect you? 

For a successful FIDO2 authentication, the user must either register the FIDO device at the relying party or order the browser to perform a navigator.credentials.create() function. This instructs the FIDO device to generate a private and public key for a specific user and bind it to a domain origin. The browser can then validate the domain origin of the relying party during the authentication process.  

Next is the authentication step, where the relying party calls the browser’s navigator.credentials.get() for each authentication request. Once it’s triggered by the RP, the browser communicates with the FIDO security key through CTAP. If authentication is approved by the end user, the security key generates a signature using the stored private key. This signature is later verified by the RP using its public key. 

In a phishing attack on a website with a different URL, the domain origin of the validated website will prevent potential credential theft because the URL doesn’t match the registered origin. However, the MITM attack mechanism is different. The prerequisite for an MITM attack is to have a trusted certificate by the target victim. Most modern browsers will alert and force secured authentication over TLS to a remote website. A successful MITM attack exposes the entire request and response content of the authentication process. When it ends, the adversary can acquire the generated state cookie and hijack the session from the victim. Put simply, there is no validation by the application after the authentication ends.  

Test use cases 

I decided to take Entra IdP, PingFederate and Yubico as research use cases. Each operates differently and has its own pros and cons.  

Use case 1: Yubico Playground 

The Yubico Playground was created to demonstrate and test FIDO security features and keys. In this example, FIDO authenticates the user directly over HTTP to a local user database. Upon successful authentication, a cookie named “session” is generated. There is no validation on the device that requested this session, and any device can use this cookie until it expires. Acquiring this cookie could allow the adversary to bypass the authentication step, reach the user’s private area and, in this case, remove the security key from the user’s profile. This is a simple example of session hijacking; as we go to more complicated scenarios, we will see how this method shifts.  

Use case 2: Entra ID SSO 

The second use case is Entra ID SSO, which has security capabilities to authenticate over various SSO protocols and other modern authentication methods. Its Conditional Access – authentication strength feature limits passwordless mechanisms – specifically FIDO2. Our test validated native Microsoft applications such as Office 365 and Azure Management portal over OpenID Connect (OIDC) protocol and Example 3rd party application over SAML protocol. In both federation protocols, the IdP provides a signed access token with an expiration time of 1 hour that is passed as a POST attribute to the relying party. In the federation mechanism, the adversary doesn’t even have to relay the authentication process. The attacker just needs a signed token, and it can be used again in the right time frame and generate state cookies within a longer time frame. OIDC supports refresh tokens which can generate session tokens for an extended period. 

We can see in the following example that the native Azure Management portal application does not validate the token granted by the SSO. 

Use case 3: PingFederate 

The third use case is PingFederate. This umbrella application provides federation SSO for a large variety of enterprise applications. Unlike Entra, Ping uses third-party adapters to perform authentication. These adapters can be chained into an authentication policy flow. Each adapter has its own context and is separated from the other. Successful authentication is where a user meets the requirements of all the adapters in the policy. FIDO2 capabilities can be used with the PingOne adapter. Surprisingly, our team discovered that if the relying party developer doesn’t validate the OIDC token (or SAML Response), the outlined MITM attack will be successful.  

Authentication weakest link 

The SSO use cases are more severe from the direct approach. As more players are involved in the authentication process, the relying party has less control of validating the integrity of the source device. Even though FIDO protects against MITM attacks, the whole chain relies on its weakest links, which are the SSO protocols where their granting tokens can be reused by a different device. 

Mitigations and next thoughts 

What if there was a way to verify that the authenticated session is used solely by the authenticated client? Introducing Token Binding, a proposed standard requested in 2018. 

Token Binding allows applications and services to cryptographically bind their security tokens to the TLS layer to mitigate token theft and MITM attacks. Token Binding v1.0 will bind the entire session to its underlying TLS handshake. The public key cryptography extends beyond the authentication context, and WebAuthn will securely deliver the token binding signature.  

But how does Token Binding work? 

• Upon Client-Server Hello, a Token Binding extension is available. 
• The two endpoints agree on TLS fields that the client will sign.  
• Exactly like in WebAuthn, the browser creates a long-lived private/public keypair.  
• The client sends the public key to the RP for signature verification; then the signature is sent over the application layer.  
• The server verifies the signature and binds it to the session token. 

I initially conducted this research in Mid-2023, and submitted the findings to Microsoft. In response to initial disclosure, Microsoft claimed this is not a vulnerability. Even so, it is an attack surface that could cause damage to an exposed organization. Four months later, Microsoft presented a conditional access preview of Token Protection, which is a variant of token binding specifically for Trusted Platform Module (TPM). In its documentation Microsoft explains that token theft is rare, but the damage from it can be significant. In the case of web applications, TPM may act similarly to FIDO using a different communication method to the security chip. However, WebAuthn protocol stays the same for browser and RP communication. The current preview is limited to specific Web applications and Windows client versions. The current configuration is cumbersome, and in the future Microsoft will expand the feature to generic FIDO security keys. 

To date, Microsoft EDGE is the only browser that offers Token Binding.  Chrome offered Token Binding but removed it due to low adoption.  

Token Binding’s proposal discusses two types of device binding. One for direct authentication is called Provided Token Binding. This type is common in simple applications like the Yubico playground. The second type, Referred Token Binding discusses the protection of both the Identity provider and the relying party.  In any of the cases, WebAuthn may pass the Token Binding signature securely on the authentication phase.  

It is recommended for application managers to require Token Binding on a FIDO2 authentication, if available.  

When designing an authentication mechanism, you need to understand your threat attribution and build your authentication accordingly. In sensitive cases, the direct approach is recommended as the application may have more control over the session token. 

For application developers, we recommend adding token binding to the FIDO2 authentication process if possible, or at least limit the OIDC token or SAML response usage of each successful authentication to be used once.  

It is concerning that the great security features of FIDO2 are not protecting the entire user session. It is important to understand that modern authentication methods are not a magic security charm, and it is not enough just to buy and implement – you need to deeply understand its pros and cons. 

To learn more about Silverfort, get a demo here.

The post Using MITM to bypass FIDO2 phishing-resistant protection appeared first on Silverfort.

*** This is a Security Bloggers Network syndicated blog from Silverfort Blog - Cyber Security News authored by Dor Segal. Read the original post at: https://www.silverfort.com/blog/using-mitm-to-bypass-fido2/