James Thew - Fotolia
A SAML vulnerability was recently discovered by Duo Security Inc., which found the flaw in one of its own products. Duo said the flaw affects single sign-on systems for five vendors, and it could affect many more depending on how companies implement SAML and which open source software libraries they use. What should infosec teams know about this SAML vulnerability?
The Security Assertion Markup Language (SAML) is an open standard protocol for exchanging authentication and authorization data between parties. It enables an identity provider to exchange authentication and authorization data with a service provider via XML-based messages and is widely used to extend single sign-on (SSO) across security domains.
The SAML vulnerability discovered by multifactor authentication provider Duo Security enables an attacker who has already authenticated access in an SSO system to authenticate as another user without that individual's SSO password. This could enable them to escalate their privileges to those of a C-level user or administrator who has privileged access.
Kelby Ludwig, senior application security engineer at Duo Security, found the SAML vulnerability in one of the company's own products, as well as products from single sign-on vendors OneLogin, Clever, OmniAuth and Shibboleth. The CERT advisory issued in coordination with Duo Security lists other vendors that may be affected by the flaw, as it involves how some open source libraries, including Python's lxml or Ruby's REXML, handle XML comments in SAML responses.
The flaw is not in the SAML protocol itself, but in its implementation. Before an XML document can be digitally signed, it needs to be converted to its canonical form -- canonicalization -- to ensure a consistent byte-by-byte comparison is possible. The process removes any variations and meaningless differences in the XML document that can lead to different digital signatures being created for what is, for all intents and purposes, the same document.
Ludwig found that the XML DOM traversal and canonicalization APIs in some SAML libraries are used incorrectly, so the inner text after the comment in XML nodes is lost prior to the SAML message being cryptographically signed. This means that text after the comment has no impact on the signature of the SAML message, so it can be modified without invalidating the cryptographic signature.
This creates a situation in which an attacker, who either has their own genuine SSO login credentials or has phished those of a genuine user, can intercept the XML-based response to the application requesting authentication and alter it to sign in as an entirely different user without invalidating its cryptographic signature. Exploitation of the bug is very simple, particularly when SSO account registration is open to any user.
Administrators running products from vendors identified by the CERT advisory should upgrade or patch them immediately. Those who are not sure if their SSO system may be affected by the SAML vulnerability should contact vendors of any SAML processing libraries they use for assurance.
Enabling two-factor authentication would only allow this vulnerability to bypass a user's first factor of authentication. However, Ludwig warns that if an identity provider is responsible for both first-factor and second-factor authentication, it's likely that this vulnerability can bypass both.
Ask the expert:
Want to ask Michael Cobb a question about application security? Submit your questions now via email. (All questions are anonymous.)