Everything you should know about SAML and how to exploit it

What is SAML ?

In my opinion, the best way to explain a technology is to show what problems it solves. So here is the problem : let’s say you work for a small company with 3 employees. In your intranet, you have a Jira, a mail server, an internal instant messaging system and a bitbucket. You’ve decided to recruit a new employee, so you will need to create an account for him on each of the company’s services. Then, one of your employees gets married and changes her lastname, so you need to update her lastname on each service. And finally, one of your employee leave the company so you have to make sure that all its accesses are revoked.

In a small company, these procedures are quite quick but with 1000 employees, it’s becoming almost impossible to do this manually. This is where SAML (Security Assertion Markup Language) comes in !

SAML works with 2 main entities : Service Provider (SP) and Identity Provider (IDP)

SP & IDP

In this way, SAML will enable users to access all services using just one pair of crendentials.

When a user logs into a SAML-compatible application, the service Provider requests authorization from the IDP. The identity provider authenticates the user’s credentials and then returns the users’s authorization to the service provider. Then, the user is able to use the application. This means that identities are stored in just one place: the IDP. SPs will then retrieve the identity and all the information associated with the user at the time of connection, by querying the IDP.

In most of the case, the IDP is an Active Directory or an Azure AD.

Technical part

How does it work ?

The user arrives on the application (SP)
The SP sees that the user is not authenticated and send him back to the IDP
The IDP then performs the authentication (whatever the method, login, password, biometric)
Finally, when authenticated, the user is sent back to the application

When the user arrives on the SP, the SP sends an AuthnRequest to the IDP to ask for an authentication. The user is redirected to the IDP for authentication. The user will type his credentials and the IDP will validate or not and then sends back a SAML Response containing a SAML Assertion with all user’s information to the SP. If the SP trusts the IDP, the user can access the site. The user can then access other sites through an SSO.

SAML AuthNRequest

Caption :

The ID is generated by the SP. The IDP will send a SAML reply in response to this ID.
IssueInstant is a timestamp for this request.
Destination is pointing to the IDP (act as a verification : the IDP can check if the request is actually intended for him).
AssertionConsumerServiceURL is pointing at where the response need to be send.
Issuer refers to the Entity Id of your SP, it is a URL that uniquely identifies your SP.

SAML Assertion

Caption :

<saml:Issuer> : An element, which contains the unique identifier of the identity provider
<ds:Signature> : An element, which contains an integrity-preserving digital signature (not shown) over the <saml:Assertion> element
<saml:Subject> : An element, which identifies the authenticated principal (but in this case the identity of the principal is hidden behind an opaque transient identifier, for reasons of privacy)
<saml:Conditions> : An element, which gives the conditions under which the assertion is to be considered valid
<saml:AuthnStatement> : An element, which describes the act of authentication at the identity provider
<saml:AttributeStatement> : An element, which asserts a multi-valued attribute associated with the authenticated principal

The SAML Assertion is contained in the SAML Response with more information like the Sigature

Let’s resume :

SAML Workflow

SAML Security

SAML provides some basic security features to guarantee the integrity of authentication. Before going any further, it’s important to note that before an IDP and a SP can be linked, a so-called “Trust” must be established through a key exchange.

SAML Signature

As we saw earlier, when the user has successfully authenticated with the Identity Provider, the IDP will send a SAML Response back to the SP with all the information associated with the user. In this way, the user’s e-mail address, username or even a role can be retrieved. It’s important not to be able to modify the values, because if a user intercepts his own request, all he would have to do is change the role to “admin”, for example.

To prevent this, the IDP will sign its SAML response to enable the SP to check that the request has not been modified during the transit. (The SP can check the signature with the key obtained during the key exhange needed for the trust)

SAML Signature

SAML Encryption

If you’ve been paying attention, you may have noticed that in the SAML assertion, user attributes such as email and role are passed in clear text to the request. Since the password is not transmitted, this is not a security flaw, but in some cases it may be useful to encrypt this information for confidentiality reasons.

Encrypted Assertion

(Encrypting the SAML assertion is optional. Whether or not it’s encrypted, you still have privacy through the transport layer security.)

Exploit SAML

The main problem with SAML is that all implementations are different and not all parsers are well designed.

The main tool I can recommend is SAML Raider. It is a plugin for Burp Suite to edit and exploit SAML messages. There is also some extensions like SAML-tracer to intercept and render SAML messages on your browser.

Modify the SAML Response

In some case, the signature is not correctly verified so it is possible to modify directly an attribute or add one to see how the SP reacts

XML Signature Exclusion

Most of the time, either the SAML Response or the SAML Assertion must be signed. It may be interesting to remove the signature and modify an attribute to see how the SP reacts. If both the assertion and the response are signed, try deleting one or the other and modifying an attribute to see if it works.

You can also try deleting only the value part of the signature, or the whole signature.

Signature Wrapping Attacks (XSW)

It’s hard to believe that SAML message parsers are perfect, there are always flaws. By manipulating messages, you can find vulnerabilities in parsers.

The main issue behind XSW is that SAML messages containing XML signatures are often processed in two separate steps : the first for validating the signature and the second for parsing information from the real application.

XML Signature Validation :

The application locates the ds:Signature’s ds:Reference element
The application uses the ds:Reference’s URI attribute to determine which XML element is signed
The application (in)validates the signed XML element

After validation, the same application attempts to use the signed data as part of its normal operation.

The application’s XML parser locates its desired XML element using top-down tree-based navigation

The goal of XSW is to move the signed contents to a different location and replaces it with an attacker-controlled XML element that doesn’t invalidate the XML document in the hopes that the XML parser finds the attacker-controlled element instead of the validated element.

Everything about XSW is explained here.

Certificate Faking

A trusted Identity Provider signed the SAML message, and certificate faking is the process of determining whether or not the Service Provider validates this. Every time a SAML message is received, the trust relationship between the SP and IDP should be verified. What this refers to is signing the SAML Response or Assertion with a self-signed certificate.

XXE & XSLT attacks

Since SAML uses XML, it inherits all the vulnerabilities associated with XML, such as XXE (XML external entity) or XSLT (Extensible Stylesheet Language Transformations).

XXE Attacks

XSLT Attacks

XSLT is a Turing complete language. it means that it is possible to use XSLT, for example, to read/write files on the local filesystem and send them over the Internet.

XSLT Attacks

XML Comments exploit

XML canonicalization is the process of transforming an XML document into a semantically identical but normalized representation. The CanonicalizationMethod in SAML messages specifies which canonicalization algorithm to apply (the most commonly occurring one we’ve seen is xml-exc-c14, which strips XML comments during transformation).

This is not a problem most of the time except when SAML libraries perform canonicalization before checking the signature.

Imagine a SAML assertion with these attributes :

1
2
3


<Subject>
    <NameID>admin@example.com.tempmail.dev</NameID>
</Subject>

I can add a comment that will not invalidate the SAML assertion :

1
2
3


<Subject>
    <NameID>admin@example.com<!---->.tempmail.dev</NameID>
</Subject>

And in some cases, the parser will not take into account what is after the comment so I will be able to connect as admin@example.com.