Demystifying SAML Misconfigurations — Hacking SAML Part 2

Welcome to Part 2 of our SAML exploration. In the previous part, we laid the groundwork by dissecting SAML’s fundamental aspects. Now, we shift our focus to the darker side of SAML security. In this part, we’ll dive into various SAML vulnerabilities that malicious actors can exploit. From signature issues to comment injections and replay attacks, we’ll equip you with the knowledge to understand and mitigate these threats.

SAML Vulnerabilities

1. The Signature Does Not Exist or Is Not Verified

If the SAML signature is not implemented or is not verified at all, the identity assertions are left unprotected. Attackers can forge the identity information in the SAML response at will.

<!-- No signature -->
<saml:AttributeStatement>
    <saml:Attribute Name="username">
        <saml:AttributeValue>
            user1
        </saml:AttributeValue>
    </saml:Attribute>
</saml:AttributeStatement>

2. Certificate Faking: Testing Trust Verification

Certificate faking is a crucial technique for evaluating whether the Service Provider (SP) appropriately verifies the signatures of SAML Messages from trusted Identity Providers (IdPs). The trust relationship between the SP and IdP should be diligently confirmed with each incoming SAML Message. In essence, this method involves using a self-signed certificate to sign the SAML Response or Assertion.

To facilitate certificate faking, we rely on the Burp extension, SAML Raider.

1. Begin by intercepting the SAML Response.
2. If the Response includes a Signature, employ the “Send Certificate to SAML Raider Certs” button.

Send Certificate to SAML Raider Certificates

3. Once sent, you should observe an imported certificate within the SAML Raider Certificates tab. Highlight this imported certificate.

4. Subsequently, select the “Save and Self-Sign” button. This action generates a self-signed replica of the original certificate.

Import & Self-Sign

5. Return to the intercepted request within Burp’s Proxy. First, choose the newly created self-signed certificate from the XML Signature dropdown menu.

6. Utilize the “Remove Signatures” button to eliminate any pre-existing signatures.

7. Finally, utilize either the “(Re-)Sign Message” or “(Re-)Sign Assertion” button, depending on your specific context.

Re-signing

8. After signing the message with the self-signed certificate, forward it on its way.

9. If authentication proceeds successfully, you have confirmed your ability to sign SAML Messages. This newfound capability allows you to modify Assertion values, which will be accepted by the Service Provider.

3. The Signature is Only Verified When It Exists

In this scenario, developers make the mistake of only verifying signatures if they exist. Attackers can remove or empty the signature field to bypass security measures.

<!-- Signature is verified if it exists -->
<saml:Signature>
    <!-- Empty signature field -->
</saml:Signature>
<saml:AttributeStatement>
    <saml:Attribute Name="username">
        <saml:AttributeValue>
            admin 
        </saml:AttributeValue>
    </saml:Attribute>
</saml:AttributeStatement>

Removing Signature using SAML Raider

4. Predictable Signature Generation

If the signing mechanism is weak or predictable, attackers can forge their own signatures. For instance, if the signature is a simple base64 encoding of the username, attackers can use this knowledge to impersonate other users.

<saml:Signature>
        ......
     <saml:SignatureValue>
        dmljdGltX3VzZXI=   <!-- base 64 decoded value : victim_user -->
     </saml:SignatureValue>
         ......
</saml:Signature>
......
<saml:AttributeStatement>
   <saml:Attribute Name="abc">
       <saml:AttributeValue>
           victim_user
       </saml:AttributeValue>
   </saml:Attribute>
</saml:AttributeStatement>

5. Comment Injection

Comment Injection is a SAML vulnerability that often goes unnoticed due to its subtlety. It involves inserting HTML or XML comments within the data of a SAML assertion. These comments can be added to various parts of a SAML message, such as user attributes, group memberships, or the user’s email.

The attacker’s goal is to manipulate the content in a way that the Service Provider (SP) misinterprets the data. They often focus on the email attribute as it can influence the user’s privileges within the application.

1. Finding the Registration Page: The attacker’s journey starts with identifying the registration page of the Service Provider.
2. Payload Manipulation: During registration, the attacker skillfully inserts a comment within the payload. For example, they might use “admin<! — comment →@email.com” as their registered email.
3. The SP’s Oversight: The SP receives this data and sees “admin@email.com.” The comment remains undetected, allowing the attacker to pose as an administrator.

Another scenarios is :

1. Hunting for Vulnerabilities: Just like in the first scenario, the attacker seeks out the SP’s registration page.
2. Initial Attempt: This time, they register as a user with an invalid signature, using an email like “admin<! — comment →@gmail.com.”
3. Persistence Rewarded: The attacker makes a subtle change to their email, turning it into “admin@gmail.com<! — comment →.test.” This new email carries a valid signature, tricking the SP into granting admin privileges.

6. SAML Replay Attacks

A SAML replay attack occurs when an attacker intercepts a SAML assertion (containing user identity information) and subsequently reuses it to gain unauthorized access to a protected resource. To mitigate this threat, SAML assertions often include a <saml:Conditions> element with NotBefore and NotOnOrAfter attributes.

<saml:Conditions NotBefore="2023-10-20T08:23:28Z" NotOnOrAfter="2023-10-20T08:28:58Z">

Part 2 has uncovered the vulnerabilities that can threaten SAML-based systems, making it crucial to bolster our defenses. As we conclude this segment, be sure to join us in Part 3, where we’ll explore advanced attacks like XML Signature Wrapping, Entity Expansion, and XPath Injection, arming you with the knowledge needed to safeguard your SAML implementations.

In Part 2, we’ve revealed weaknesses that could harm SAML-based systems, stressing the importance of strengthening our security measures. As we finish this part, don’t forget to continue with us in Part 3. There, we’ll delve into more advanced attacks like XML Signature Wrapping, Entity Expansion, and XPath Injection, giving you the information to protect your SAML systems effectively.

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

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

Security Assertion Markup Language — Wikipedia

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