Vulnerabilities in Single Sign-On services could be abused to bypass authentication controls

SAML XML injection gives attackers free rein over user accounts, although hard-to-execute bug proves real-world threat is minimal

UPDATED A class of vulnerability detected in several Single Sign-On (SSO) services might allow attackers to hack into corporate systems, security researchers at NCC Group warn.

SSO technology is an approach to authentication and identity management that allows enterprise users to access to array of corporate applications through a single (often third-party) service.

The technology, which has been widely adopted among enterprises, offers convenience to users because it gets around the need to manage multiple workplace passwords.

As well as cutting down on helpdesk calls, the technology offers a way to manage credentials and privileges from a single location and increases security – at least in theory.

Security researcher Adam Roberts of NCC Group has discovered similar vulnerabilities in several SSO services that rely on Security Assertion Markup Language (SAML) to authenticate users.

These implementation flaws create a potential means to break into systems and cause all manner of mischief, Roberts warns in a technical blog post.

“The flaw could allow an attacker to modify SAML responses generated by an identity provider, and thereby gain unauthorized access to arbitrary user accounts, or to escalate privileges within an application,” according to Roberts.

Play it again, SAML

SAML is a standard that allows authentication and authorization data to be securely exchanged between different contexts.

The technology integrates with Active Directory, Microsoft’s proprietary directory service, which makes it easy to roll out and hence a popular option for enterprise-grade SSO deployments.

Authentication requests in this scenario are directed through identity providers through SAML request message. This generates a response that typically authorizes an enterprise user to make use of a specified application.

RECOMMENDED Ransomware: Nearly a fifth of victims who pay off extortionists fail to get their data back

Roberts discovered that these SAML authentication responses might be modified through a technique known as “SAML XML injection”.

More specifically it “may be possible for an attacker to inject additional XML and change the structure of the SAML message”, as Roberts explains:

Depending on the location of the injection and the configuration of the service provider, it may be possible to inject additional roles, modify the receiver of the assertion, or to inject an entirely new username in an attempt to compromise another user’s account.

Crucially, it should be noted that the XML for SAML assertions and responses is always built before a cryptographic signature is applied. Therefore, the use of response signatures does not protect against this vulnerability.

According to Roberts, the security weakness most commonly shows up where SAML identity providers have “naively” used string templates to build the SAML XML messages. “User-controlled data may be inserted into the template string using a templating language, regex match/replace, or simple concatenation,” Roberts warns.

Is your organization vulnerable?

This potentially damaging authentication vulnerability can be identified in testing using common XML injection probing payloads.

The NCC blog post goes on to note that exploiting SAML XML injection vulnerabilities is something of an art, and much more difficult than simply identifying flawed implementations, a comparatively straightforward exercise.

Catch up on the latest authentication-related security news

Roberts told The Daily Swig that the issue arose from an "implementation bug rather than an inherent flaw in the SAML specification".

"The issue seems to arise when developers build XML documents insecurely, including the use of string-based templates to create the SAML response XML or incorrect use of an XML library," he explained.

Roberts used this technique in a number of engagements, and the research is a "lab distillation of the experiences gained from that work combined with supplemental research", NCC Group explained.

It’s unclear to what extent, if at all, real-world attackers are relying on the approach.

Roberts concluded: “To address the issue, developers of identity providers should check their codebase and ensure that user-controlled data is not being included within a SAML response insecurely.

"We’d recommend that security researchers and enterprise penetration testers add this technique to their methodologies when testing a SAML identity provider to help them ensure they are also protected against this recently uncovered bug type.”

This story has been updated to include comment from Adam Roberts, senior security consultant at NCC Group