A peculiarity 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 hacker seeking access to reserved network areas.
The vulnerability was discovered by the research team of a cyber security firm. According to the investigation, it affects many of the leading SSO providers and probably the majority of developers of SSO.
Security Assertion Markup Language (SAML) is the protocol used by most SSO implementations. It is what allows authentication to be passed between a company’s identity stores and, for example, a third-party service. Usually, 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 vulnerability is in how authentication is encoded by SAML in the provider’s ‘response’.
The SAML authentication response contains two primary elements: the affirmation and the signature. The affirmation 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,” comment the data security researchers.
“One of the causes of this vulnerability is a unexpected behavior of XML libraries like Python’s ‘lxml’ or Ruby’s ‘REXML’,”. Comments can be included in the signature, but the binding process of the SAML libraries tends to drop all text after the first text node to isolate the NameID.
The cyber security researchers explain, “As an attacker with access to the account ‘user@user.com.evil.com’, I can modify the SAML affirmation to change the NameID to ‘user@user.com’ when processed by the SP.” The seven characters are inserted before .evil.com. This causes the biding process to drop ‘.evil.com’, leaving the authenticated account as ‘user@user.com’.
Not all SSO implementations are vulnerable to this glitch, but many are. All that is required 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.
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.
The data security professionals suggest implementing multi-factor authentication, “because this vulnerability would only allow a bypass of a user’s first factor of authentication, but if your IdP is responsible for both first factor and second factor authentication, it’s likely that this vulnerability bypasses both”
The cyber security company has confirmed the vulnerability 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).
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
