Understanding and Defending Against SAML Vulnerabilities

Introduction to Security Assertion Markup Language (SAML)

If you are currently working with a Fortune 500 company, a company implementing a zero trust network, or one that utilizes single sign-on (SSO) technology, then you are highly likely to encounter Security Assertion Markup Language (SAML).

SSO, as defined by Google, is “an authentication scheme that allows a user to log in with a single ID and password to any of several related, yet independent, software systems.” Essentially, SSO allows users to access multiple services with just one set of credentials, dramatically improving the user experience and security posture.

The SAML Authentication Flow

The illustration below describes a typical implementation of SAML. When examining this flow, you should pay close attention to the SSO website and the Identity Provider (IDP).

The primary goal of SSO is to use one set of credentials across multiple websites. Therefore, we require a central place for the user to log in, and the SSO website acts as this central point. Once a user logs into the SSO website, their credentials are sent to the IDP. The IDP checks the supplied credentials against its user database, and if a match is found, the user is authenticated and logged in.

Now, if a user attempts to log into their target website (also known as the Service Provider (SP)), they will be automatically forwarded to the SSO website. Since the user is already logged into the SSO website, they will be forwarded back to the SP. This time, they are sent back with a SAML Assertion that contains their verified identity information.

Deconstructing a SAML Assertion

A SAML Assertion is the XML document that the Identity Provider (IDP) sends to the Service Provider (SP), which contains the user’s authorization and authentication details.

A SAML assertion typically contains several critical components:

• Subject Section: This section contains the authentication information, such as a username or email address, often held within a tag like NameID. This information is crucial for the SP to identify and log in the user.
• Signature Section: This is a vital security component that contains a signature value designed to verify that the Subject section (and often the entire assertion) has not been tampered with.
• Reference URI: Located within the signature section, the Reference URI is a tag that points to the specific section of the XML document that the signature applies to. For example, if a signature has a Reference URI matching the Assertion ID (e.g., _2fa74dd0-f1dd-0138-2aed-0242ac110033), this means the signature is verifying that entire assertion tag and all the data it holds.

Example: In a SAML assertion, we might see a tag called NameID which holds the user’s username. This information is sent to the Service Provider, and if accepted, it will log in the user as that identity.

Common SAML Vulnerabilities and Exploitation Techniques

When a Service Provider (SP) receives a SAML assertion, the endpoint is supposed to verify that the information has not been tampered with or modified by checking the XML digital signature. However, several vulnerabilities exist that can bypass this crucial security check.

1. XML Signature Removal

In certain systems, it is possible to bypass the signature verification process by either removing the signature value or the entire signature tag from the assertion or message.

• Nullifying the Signature Value: One initial technique to attempt is to make the SignatureValue data blank, so it appears as:XML<ds:SignatureValue></ds:SignatureValue> In some specific situations, this is enough to completely break the signature check, allowing a malicious actor to modify the information in the assertion without detection.
• Completely Removing Signature Tags: Another potential attack involves completely removing the signature tags from the request. If you are using a security tool like the SAML Raider plugin in Burp Suite, you can often achieve this by clicking a “Remove Signatures” button.

Note: A security professional can also remove the signature manually from the raw HTTP request if they prefer not to use a plugin. The end result is a message or assertion tag without any signature section.

While a normal Service Provider would reject a SAML message that is missing its signature section, in some configurations, it will still be accepted. If the message is accepted, an attacker could then modify the information in the Subject tags (like the NameID username/email) without the information being verified. This action would allow an attacker to supply another user’s email or identifier, potentially giving them full, unauthorized access to that user’s account.

2. XML Comment Injection

An XML comment serves the same purpose as a comment in any other programming language: it is used by developers to leave notes in the code and is ignored by compilers or parsers. In XML, we can include comments anywhere in the document using the following tag structure:

An XML parser will typically ignore or remove these comments when processing an XML document, and this is where an attacker can exploit the process.

If a malicious actor passes a username like:

admin@gmail.com

The comment section (“) will be removed or ignored by the parser, resulting in the desired, legitimate-looking username: admin@gmail.com.

In a SAML response, a user identity containing a comment can be crafted. When this malicious assertion is passed to the Service Provider, the comment is stripped out, resulting in the clean email admin@gmail.com. If this identity is a privileged user, the attacker will then be logged in as that user.

3. XML Signature Wrapping (XSW)

The core idea of XML Signature Wrapping (XSW) is to exploit the separation between the SSO Verificator and the SSO Processor. This vulnerability arises because XML documents containing XML Digital Signatures are typically handled in two distinct steps:

1. Validation: The digital signature is validated.
2. Processing: The application uses the XML data.

A typical application will first locate the signature and its Reference URI. As discussed earlier, the Reference URI is used to determine which document element the signature verifies. The application uses this URI to find the signed XML element and validates or invalidates it. Once this validation process is complete, the application proceeds to locate the desired XML element and parses out the information it is looking for (e.g., the username).

Normally, the validation phase and the processing phase operate on the exact same XML element. However, with Signature Wrapping, this may not be the case: validation may be performed on one element, but the processing phase happens on a different (malicious) element.

For security testing professionals, using the SAML Raider plugin for Burp Suite is recommended for testing this vulnerability.

To test for XSW: Select the XSW attack in the plugin, press the “Apply XSW” button, and send the modified SAML response. If the endpoint returns successfully without erroring out, the system may be vulnerable to this type of attack.

XSW Attack Variations

The following are different techniques used to perform an XML Signature Wrapping attack.

XSW Attack 1: Enveloping Signature Attack (Targets the Response Signature)

This first attack focuses on the signature of the entire SAML response. The technique involves creating a new SAML response with a malicious assertion and then wrapping the original response inside this new response. The core idea is to trick the system:

• The validation process will occur on the original response (where the signature is valid).
• The processing phase will occur on our modified (malicious) response (which appears earlier or is otherwise preferentially parsed).

In this scenario, the original SAML response is embedded within the signature, which is known as an enveloping signature. The signature’s Reference URI will match the ID of the embedded original SAML response, causing the verification process to succeed. However, when the application goes to parse the actual assertion data, it will incorrectly select our evil assertion instead of the original, verified one.

XSW Attack 2: Detached Signature Attack (Targets the Response Signature)

The second attack is functionally similar to the first, but it uses a detached signature instead of an embedded (enveloping) one. Like Attack 1, this method targets the signature of the overall SAML response.

Note: XSW Attack 1 and XSW Attack 2 are the only two attacks in this list that specifically target the signature of the SAML response. The remaining attacks focus on exploiting the signature associated with the assertion itself.

XSW Attack 3: Preceding Malicious Assertion (Targets the Assertion Signature)

This attack works by placing the malicious assertion above the original assertion, ensuring it is the first element in the SAML response payload.

The hope here is that after the validation steps are complete, the parsing process—which is looking for the assertion to extract user details—takes the first element it finds in the SAML response. If the parser is lazy or incorrectly implemented, it will grab the malicious assertion instead of the original, verified one.

XSW Attack 4: Embedding Original in Evil Assertion (Targets the Assertion Signature)

This attack is similar to XSW Attack 3, but the technique involves embedding the original assertion inside the evil/malicious assertion.

XSW Attack 5: Copying Signature into Evil Assertion (Targets the Assertion Signature)

In this method, the original, valid signature is copied and embedded into the malicious assertion. Crucially, the original signature still points to the original assertion via its Reference URI. This aims to satisfy a checker that is looking for a valid signature associated with the assertion while still presenting a malicious payload for processing.

XSW Attack 6: Double Embedding (Targets the Assertion Signature)

This method involves a deeper level of wrapping: the original assertion is embedded within the original signature, and then all of that is embedded within the malicious assertion.

XSW Attack 7: Utilizing the Extensions Tag (Targets the Assertion Signature)

This technique utilizes the Extensions tag, which is often a less restrictive XML element in terms of parsing and validation rules. The malicious assertion is placed within a set of Extensions tags, and it is given the exact same ID as the original, legitimate assertion.

Note: Both the malicious assertion and the original assertion have the same ID, which can confuse the parser or lead to an incorrect processing choice.

XSW Attack 8: Utilizing the Object Tag (Targets the Assertion Signature)

This final method also makes use of a less restrictive XML element, the Object tag. The steps are as follows:

1. Create the malicious assertion and embed the original signature within it.
2. Embed an Object element within the signature.
3. Place the original assertion within the Object element.

Note: Just like Attack 7, the malicious assertion and the original assertion have the same ID, aiming to confuse the system’s processing logic.