How I Bypassed SAML Authentication, Leading to Admin Panel Access.
PreviousHow i found a Privilege Escalation via Impersonation Features featureNextHow I was able to discover ATO Via IDOR vulnerability
Last updated
Last updated
Hey, hunters!,
It’s your buddy Ahmed Tarek again with a new interesting finding. I’ve discovered a critical security flaw in the SAML authentication system. This vulnerability can allow an attacker to bypass authentication and gain unauthorized access to the system, including potential administrative privileges.
Grab ur coffe, and let’s get started! 😉
SAML (Security Assertion Markup Language) is used for Single Sign-On (SSO). it is a feature that allows users to access multiple services without logging in multiple times, For example, if you are logged into facebook.com, you wouldn’t have to reenter your credentials to use messenger.com.
SAML uses XML to send authentication data between an Identity Provider (IdP) and a Service Provider (SP), so when a user tries to access certain services, the identity provider can provide SAML attributes to the service provider once the user logs in first to Single Sign On with the identity provider. The service provider asks the identity provider for authentication and authorization.
Each identity provider and service provider need to agree upon the configuration for SAML. Both ends need to have the exact configuration for the SAML authentication to work.
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 ( uniqe ) .
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:
In real-world scenarios, SAML responses are usually encoded in base64 or other secure encoding schemes for transmission.
well as usual, let’s consider our target as example.com After collecting subdomains through various methods like subdomain enumeration, reverse DNS lookup, and Google dorks, I found a subdomain: login-otp.example.com/login.
so the first thing you gotta do when you find a login page is to check the source code for any leaks or useful information. Unfortunately, i didn’t find much, except that email addresses that ends with company’s domain name were getting special treatment.
BORING Anyway, let’s continue.
i entered any random shit and clicked login to inspect the request
the request to https://login-otp.example.com/SAML2/SSO/POST with the SAMLRequest parameter and my entered data
what I did was decode the original SAML response and play some games with it for hours:
— If you got lost in here, refer to the “SAML Response Structure” section in the first part of the write-up for guidance —
Password:
well i didn’t do anything with the password, because i enterd the comapny email so it is no use
2. i changed the ID :
ID=”b261eb3afa7ee41b11f2965608172e35" :
Every request has a unique ID and technically we are sending a new reqeust so it needs a new ID, I generated a new ID using UUID.
3. Removes all <Signature> elements from the manipulated response.
By doing this i was able to bypass the validation mechanisms that would otherwise ensure the response’s authenticity. This step is critical in testing how a system handles tampered or unsigned responses.
4. Modify Attributes
I updated specific attributes in the SAML response to test the system’s handling of altered data
Well, that’s kinda boring (even tho manually it’s more efficient), so I made a Python script to automate the whole process of tweaking the SAML response : https://github.com/0xxnum/saml_injector/blob/main/saml_injector.py
This script takes a SAMLResponse as a command-line argument, decodes it from base64, and parses the XML structure. It removes the original digital signature and modifies specified attributes within the response, such as the OTP, email, and user identifier (in my case). After applying these changes, it re-encodes the modified SAMLResponse back to base64 and prints the new value. This modified response can be used to simulate attacks or test vulnerabilities in SAML-based authentication systems, and you can customize the attributes based on your target’s requirements.
and then i ran the script in python3 with the oringnal SAMLResponse as argument
and then i Replaced the parameter value with the one given by the script and forward the request, and the admin acccount had been created!
The developer mistake is not implementing proper signature validation and verification for SAML responses. This failure allows attackers to modify the SAML response, including altering IDs, attributes, and removing signature elements, enabling unauthorized access or privilege escalation.
Verify signature validation rigorously. Always test how a system handles tampered or unsigned SAML responses. Ensure the system enforces proper signature validation and does not accept altered or unsigned responses. Validate that the SAML response’s integrity and authenticity are maintained by the service provider.
you can follow me to see more Write-Ups
For tipa and collaboration, contact me on Discord: 0x_xunm
