Demystifying SAML Misconfigurations — Hacking SAML Part 1

7 min readOct 25, 2023

Welcome to our three-part series on Security Assertion Markup Language (SAML). SAML is a crucial framework for implementing Single Sign-On (SSO) and federated authentication. In this first part, we will lay the foundation by exploring the fundamental components of SAML, understanding the SAML workflow, dissecting the SAML response structure, and addressing key security considerations. Additionally, we’ll introduce you to a playground where you can experiment with real-world SAML vulnerabilities, so let’s dive in!

When it comes to security, understanding the vulnerabilities in authentication systems is essential. Security Assertion Markup Language (SAML) is a key technology that secures the process of verifying identities. In this beginner-friendly guide, we’ll explore the world of SAML misconfigurations and vulnerabilities.

The entire blog series will be covering the following topics:

SAML Components
The SAML Workflow
SAML Response Structure
SAML Security Considerations
Your Playground
a. Yogi’s Vulnerable SAML App
b. SAML Raider
SAML Vulnerabilities
a. The Signature Does Not Exist or Is Not Verified
b. Certificate Faking: Testing Trust Verification
c. The Signature is Only Verified When It Exists
d. Predictable Signature Generation
e. Comment Injection
f. SAML Replay Attacks
g. XML Signature Wrapping
i. Simple Signature Wrapping Attack
ii. Signature Wrapping Attack Before (Response)
iii. Signature Wrapping Attack Before (Assertion)
iv. Signature Wrapping Attack After (Assertion)
v. Signature Exclusion Attack
vi. Simple Entity Expansion Attack
vii. XPath Injection Attack
viii. Wrapping with Malicious Assertion
ix. Signature Reference Attacks
References

Meet SAML — Your Digital Passport

Before we dive into the fascinating world of SAML misconfigurations, let’s get acquainted with SAML itself. Imagine SAML as your digital passport. It allows you to log in once and access multiple websites without re-entering your credentials every time.

Think of it this way: when you check in for a flight, you log in with your airline, and they provide you with a “boarding pass” (a SAML assertion). This “boarding pass” confirms your identity. When you visit the airline’s entertainment site, it doesn’t ask for your password again. It simply checks your “boarding pass” (SAML assertion), and you’re granted access!

SAML Components (User, Identity Provider, Service Provider)

To understand SAML, it’s essential to grasp its core components:

User: This is the end-user who is attempting to access a specific service.
Identity Provider (IdP): The IdP is responsible for authenticating users. It verifies their identities and provides user information to Service Providers (SPs) as needed. In SAML, the IdP is the trusted source of user identity information.
Service Provider (SP): The SP is the actual application or service that users are trying to access. It relies on the IdP to ensure user identity.

Illustration of Single Sign-On (SSO) using SAML in a web browser (Image source: Wikipedia)

The SAML Workflow

Understanding the SAML workflow is key to comprehending how SSO works:

User Access Request: The process begins when the user initiates access to a resource or service protected by an SP.
SP Authentication Request: The SP requests user authentication and redirects the user to the IdP.
User Authentication: The IdP authenticates the user’s identity through various methods, such as username and password, multi-factor authentication, or other credentials.
SAML Response Creation: After a successful user authentication, the IdP generates a SAML response that contains an identity assertion. This assertion communicates user identity to the SP.
User Return to SP: The user is then redirected back to the SP, carrying the SAML response.
SP Validation: The SP validates the SAML response to determine if the user should be granted access to the requested resource.

SAML Response Structure

The anatomy of a SAML response is essential to understanding how this authentication and authorization protocol works. Here’s a breakdown of the key components of a SAML response:

XML Structure: A SAML response is an XML document. It starts with the XML declaration, which specifies the XML version and character encoding. The rest of the document is enclosed within a pair of <samlp:Response> tags.
Response Attributes:

ID: An identifier for the SAML response.
Version: The version of the SAML protocol being used (e.g., 2.0).
IssueInstant: The timestamp indicating when the response was issued.
Destination: The URL of the intended recipient of the response (usually the service provider).
InResponseTo: The ID of the SAML request to which this response is a reply.

3. Issuer: The <saml:Issuer> element specifies the entity (usually the IdP) that issued the SAML response. This is an important element for verifying the response’s authenticity.

4. Status: The <samlp:Status> element indicates the overall status of the response. It contains a <samlp:StatusCode> element that can have various values such as “Success” or “Requester” (indicating an error).

5. Assertions: A SAML response can contain one or more assertions, which are statements about a subject, typically the user. There are two main types of assertions:

Authentication Assertion (saml:AuthnStatement): Contains information about the user’s authentication, like when and how they authenticated.
Attribute Assertion (saml:AttributeStatement): Carries user attributes (e.g., username, email) or additional information.

6. Signature: To ensure the integrity and authenticity of the SAML response, it’s usually signed using the IdP’s private key. The <ds:Signature> element contains the cryptographic signature.

7. Conditions: The <saml:Conditions> element sets constraints on the validity of the assertion. This includes attributes like NotBefore (the earliest time the assertion can be used) and NotOnOrAfter (the latest time the assertion can be used).

8. Subject: The <saml:Subject> element identifies the subject of the assertion, typically the user. Within it, you’ll find the <saml:NameID> element, which contains a unique identifier for the user.

9. Audience Restriction: The <saml:AudienceRestriction> element specifies the intended audience of the assertion, usually the service provider’s entity ID. It helps prevent assertion replay attacks.

10. Conditions: This part of the response defines the conditions under which the assertion is valid, such as the time frame and audience.

11. Attribute Statements: If included, the <saml:AttributeStatement> section contains user attributes and their values. These attributes are typically used by the service provider to grant access or populate user profiles.

12. Signature Verification: To validate the SAML response, the service provider must verify the signature. This involves checking the signature against the IdP’s public key to ensure that the response has not been tampered with.

A simplified example of a SAML identity assertion is presented below. This assertion communicates the user’s identity via the user’s username:

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_abc123" Version="2.0" IssueInstant="2023–10–18T14:30:00Z">
 <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://idp.example.com</saml:Issuer>
 <samlp:Status>
 <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
 </samlp:Status>
 <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_def456" IssueInstant="2023–10–18T14:30:00Z">
 <saml:AttributeStatement>
 <saml:Attribute Name="user">
 <saml:AttributeValue>john.doe@example.com</saml:AttributeValue>
 </saml:Attribute>
 <saml:Attribute Name="name">
 <saml:AttributeValue>John Doe</saml:AttributeValue>
 </saml:Attribute>
 </saml:AttributeStatement>
 <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
 <! - Signature data goes here →
 </ds:Signature>
 </saml:Assertion>
 </samlp:Response>

In real-world scenarios, SAML responses are usually encoded in base64 or other secure encoding schemes for transmission.

Captured SAML Response Containing URL and Base64 Encoded Data

SAML Security Considerations

The Role of Identity Assertions

Identity assertions are central to SAML security. They are part of the SAML response and contain user identity information, such as usernames, email addresses, or user IDs. These assertions are crucial for establishing trust between the IdP and the SP.

Tampering with Identity Assertions

One of the most significant security concerns in SAML is the possibility of identity assertion tampering. If an attacker can modify or forge identity assertions, they can potentially assume the identity of another user, resulting in unauthorized access.

Example:

<saml:AttributeStatement>
   <saml:Attribute Name="abc">
       <saml:AttributeValue>
           victim_user
       </saml:AttributeValue>
   </saml:Attribute>
</saml:AttributeStatement>

In the above example, the attacker has modified the identity assertion to impersonate “victim_user.”

The Importance of Signatures

To mitigate these risks, most SAML implementations incorporate digital signatures within SAML responses. Signatures help ensure the integrity and authenticity of the identity assertion. Here’s an example of a SAML response with a signature:

<saml:Signature>
        ......
     <saml:SignatureValue>
        dXNlcjE=
     </saml:SignatureValue>
         ......
</saml:Signature>
......
<saml:AttributeStatement>
   <saml:Attribute Name="abc">
       <saml:AttributeValue>
           victim_user
       </saml:AttributeValue>
   </saml:Attribute>
</saml:AttributeStatement>

In this case, the signature provides a level of assurance that the assertion has not been tampered with during transmission. It confirms the authenticity of the data.

Your Playground

Yogi’s Vulnerable SAML App

To provide a safe environment for our demonstrations, we will use “Yogi’s Vulnerable SAML App” as our virtual playground. Yogi’s app simulates a SAML environment with intentional misconfigurations and vulnerabilities. This allows us to explore real-world scenarios without affecting real systems.

You can access Yogi’s Vulnerable SAML App at yogisvulnerableapp.com. This web application will serve as a hands-on platform for our exercises and demonstrations.

SAML Raider

SAML Raider is a Burp Suite extension designed for discovering vulnerabilities in SAML security. This tool offers various functionalities, including the analysis of SAML messages, manipulation of SAML requests and responses, and the detection of vulnerabilities. SAML Raider extends Burp Suite’s capabilities for in-depth SAML security testing.

Key Features:

Analyze SAML messages.
Manipulate SAML requests and responses.
Detect SAML vulnerabilities.

In this section, we’ve established a strong understanding of SAML and its fundamental mechanisms. We’ve delved deep into the intricacies of SAML components, navigated through the SAML workflow, dissected response structures, and emphasized critical security considerations. With this foundation in place, let’s transition to the next part, where we’ll expose vulnerabilities in SAML that could potentially undermine the integrity of your authentication system.

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

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