SAML [Security Assertion Markup Language] Vulnerabilities

In this blog, we are going to discuss about what is the SAML (Security Assertion Markup Language) and how it works as well as we are going to discuss the Security Assertion Markup Language Vulnerabilities. In the second part of this blog we will see the actual exploitation of the SAML vulnerabilities, so let’s get start.

What is SAML (Security Assertion Markup Language):

SAML is the oldest standard, originally developed in 2001. SAML, pronounced as “sam-el,” stands for Security Assertion Markup Language. It is an open standard that provides both authentications as well as authorization.

Security Assertion Markup Language is an XML- based open standard for exchanging authentication as well as authorization data between parties. Security Assertion Markup Language (SAML) allows identity providers (IdPs) to pass authorization credentials to service providers (SP’s). It’s much simpler to manage one login per user than it is to manage separate logins to email, customer relationship management (CRM) software, applications, Active Directory, etc.

Fig: Working of SAML

Identity Provider (IdPs) – The software or tool or service that performs the authentication; checking usernames and passwords, verifying account status, invoking two-factor, etc.
Service Provider (SPs) – The web application where the user is trying to gain access.
SAML Assertion – Message asserting a user’s identity and often other attributes, sent over HTTP via browser redirects.

How Does SAML Vulnerability Work:

By modifying SAML body content without invalidating the cryptographic signature, a remote attacker or unauthenticated user may be able to bypass primary authentication for an affected SAML service provider. Simply, this means that if an attacker is able to create or successfully compromise an account, could use this vulnerability to add comments to an attribute in order to get access to an account, like an administrator account.

SAML authentication enables the sharing of identity information between an IdPs and cloud or web applications. A SAML – based authentication model is composed of an identity provider, which is a producer of SAML assertions, such as SafeNet Trusted Access, and a service provider(SP), which is a consumer of assertions, such as G-Suite, Office 365, and any other cloud application that supports SAML. SAML assertions are generally signed with PKI signature which confirms that the assertion is authentic or not.

An authentication service acting as identity provider(IdP) collects the user credential and returns a response to the cloud application being accessed. This response is called a SAML assertion. The SAML assertion which contains an accept or reject response. If the SAML assertion is valid, the user is getting logged into the application.

**How to Identify Security Assertion Markup Language Vulnerabilities:**

SAML Raider:

SAML Raider is a Burp Suite extension for testing SAML infrastructure. It contains two core functionalities: Manipulating all SAML Messages and manage X.509 certificates.

It automatically highlights proxied requests containing SAML messages and adds a proxy tab with the decoded payload in the raider. SAML Raider also adds a pane to repeater which allows you to quickly issue popular signature wrapping attacks. SAML Raider adds a Cert tab which makes cloning certificates easy. User can either clone the certificate outright or create a self-signed version of the certificate.

Message Replay:

The assertions should contain a unique ID that is only accepted once by the application. Try replaying a SAML message to create multiple sessions through SAML request.

Fig: Overview of SAML

SAML from Different Recipient:

An application should only accept a SAML message intended for the service provider (SP) application. If the application does not perform this check, it may honor a security assertion markup language (SAML) message generated from authenticating to another application and allow you into the application as the user from the others application. If you have a valid login for another application which uses the same IP, login to the other service provider (SP) application and record the message. Replay the message intended for the other service provider (SP) to your target SP.

XML External Entity (XXE):

A SAML message is just a user-provided XML message that is processed by the Service Provider (SP). Be sure to check all standard XML attack vectors like XXE. XXE is a very common XML attack and attackers find it frequently through SAML messages.

Successful SAML attacks result in severe exploits such as replaying sessions and gaining unauthorized access to application functions, software and tools. SAML attacks are varied but tools such as SAML Raider can help in detecting and exploiting all common SAML issues. Hope that by using these techniques user can improve his/her detection and correction of SAML vulnerabilities in applications. Also, in my next blog I will explain the actual exploitation of SAML vulnerability (XXE).

How to Exploit SAML Vulnerabilities:

The likelihood to exploit SAML vulnerabilities is low. Replaying expired messages and replaying messages for another application, software and tool will yield their own limited results. Most of the vulnerabilities described above allow an assertion to be tampered with, which requires one last step to fully exploit the discovered SAML vulnerabilities. If user is able to tamper with a SAML message in such a way as to send your own assertions.

The presence of behavior is not great, but not always be exploitable. SAML IdP and SP are generally very configurable, so there is lots of room for increasing or decreasing impact.

e.g.: In SAML Response: Change the UserId to a different invalid user – Sometimes an application will grant default permissions or higher privileges to an unmapped user.

On the IdP side, openly allowing users to register accounts is one way to increase the impact of this issue by adding XML content in second part. A manual user provisioning process may add a barrier to entry that makes exploitation more infeasible.

For the actual exploitation of the SAML vulnerability, I am going to write my second blog so, stay tuned.

How to Mitigate SAML Vulnerabilities:

Remediation of this issue somewhat depends on what relationship user have with SAML.

The best remediation is to ensure that SAML processing libraries are not affected by any of this issue. User identified several SAML libraries that either leveraged these unintuitive XML APIs or did faulty manual text extraction, but surely there are more libraries out there that don’t handle comments in XML nodes well.

The number of libraries affected by this vulnerability suggest that multiple user also seem to assume XML inner APIs are not affected by comments, so change an API’s behavior of the application. However, there is a clear right answer for XML library authors, and a very reasonable action may be keeping the APIs as they are and improving documentation surrounding this behavior of SAML.

Another possible remediation is updating libraries to use the canonicalized XML document after signature validation for any processing such as text extraction, this could prevent this vulnerability and other vulnerabilities that could be introduced by XML canonicalization issues.

Also, possible remediation path is improving the XML standards. With my research, I did not identify any standards that specified the correct behavior, and it may be worth specifying how these related standards should interoperate with each other.

Security Best Practices for SAML :

Validate X.509 Certificate for algorithm compatibility and strength of encryption.
Validate Strong Authentication options for generating the SAML assertion and token.
validation of IDP (which IDP mints the token).
Use trust Root CAs whenever possible.
Synchronize to a common Internet-based timesource.
Define levels of assurance for user identity verification.
Prefer asymmetric identifiers for identity assertions over personally identifiable information like (e.g. SSNs, etc).
Use Sign assertions whenever possible.
Always validate session state for user.
Set Level of granularity in setting authZ, context when consuming SAML token (do you use groups, roles, attributes).
Validate authorized IDP’s.
Always validate IDP certificates for expiry against CRL/OCSP
Always validate NotBefore and NotOnorAfter
Always define specific criteria for SAML logout
Exchange assertions only over secure transports.
Always define criteria for session management.
Validate signature whenever possible.
Always verify user identities obtained from SAML ticket assertions whenever possible.
Ensure that all SAML providers/consumers do proper input validation.

Flaw Affects Multiple Vendors, Open-Source Libraries:

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

Conclusion:

SAML is used in various companies and products as a Single Sign On solution. Taking a closer look at SAML implementations and its history of known security vulnerabilities, it could be assessed that SAML can be considered secure, if established security standards are met. In addition to this, it could be shown, that Microsoft’s implementation of a custom SAML 2.0 Web Browser SSO has been disregarding some of these security standards, such as validation of the security token against the Identity Provider. When security vulnerabilities were found in the Microsoft Office 365 SAML implementation, it raised the question whether this vulnerability was caused by SAML or Microsoft’s implementation. In conclusion, it could be assessed, that the cause of the security vulnerability in Microsoft Office 365 lay exclusively in a flawed implementation of SAML 2.0 Web Browser SSO, and was not related to any general flaws in the SAML.

References:

Author,

Prafull Pansare

Attack & PenTest Team

Varutra Consulting Pvt. Ltd.

Vulnerabilities Related to SAML [Security Assertion Markup Language] – Part 1