SSO Wars: The Token Menace

Overview: Alex Emeril and Alvaro Muñoz present an in-depth security analysis of delegated authentication and Single Sign-On (SSO) token processing within the Microsoft .NET Framework. The researchers investigate how Service Providers parse and validate cryptographic tokens, identifying severe design flaws in .NET token handling libraries. Their talk demonstrates two critical vulnerabilities: an arbitrary constructor invocation flaw via unvalidated cryptographic algorithm resolution and a complete SAML signature bypass arising from "key confusion."

Key Topics: - Delegated authentication architecture: Identity Providers (IdP), Service Providers (SP), and signed tokens - Arbitrary constructor injection via CryptoConfig.CreateFromName in .NET - Target exploitation on Microsoft SharePoint and Microsoft Exchange Server - SAML XML signature bypass via asymmetric ResolveSecurityKey and ResolveSecurityToken evaluation

Technical Details: In delegated authentication architectures, a Service Provider offloads user verification to an Identity Provider, which issues signed tokens (such as SAML, JWT, or Simple Web Tokens). The researchers focused their vulnerability research on the Service Provider's token intake and verification pipeline, targeting flaws that execute prior to or directly subvert cryptographic signature validation.

The first vulnerability involves cryptographic token parsing in the .NET Framework. To instantiate objects representing cryptographic algorithms, libraries routinely invoke CryptoConfig.CreateFromName. However, the researchers discovered that CreateFromName failed to restrict type names, allowing callers to execute any public, parameterless constructor of any class accessible in the application context. This unvalidated reflection entry point can be reached before signature verification via untrusted token headers, such as the alg attribute in System.IdentityModel.Tokens.Jwt or the Algorithm attribute within SAML SignatureMethod elements. When tested against Microsoft SharePoint, this primitive allowed unauthenticated attackers to fingerprint installed software components, determine exact versions, and trigger denial-of-service exceptions; against Microsoft Exchange Server, authenticated users could instantiate arbitrary constructors across local DLLs.

The second vulnerability exploits architectural asymmetry during SAML XML signature verification in Windows Communication Foundation (WCF) and SamlAssertion handlers. XML signatures contain a KeyInfo element that specifies the key or key reference required for verification. The .NET implementation queries KeyInfo twice: first calling ResolveSecurityKey to obtain the cryptographic key for mathematical signature validation, and subsequently calling ResolveSecurityToken to establish the identity of the signing party. However, ResolveSecurityKey traverses candidate keys using a depth-first search (iterating through all keys in KeyInfo first), whereas ResolveSecurityToken iterates through available resolvers first. By crafting a malformed KeyInfo element containing competing key definitions, an attacker creates a "key confusion" state where the server verifies the mathematical signature using an attacker-supplied key while simultaneously validating the token's origin as the legitimate Identity Provider, completely bypassing SAML authentication.

Key Takeaways: Developers using .NET cryptographic frameworks must ensure type resolution routines enforce strict whitelists of permitted algorithm identifiers rather than accepting arbitrary class names from unauthenticated token headers. Security teams must ensure SAML and XML signature libraries use atomic, consistent key resolution pathways that bind cryptographic validation directly to identity verification. Systems processing federated identity tokens must be patched to prevent key confusion attacks that allow complete signature circumvention.

(AI summary — Gemini Flash)