close search bar

Sorry, not available in this language yet

close language selection

SSO flaw fixed for some, but risk remains

SSO flaw fixed for some, but risk remains

A recently discovered flaw that undermines the security of numerous single sign-on (SSO) services has been patched by four major providers. But the risk remains for those who don’t install available patches and those for whom no patch is available yet.

It’s true that SSO’s major selling point is convenience, not security

It makes it easier, and much quicker, to sign into multiple applications, platforms, servers, and so on.

Still, improved security is supposed to be a byproduct. The theory is that if users have to remember a single password instead of dozens of them, they’re more likely to pick a stronger one.

But for at least the past few months, the byproduct of SSO has been insecurity, which could still exist no matter how strong your password is.

Duo Security’s Duo Labs said it discovered the flaw last Dec. 11 in a Security Assertion Markup Language (SAML) library used in one of its own products—the Duo Network Gateway (DNG), which uses two-factor authentication (2FA).

SAML is one of the most common languages in the SSO world, where authentication servers known as identity providers (IdPs) validate requests from users for access to service providers (SPs) on the network. For those different services—frequently from different vendors—to work together, they need a uniform data language and vocabulary.

Duo said in an advisory issued Tuesday that a flaw in the open source library python-saml could, “under certain conditions, allow an attacker with authenticated access to a SAML IdP to bypass the first factor of authentication for a different user.”

As Jacob Ewers, associate managing consultant with the Synopsys Software Integrity Group (SIG) put it,

“It allows an attacker to impersonate another user by shortening their name.”

His colleague, Luke Arntson, associate principal consultant with SIG, gave an example: “Let’s say there is a user called, and you create an account,” he said.

“You sign into Duo, it returns a SAML response with a signature you cannot replicate, and you change your response to<!– –>” The affected software, rather than processing the response in full, would first parse it into three components: “,” an empty comment, and “” Then it would validate only the first component as the username. “Your SAML log-in to the third-party site from Duo—the only person that should be able to sign your SAML response—now validates you as”

Experts generally agree that Duo went by the book in its response to the discovery—it notified CERT/CC (Computer Emergency Response Team Coordination Center) along with three other affected vendors, but otherwise kept quiet until it and the other vendors had created patches.

By Feb. 1, CVE numbers had been reserved for each vendor’s affected software:

  • Duo Network Gateway: CVE-2018-7340
  • 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

Then, in its advisory this past Tuesday, Duo requested that users update their DNG to version 1.2.10+.

The only risk with staying quiet for about 2.5 months, Arntson said, is that hackers might have also discovered the flaw and been exploiting it.

“This happened when LastPass was found to have a vulnerability that would leak your private key through the web extension and another vulnerability that could run full RCE (remote code execution) on your machine,” he said.

“The disclosure came pretty late, and researchers found evidence of the exploit code being actively used on malicious sites before the public disclosure, which could have meant bank accounts stolen, emails hacked, computers infected with bots, etc.”

But with the patches now available, does that mean the problem is solved?

That depends. It is for those who use those vendors and who install the available patch. But because IdPs and SPs using SAML libraries are extremely configurable, there are plenty that remain vulnerable.

David Johansson, principal consultant with Synopsys SIG, said there are “multiple libraries to parse SAML responses or XML messages in general that may be used by organizations when they build their own solution, and these may not be patched.

“It will likely take a long time before every SAML service provider solution is fixed, and testing for this issue should be part of every security test of an application using SAML,” he said.

Arntson contends that the flaw is actually not with the library. “This is a logic flaw with undocumented behavior rather than a library flaw,” he said. “It is up to the developers of the LDAP (Lightweight Directory Access Protocol) services or any SAML-digesting service to appropriately parse the incoming XML (eXtensible Markup Language) and recognize potentially bad datasets.”

There is also some dispute about the severity of the threat.

Duo said in its advisory that while the flaw would allow an attacker to trick the DNG into authenticating as the victim, that is only one factor of its 2FA. “Unless the attacker can separately bypass 2FA, this attack would not result in a full bypass of user authentication,” it said.

Not according to Amit Sethi, principal consultant with Synopsys SIG. “I don’t think this has anything to do with 2FA,” he said.

“You have to look at the overall log-in flow, and when SAML assertions are generated/verified. If you have an IdP that performs 2FA before generating a SAML assertion, then you’d be vulnerable. If the 2FA mechanism is invoked by the SP after consuming a SAML assertion and the 2FA process doesn’t involve SAML, then you’d be safe.

“The overall risk depends on the SP,” he said. “If users can register arbitrary usernames, this is potentially a high-risk issue. If usernames are assigned by an administrator, and especially if they’re corporate email addresses, then this is low-risk.”

Arntson added that he suspects many developers “were probably not aware that certain libraries such as lxml break up text nodes inside of an XML element when you insert a comment.” This mechanism is what allows the input “<!– –>” to be processed as “” by the affected software.

“There is no golden fix here, and vendors must review their code for any issues related to this security flaw,” he said.

It’s time to address your unique security and quality needs.

We can help

Taylor Armerding

Posted by

Taylor Armerding

Taylor Armerding

Taylor Armerding is an award-winning journalist who left the declining field of mainstream newspapers in 2011 to write in the explosively expanding field of information security. He has previously written for CSO Online and the Sophos blog Naked Security. When he’s not writing he hikes, bikes, golfs, and plays bluegrass music.

More from Security news and research