Beginner’s Guide to Bypassing Modern Authentication Methods to SSO

Beginner’s Guide to Bypassing Modern Authentication Methods to SSO

Speakers: Dor

Conference: RSAC 2024

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

Overview

In an era where organizations increasingly rely on robust authentication mechanisms to secure their digital assets, this talk by Dor at RSAC 2024 delves into a critical, often overlooked, vulnerability: the post-authentication session. While modern methods like FIDO2 are widely advertised as security panaceas, especially against phishing and man-in-the-middle (MITM) attacks, Dor challenges this perception. The core premise of the presentation is that even the most advanced authentication, once completed, can leave the subsequent user session exposed to hijacking, particularly in complex Single Sign-On (SSO) environments.

The talk systematically deconstructs the architecture of modern authentication, specifically focusing on FIDO2 and its underlying protocols WebAuthn and CTAP. Dor demonstrates how an adversary, by intercepting and replaying session cookies or refresh tokens, can bypass the initial FIDO authentication entirely. This issue is magnified within federated SSO systems, where the security key might protect the Identity Provider (IdP) but fail to extend its cryptographic binding to the downstream Relying Party (RP) applications. The presentation serves as a crucial wake-up call for security professionals, urging them to look beyond the login screen and implement comprehensive session protection strategies.

The implications of this research are significant. As enterprises adopt passwordless and phishing-resistant authentication, there's a risk of developing a false sense of end-to-end security. Dor's work highlights that while FIDO excels at verifying the user's identity at the point of login, it does not inherently secure the continuous, active session. This gap necessitates a deeper understanding of session management and the adoption of advanced techniques like Token Binding or its successors, which aim to cryptographically link an authenticated session to the client's underlying TLS handshake, thereby making session hijacking considerably more difficult.

Background

▶ Watch: Introduction: Are modern authentication methods truly secure? (0:00)

Modern authentication methods were developed to address the inherent weaknesses of traditional password-based systems. These methods aim to bind a physical device to a virtual identity, validating the integrity of both the user and their device. Key protocols underpinning these systems include SAML, WS-FED, OpenID Connect, and OAuth, often extending familiar protocols like Kerberos or certificate-based authentication. Examples of modern methods include authenticator apps, time-based passcodes, third-party identity providers, and most notably, FIDO.

The talk focuses specifically on FIDO2, which is widely regarded as superior to legacy passwords due to its reliance on public key cryptography, inclusion of physical or biometric features, origin binding to prevent phishing, and its promise of a passwordless experience (though a PIN might still be required for the security device). FIDO2 leverages two primary protocols: WebAuthn and CTAP. WebAuthn facilitates communication between the browser and the relying party (the application), while CTAP handles communication between the browser and the physical security device itself.

The WebAuthn process involves two main steps: enrollment and sign-in.

1. Enrollment: This step binds the physical security key to the user's account. The relying party initiates this by triggering the browser's credentials.create() function. A signed challenge is sent to the browser. The client then locally creates a credential pair (a private and public key), associates it with the domain origin of the relying party, and generates a unique credential ID. The public key and credential ID, along with the server's challenge, are sent back to the relying party for storage. An optional attestation statement can validate the key's manufacturer.
2. Sign-in: For subsequent logins, the relying party triggers credentials.get(). The physical device uses its stored private key to sign a unique challenge, creating a unique signature for that authentication attempt. The relying party then uses the previously stored public key to validate this signature, confirming the user's identity. Upon successful sign-in, a session cookie is typically granted to the browser, allowing continued access to the application.

FIDO and WebAuthn incorporate several features specifically designed to protect against MITM and phishing attacks:

• Challenge: A unique challenge sent by the relying party must be returned as is, preventing replay attacks of the authentication request.
• Domain Origin: The authentication is bound to the specific domain origin, making it difficult for phishing sites (different domains) to trick users into authenticating.
• Attestation Protection: This validates that the physical key is manufactured by a legitimate provider, guarding against forged keys.

However, Dor highlights a critical limitation: while FIDO excels at protecting the integrity of the authentication process, it does not protect the authenticated session itself. Once the FIDO-protected authentication concludes and a session cookie is issued, the session's security relies on mechanisms other than FIDO. This creates a window of vulnerability where, if the session cookie is intercepted, an adversary can bypass the entire FIDO authentication and gain unauthorized access.

Key Findings

▶ Watch: Understanding WebAuthn: Enroll and sign-in steps (2:20)

Dor's research reveals several critical findings challenging the perceived end-to-end security of modern authentication methods, particularly in enterprise environments:

1. Session Hijacking Persists Beyond FIDO Protection: Despite FIDO2's robust protections against phishing and MITM during the authentication phase, these safeguards do not extend to the active, post-authentication session. Once a session cookie or session token is generated, an adversary who intercepts it can bypass the FIDO authentication entirely, gaining unauthorized access to the application. This is effectively cookie hijacking.

1. SSO Amplifies Vulnerability: In Single Sign-On (SSO) architectures, FIDO typically protects the Identity Provider (IdP), such as Entra ID SSO or Okta. However, the protection often does not extend directly to the Relying Party (RP) applications that consume tokens from the IdP. The FIDO origin (e.g., login.microsoft.com) is bound to the IdP, not the target application. This creates a "weakest link" scenario where the RP might only validate the token's signature from the IdP, without verifying the underlying client's context or cryptographic binding.

1. Token Replay Attacks are Effective: Adversaries can intercept and replay access tokens or, more critically, refresh tokens issued by the IdP. The talk demonstrated that even in high-security environments like the Azure management portal, replaying these tokens from a different browser (and implicitly, a different device or location) grants full access without further FIDO authentication. Refresh tokens, in particular, allow for long-term unauthorized access as they can generate new session tokens.

1. Lack of Robust Session Token Validation: A significant discovery was the observed lack of validation on session tokens by many applications. The demonstrations showed that intercepted tokens could be used from different browsers, locations, or user agents without triggering re-authentication or security alerts. This indicates that applications often trust the token implicitly once issued by a trusted IdP, failing to perform their own contextual validation of the client.

1. Federated Authentication Weakens End-to-End Security: The act of federating authentication, while convenient, can weaken the end-to-end security provided by modern methods. When multiple authentication methods are chained, the overall security relies on the weakest link. The relying party's inability to fully validate the session created by the identity provider, beyond merely checking its signature, is a critical flaw.

1. Proposed Solution: Token Binding: An existing RFC suggestion, Token Binding 1.0 (proposed in 2018), aims to address this by cryptographically binding a modern authentication to its underlying TLS handshake. This extends public key cryptography beyond the authentication context to the entire session, ensuring that the session cookie is unique to the specific client's TLS session. However, its adoption has been low, with Chrome dropping support and Yubico Playground adding and then removing it. Edge is currently the only major browser supporting it.

1. Microsoft's Token Protection Feature: Following Dor's MSRC report on bypassing modern authentication methods in Entra ID SSO, Microsoft introduced a "Token Protection" (preview) feature. This feature aims to bind tokens to the Trusted Platform Module (TPM), acknowledging the risk of token theft. While limited in current scope (specific Windows clients and applications like OneDrive, Teams, Power BI desktop, Visual Studio), it signifies vendor recognition of the problem and a move towards mitigating it.

Technical Deep Dive

▶ Watch: FIDO's advertised protection against MITM attacks (4:40)

The technical core of this presentation revolves around the interplay between WebAuthn, SSO protocols, and the post-authentication session management. Dor meticulously explains how FIDO's robust cryptographic protections, while effective for the initial login, do not extend to the subsequent session.

WebAuthn Mechanics and its Limitations:

As discussed in the background, WebAuthn's credentials.create() (enrollment) and credentials.get() (sign-in) functions leverage public-key cryptography. During enrollment, a unique public/private key pair is generated on the user's device, with the public key stored by the relying party (RP). For sign-in, the device uses its private key to sign a challenge, and the RP verifies this signature with the stored public key. This process is secured by:

• Unique Challenges: Prevents simple replay of authentication requests.
• Origin Binding: Ensures the authentication only occurs with the legitimate domain, thwarting phishing sites.
• Attestation: Verifies the authenticity of the security key hardware.

However, the critical point is that these protections apply only to the act of authentication. Once the authentication is successful, the relying party issues a session cookie (or a session token in more complex scenarios). This cookie is then used by the browser for all subsequent requests to maintain the user's authenticated state. FIDO’s cryptographic binding ends here; the session cookie itself is not inherently cryptographically bound to the client's device or TLS session by FIDO.

Session Hijacking in Detail:

Session hijacking, also known as cookie hijacking, occurs when an adversary intercepts this session cookie. Because the cookie represents an active, authenticated session, the adversary can then present this cookie to the web application, effectively impersonating the legitimate user without needing to re-authenticate with FIDO. The application, seeing a valid session cookie, grants access. This attack occurs after the FIDO authentication has successfully protected the login process. The adversary's context is after the session cookie is created, operating outside the FIDO-protected authentication flow.

SSO Integration and the "Weakest Link":

Real-world scenarios often involve Single Sign-On (SSO), where users authenticate once to an Identity Provider (IdP) (e.g., Entra ID SSO, Okta, PingFederate) and gain access to multiple Relying Party (RP) applications. SSO typically operates over protocols like OpenID Connect and SAML.

In an SSO setup with FIDO:

1. The user attempts to access an RP application.
2. The RP redirects the user to the IdP for authentication.
3. The user authenticates with FIDO at the IdP's federation endpoint. Crucially, the domain origin for FIDO is the IdP's domain (e.g., login.microsoft.com), not the RP's domain.
4. Upon successful FIDO authentication, the IdP issues an access token (and often a refresh token) to the user's browser.
5. The browser then presents this token to the RP. The RP validates the token's signature (ensuring it came from the trusted IdP) and then issues its own session cookie to the client.

The vulnerability arises because FIDO's origin binding protects the IdP, but the token issued by the IdP, and subsequently the session cookie issued by the RP, may not retain the same cryptographic binding to the client's device or TLS session. The RP typically trusts the IdP's assertion and does not have the "power" to validate the full context of the FIDO authentication performed at the IdP. This creates a "weakest link" in the chain: if the access token or refresh token can be intercepted and replayed, the adversary bypasses FIDO entirely. Refresh tokens are particularly dangerous as they can generate new session tokens, extending unauthorized access for potentially long durations.

State Actors and MITM:

Dor emphasizes that while TLS has made general MITM difficult, it is not impossible, especially for sophisticated adversaries like state actors. They may possess capabilities such as stealing root certificates or exploiting vulnerabilities in services like Active Directory Certification Services, allowing them to decrypt TLS traffic and intercept session tokens. The speaker argues that designing authentication methods should account for these advanced threat models.

Token Binding as a Solution (and its challenges):

To address this, the speaker introduces Token Binding 1.0, an RFC suggestion from 2018. This mechanism aims to cryptographically bind an authenticated client to its underlying TLS handshake.

• How it works: During the Client-Server Hello phase of the TLS handshake, if both endpoints support Token Binding, they agree on specific TLS fields. The client then creates a long-lived private/public key pair (similar to WebAuthn). This private key is used to sign a unique value derived from the TLS session. This Token Binding signature, along with the public key, is sent over the application layer (e.g., within the WebAuthn response or alongside the session token).
• Verification: The server verifies this signature using the public key and binds it to the session token. This makes the session cookie unique to that specific TLS session and client device. If an adversary steals the session cookie and tries to use it from a different TLS session (e.g., from their own browser), the Token Binding signature will not match, and the request will be rejected.
• Types: Provided Token Binding (for single RPs) and Referred Token Binding (for SSO scenarios, binding both IdP and RPs).

However, Token Binding faces significant practical challenges, as highlighted during the Q&A:

• Low Adoption: Chrome dropped support in version 70 due to low adoption, and Yubico Playground removed it. Edge is the only major browser still supporting it.
• Scalability/Portability Issues: Binding a session to a specific TLS handshake creates issues with modern cloud environments where servers are ephemeral, scale dynamically, and clients move between networks (e.g., cafe to home). The TLS session parameters change frequently, potentially forcing re-authentication.
• DPoP (Distributed Proof of Possession): A successor to Token Binding, DPoP is being explored to address these portability issues by using cryptographic primitives based on hardware/host-based security but without tying them directly to the TLS session.

Demo / Proof of Concept

▶ Watch: Adversary context for session hijacking post-authentication (6:30)

Dor presented two compelling demonstrations to illustrate the session hijacking vulnerability, first in a direct FIDO authentication scenario and then within an Entra ID SSO environment.

1. Hijacking Demonstration on Yubico Playground:

• Scenario: The speaker chose Yubico Playground, a simple application designed to showcase FIDO's security features, as it authenticates directly with FIDO without additional players. The speaker logged into the Yubico Playground using a FIDO security key (requiring a PIN, as it lacked biometric features) and successfully signed in.
• Adversary Action: The speaker, acting as an adversary, utilized Fiddler to safely decrypt the entire TLS session between the browser and the Yubico Playground. After decryption, a browser extension was used to "steal" the session cookie that was granted post-authentication.
• Outcome: The stolen session cookie was then injected into a different browser. Crucially, there was "no validation on either the browser or actually anything." The adversary successfully logged in, bypassing the FIDO authentication entirely. The demonstration went further, showing that with this hijacked session, the adversary could access sensitive user data and even remove the victim's security key from their profile, effectively locking them out and demonstrating full control over the account. This vividly illustrated that FIDO protects the login, but not what happens after the login.

2. MITM Attack in Entra ID SSO (Azure Management Portal):

• Scenario: This demonstration showcased the attack in a more complex, real-world enterprise setting: authenticating to the Azure management portal via Entra ID SSO. The speaker authenticated using their FIDO security key and PIN code, successfully signing into the portal.
• Adversary Action: Again, Fiddler was used to decrypt and intercept the traffic. The adversary successfully extracted the session token (or access token) that Entra ID SSO issued after FIDO authentication. The speaker noted that while session tokens might default to an hour's validity, refresh tokens (a concept in OpenID Connect) could grant unauthorized access for much longer periods by generating new session tokens.
• Outcome: The intercepted token was then replayed from a different browser. The speaker explicitly demonstrated changing the browser to highlight the lack of validation. The critical finding was that there was "no validation of the browser or location or number of usages." The modified network packet (containing the stolen token) was allowed to continue, and the adversary successfully gained unauthorized access to the private data and resources within the Azure management portal, completely bypassing the modern FIDO authentication.

These demonstrations served as compelling proof-of-concept for the core argument: FIDO secures the initial authentication step, but the subsequent session, especially in federated SSO environments, remains vulnerable to hijacking if robust session-level protections are not in place.

Defensive Implications

▶ Watch: Beginning of session hijacking demonstration on Yubico Playground (7:00)

The findings presented by Dor highlight a critical gap in the perceived end-to-end security of modern authentication methods and necessitate a shift in defensive strategies. Defenders should consider the following implications and actions:

1. Extend Security Beyond Authentication: The primary takeaway is that security measures cannot end at the login prompt. While FIDO2 provides excellent protection against phishing and replay during authentication, organizations must implement robust controls to protect the entire authenticated session. This requires focusing on session management and session token integrity.

1. Implement Comprehensive Session Token Validation: Applications and Identity Providers should implement advanced validation mechanisms for session cookies and tokens after they have been issued. This could include:

• Device Fingerprinting: Binding sessions to specific device characteristics (though this can impact user experience with legitimate device changes).
• IP Address/Location Monitoring: While challenging with dynamic IPs and VPNs, monitoring for sudden, geographically improbable changes in IP address can indicate hijacking.
• User Agent Validation: Detecting significant changes in the user-agent string during an active session.
• Behavioral Analytics: Monitoring for anomalous user behavior within a session that deviates from typical patterns.
• Token Binding or DPoP: Explore and adopt cryptographic binding mechanisms like Token Binding (if browser support and scalability issues can be managed) or its successor, DPoP (Distributed Proof of Possession), which aims to cryptographically link an access token to the client's proof-of-possession key, making tokens non-transferable.

1. Strengthen SSO Integrations: In federated SSO environments, Relying Parties (RPs) should not blindly trust tokens from Identity Providers (IdPs). While validating the IdP's signature is crucial, RPs should also:

• Implement their own contextual validation of the client using the token.
• Explore ways to propagate stronger client context or cryptographic binding from the IdP to the RP.
• Understand that adding more authentication methods to an SSO chain does not necessarily increase overall security if the weakest link (session protection) remains unaddressed.

1. Adopt Microsoft's Token Protection Feature (if applicable): For organizations using Entra ID SSO, leveraging the "Token Protection" (preview) feature is a direct mitigation. This feature binds tokens to the Trusted Platform Module (TPM), making them non-exportable. While currently limited to specific Windows clients and applications, its adoption where feasible is recommended. Defenders should monitor its development and expanded availability.

1. Be Wary of Refresh Token Abuse: Given the demonstration of refresh token replay, it is critical to implement strong controls around refresh token issuance, revocation, and validation. Consider shorter refresh token lifetimes or more stringent re-authentication requirements for their usage, especially when detecting suspicious activity.

1. Embrace Zero Trust Principles: The findings reinforce the need for a Zero Trust security model. Instead of trusting a session implicitly after initial authentication, organizations should continuously verify the user, device, and context throughout the session lifecycle.

1. Consider the Advanced Threat Landscape: Acknowledge that sophisticated adversaries, including state actors, possess capabilities to bypass TLS and intercept sensitive data. Defensive strategies must account for these high-level threats, not just common phishing attacks.

Key Takeaways

• FIDO2 and WebAuthn effectively secure the initial authentication process against phishing and replay attacks but do not inherently protect the post-authentication session.
• Session hijacking remains a critical threat, allowing adversaries to bypass modern authentication methods by intercepting and replaying session cookies or session tokens.
• In Single Sign-On (SSO) environments, FIDO typically protects the Identity Provider (IdP), but the security key's cryptographic binding often doesn't extend to the downstream Relying Party (RP) applications, creating a "weakest link."
• Token replay, especially of refresh tokens, can grant long-term unauthorized access without requiring the adversary to re-authenticate with the victim's FIDO key.
• Many applications, even high-security ones, currently lack robust validation of session tokens regarding device, location, or user agent after initial issuance.
• Solutions like Token Binding aim to cryptographically link session tokens to the client's TLS session, but face challenges with browser adoption and scalability; alternatives like DPoP are being explored.
• Defenders must shift focus to comprehensive session protection and leverage emerging features like Microsoft's "Token Protection" to secure the entire user journey, not just the login.

About the Speaker(s)

The speaker for this insightful presentation was Dor. Based on the content of the talk, Dor is a security researcher with a focus on modern authentication methods, particularly FIDO2 and Single Sign-On (SSO). Dor conducted original research into the vulnerabilities of these systems, specifically demonstrating session hijacking and token replay attacks against platforms like Yubico Playground and Entra ID SSO (Azure management portal). Notably, Dor submitted an MSRC (Microsoft Security Response Center) report detailing the bypass of modern authentication methods in Entra ID, which subsequently led to Microsoft's development of a "Token Protection" feature. While the transcript does not provide a specific title or company affiliation, Dor's work clearly positions them as an expert in dissecting and challenging the security posture of contemporary authentication architectures.