A behavioral quirk in SAML libraries has left many single-sign-on (SSO) implementations vulnerable to abuse. It allows an attacker that has gained any authenticated access to trick the system into granting further access as a different user without knowledge of that user’s password.
This could be used by an attacker who has compromised a low level limited access account to acquire access to third-party cloud services — or it could be used by a malicious insider seeking access to reserved network areas (such as the payroll databases, or HR records).
The vulnerability was discovered by the research team of Duo Security, itself an SSO provider; and is described in a blog posted today. It affects many of the leading SSO providers, and probably affects the majority of proprietary company SSO developments.
Duo has confirmed the flaw in OneLogin – python-saml (CVE-2017-11427); OneLogin – ruby-saml (CVE-2017-11428); Clever – saml2-js (CVE-2017-11429); OmniAuth-SAML (CVE-2017-11430); Shibboleth (CVE-2018-0489); and Duo Network Gateway (CVE-2018-7340).
Security Assertion Markup Language (SAML) is the underlying protocol used by most SSO implementations. It is what allows authentication to be passed between a company’s identity store and, for example, a third-party service. Typically, a user will log onto the identity store. This contains the credentials that will allow the same user to access other services.
SAML is used to pass authentication, via the browser, from the identity provider to the third-party service, granting access. The flaw lies in how authentication is encoded by SAML in the provider’s ‘response’.
The SAML authentication response contains two primary elements: the assertion and the signature. The assertion element says this NameID is authenticated. The signature element is designed to prevent the authenticated user NameID being changed at any point between the identity provider and the service being accessed. “If the attacker can modify the ‘NameID’ without invalidating the signature, that would be bad,” suggest the Duo researchers; and then proceed to explain how it can be done.
“One of the causes of this vulnerability is a subtle and arguably unexpected behavior of XML libraries like Python’s ‘lxml’ or Ruby’s ‘REXML’,” write the blog’s authors. Comments can be included in the signature, but the canonicalization process of the SAML libraries tend to drop all text after the first text node to isolate the NameID.
“So,” explain the researchers, “as an attacker with access to the account ‘user@user.com.evil.com’, I can modify *my own* SAML assertions to change the NameID to ‘user@user.com’ when processed by the SP.” The seven characters are inserted before .evil.com. This causes the canonicalization process to drop ‘.evil.com’, leaving the authenticated account as ‘user@user.com’.
Not all SSO implementations are vulnerable to this glitch; but Duo has demonstrated that many are. All that is required from the attacker is a genuine account that he can ‘modify’ to his attack target, plus the relatively minor technical savvy to intercept and edit the SAML authentication as it passes through the browser.
“Remediation of this issue,” notes the report, “somewhat depends on what relationship you have with SAML.” It gets a bit complicated. “Duo has released updates for the Duo Network Gateway in version? ?1.2.10?. If you use the DNG as a SAML Service Provider and are not at version 1.2.10 or higher (at the time of writing this, 1.2.10 is the latest version), we recommend upgrading.”
Different affected SSOs will have different specific recommendations, and it would be best to refer to them for guidance. Similarly, there are different recommendations for maintainers of identity or service providers, maintainers of SAML processing libraries, and maintainers of XML parsing libraries. One thing that would help, suggest the authors, is the ability to enforce multi-factor authentication, “because this vulnerability would only allow a bypass of a user’s first factor of authentication.” But the authors also warn, “if your IdP is responsible for both first factor and second factor authentication, it’s likely that this vulnerability bypasses both!”
Because multiple vendors are affected by this vulnerability, Duo Security worked with CERT/CC to co-ordinate disclosure. It provided the vulnerability information to CERT/CC on 18 December 2017. By 20 February 2018, all notified affected vendors had confirmed they were ready for disclosure; and Duo Security has disclosed the vulnerability details today.
Ann Arbor, Michigan-based Duo Security, a cloud-based provider of identity and access management solutions, announced a $70 million Series D funding round led by Meritech Capital Partners and Lead Edge Capital in October 2017. This brought the total amount raised to $119 million, and valued the company at $1.17 billion.