SAML Vulnerabilities: Canonicalization and DOM traversal

Jeff Hickman
February 28, 2018

Get the latest from the SecureAuth Blog

On February 27th, 2018 Duo Security posted a blog about a vulnerability they found in a number of SAML libraries used by a number of vendors, developers, and enterprises alike.

These findings are tied to a number of Common Vulnerabilities and Exposures (CVE) depending on the library or product affected. The filling can be found here:

After receiving notification of this vulnerability, SecureAuth’s Research and  Engineering teams dove into action to uncover if SecureAuth products that support SAML were affected.

We can happily inform the public that all SecureAuth products are not affected by this vulnerability. Our official customer notification can be found here.

To understand the nature of this vulnerability, Duo Security’s blog does a great job of explaining how the vulnerability is exploited and what specific details are. However, there are a few items that need to be explained in how an attacker could exploit this vulnerability and why the Common Vulnerability Scoring System (CVSS) rank assigned by CERT is a base of 6.3 (Medium Severity).

With the understanding gained from the Duo Security blog, the vulnerability has to do with the canonicalization of the XML elements that make up a SAML Response token. In simple terms, this is how programming code takes an XML document, such as the SAML Response, and converts it into an object that the code can work with. Over the course of software history, there have been a large number of vulnerabilities with parsing text into code that has been exploited time and time again, and this vulnerability is no exception.

The largest difference here is that the SAML Response XML is cryptographically signed. This means that in order to execute this vulnerability, the attacker must be able to create a SAML Response that is signed with the private key of the issuing Identity Provider. This presents some challenges to the attacker, they must compromise the Identity Provider server, or have an account that exists with the Identity Provider to create a signed SAML Response. Hence the recommendation by Duo Security to be wary of Identity Providers that have unprotected or open user registration. Even if the user that is registered is not authorized to access each of the federated applications offered, using the vulnerability the attacker can simply impersonate any user they choose without compromising said user’s credentials.  Once again, we fall back to the use of stolen credentials as the avenue of attack. The need for strong authentication in the use of federation cannot be understated.

With SecureAuth’s Adaptive Authentication, the attack surface for an attacker is extremely limited. By validating where the user is attempting to authenticate from, where they have previously authenticated and when, the device they are using, the threat and reputation of the IP address of the user, their roles and groups inside of the organization, and others, SecureAuth can protect the access to gaining federated access to any application.

To learn more, please visit our Adaptive Authentication page or contact us to speak with an expert.

Related Stories

Pin It on Pinterest

Share This