Demystifying SAML Misconfigurations — Hacking SAML Part 3

Saumya Kasthuri
6 min readOct 31, 2023

--

Welcome to the last part of our complete SAML series. In Part 2, we talked about problems, but there’s more to learn. In Part 3, we’re going to dig even deeper into the world of SAML security. We’ll talk about advanced attacks like XML Signature Wrapping, Entity Expansion, and XPath Injection. We’ll explain these tricky tactics and give you the knowledge you need to make your SAML systems stronger against these complex threats.

7. XML Signature Wrapping

XML Signature Wrapping attacks (XSW) are a class of vulnerabilities that target the handling of XML documents containing XML Signatures. These attacks exploit discrepancies between the processing of the signature and the application’s business logic, allowing adversaries to inject forged elements into the message structure without invalidating the XML Signature. The end goal is to deceive the recipient into successfully verifying the signature while processing malicious content.

How XSW Attacks Work:

XML documents with signatures are typically processed in two separate steps:

  1. Signature Validation: In this step, the XML Signature is verified to ensure the integrity and origin authentication of the message.
  2. Function Invocation (Business Logic): Once the signature is validated, the message is processed according to the application’s logic.

XSW attacks take advantage of the difference in how these two modules interpret the data within the XML document. The attacker’s goal is to alter the message structure by injecting forged elements that do not interfere with the XML Signature validation. These forged elements are strategically placed to deceive the application’s logic into processing the attacker’s content.

Key Points of XSW Attacks

  1. Valid Signatures, Altered Messages: The attacker’s modifications do not disrupt the validity of the XML Signature. As a result, the recipient successfully verifies the signature, believing the message to be intact.
  2. Diverging Interpretations: The application logic and the signature verification module have different interpretations of the message due to the attacker’s manipulations.
  3. Content Injection: XSW attacks enable the injection of arbitrary content into the application’s processing flow. This can have severe consequences, as the injected content may be malicious or disrupt the intended functionality.
  4. Integrity and Authentication Bypass: The attacker effectively circumvents the integrity protection and origin authentication provided by the XML Signature, as the application processes the bogus elements.

XSW: Simple Signature Wrapping Attack

In this attack, an adversary adds a cloned unsigned copy of the Response after the existing signature.

Original SAML Response:

<Response>
<Data>Important data</Data>
<Signature> <!-- Valid Signature -->
<SignedInfo>
<!-- Signature details -->
</SignedInfo>
<SignatureValue>abc123</SignatureValue>
</Signature>
</Response>

Modified SAML Response:

<Response>
<Data>Important data</Data>
<Signature> <!-- Valid Signature -->
<SignedInfo>
<!-- Signature details -->
</SignedInfo>
<SignatureValue>abc123</SignatureValue>
</Signature>
<Response> <!-- Cloned unsigned Response -->
<Data>Manipulated data</Data>
</Response>
</Response>

XSW: Signature Wrapping Attack Before (Response)

In this attack, the adversary adds a cloned unsigned copy of the Response before the existing signature.

Original SAML Response:

<Response>
<Data>Important data</Data>
<Signature> <!-- Valid Signature -->
<SignedInfo>
<!-- Signature details -->
</SignedInfo>
<SignatureValue>abc123</SignatureValue>
</Signature>
</Response>

Modified SAML Response:

<Response>
<Data>Important data</Data>
<Response> <!-- Cloned unsigned Response -->
<Data>Manipulated data</Data>
</Response>
<Signature> <!-- Valid Signature -->
<SignedInfo>
<!-- Signature details -->
</SignedInfo>
<SignatureValue>abc123</SignatureValue>
</Signature>
</Response>

XSW: Signature Wrapping Attack Before (Assertion)

In this type , attackers add a cloned unsigned copy of the Assertion before the existing Assertion.

Original SAML Response:

<Assertion>
<Data>Important data</Data>
<Signature> <!-- Valid Signature -->
<SignedInfo>
<!-- Signature details -->
</SignedInfo>
<SignatureValue>abc123</SignatureValue>
</Signature>
</Assertion>

Modified SAML Response:

<Assertion>
<Assertion> <!-- Cloned unsigned Assertion -->
<Data>Manipulated data</Data>
</Assertion>
<Data>Important data</Data>
<Signature> <!-- Valid Signature -->
<SignedInfo>
<!-- Signature details -->
</SignedInfo>
<SignatureValue>abc123</SignatureValue>
</Signature>
</Assertion>

XSW: Signature Wrapping Attack After (Assertion)

In this type, attackers add a cloned unsigned copy of the Assertion after the existing Assertion.

XSW: Signature Exclusion Attack:

This attack focuses on removing the signature from the SAML response, making it appear as if the response is valid without verification.

Original SAML Response:

<samlp:Response ...>
<ds:Signature>
<!-- Signature Data -->
</ds:Signature>
<!-- Original content -->
</samlp:Response>

Modified SAML Response:

<samlp:Response ...>
<!-- Maliciously exclude the signature element -->
<!-- Original content -->
</samlp:Response>

XSW: Simple Entity Expansion Attack:

In this attack, an attacker injects additional XML entities into the SAML response to expand the document and potentially cause a denial of service.

Original SAML Response:

<samlp:Response ...>
<!-- Original content -->
</samlp:Response>

Modified SAML Response:

XSW: XPath Injection Attack:

This attack exploits XPath processing in the SAML response to extract sensitive information.

Original SAML Response:

<samlp:Response ...>
<saml:Attribute Name="userEmail">
<saml:AttributeValue>jane.doe@example.com</saml:AttributeValue>
</saml:Attribute>
<!-- Original content -->
</samlp:Response>

Modified SAML Response:

<samlp:Response ...>
<saml:Attribute Name="userEmail">
<saml:AttributeValue>jane.doe@example.com' or 1=1 or ''='</saml:AttributeValue>
</saml:Attribute>
<!-- Original content -->
</samlp:Response>

XSW: Wrapping with Malicious Assertion

In this attack, an attacker wraps a legitimate SAML response with a malicious SAML assertion.

Original SAML Response:

<samlp:Response ...>
<!-- Original content -->
</samlp:Response>

Modified SAML Response:

<samlp:Response ...>
<!-- Legitimate SAML assertion -->
<saml:Assertion ...>
<!-- Original content -->
</saml:Assertion>
<!-- Malicious SAML assertion -->
<saml:Assertion ...>
<!-- Malicious content -->
</saml:Assertion>
</samlp:Response>

XSW: Signature Reference Attacks

In this type, attackers manipulate the references in the XML Signature. XML Signatures often contain references to specific elements within the XML document. Attackers alter these references to inject arbitrary content, leading to discrepancies between the document’s intended processing flow and the application’s interpretation.

Original SAML Response:

<Assertion>
<Data>Important data</Data>
<Signature> <!-- Valid Signature -->
<Reference URI="#element1" />
</Signature>
</Assertion>

Modified SAML Response:

<Assertion>
<Data>Important data</Data>
<Signature> <!-- Valid Signature -->
<Reference URI="#element2" /> <!-- Altered reference -->
</Signature>
</Assertion>

These examples demonstrate how attackers exploit XML Signature Wrapping vulnerabilities to manipulate XML documents and deceive systems that rely on XML signatures for security.

SAML Raider, offers a user-friendly feature to test for XML Signature Wrapping (XSW) vulnerabilities within SAML-based applications. With this tool, you can select an XSW attack type from a dropdown menu, and SAML Raider will modify the SAML message accordingly, simplifying the process of identifying and addressing potential security weaknesses.

XSW attacks using SAML Raider

As we come to the end of this three-part series, we’ve taken a deep dive into the world of SAML, from understanding its basics in Part 1 to uncovering vulnerabilities in Part 2 and exploring advanced attacks in Part 3. With this knowledge, you’re better prepared to secure your systems.

Remember that SAML security is an ongoing journey. It’s not just about what you’ve learned in these three parts, but how you continuously apply this knowledge. Stay vigilant, keep up with security updates, and implement robust measures to protect your SAML-based systems. Your digital assets are valuable, and safeguarding them is an ongoing commitment.

I hope this series has been a valuable resource for you, and I wish yourself the best of luck in your journey toward a more secure digital environment.

Link to Part 1: https://medium.com/@srkasthuri/demystifying-saml-misconfigurations-3874aa1097ff

Link to Part 2 : https://medium.com/@srkasthuri/demystifying-saml-misconfigurations-hacking-saml-part-2-c877de0d23fa

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Hackmanit — Ihr Spezialist für Web Sicherheit und Kryptographie.
Hackmanit — Your Specialist for Web Security and Cryptography.www.hackmanit.de

SAML — what can go wrong? Security check — Securing
What you should consider when trying to securely integrate with SAML Identity Provider.www.securing.pl

https://book.hacktricks.xyz/pentesting-web/saml-attacks

https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/

--

--