Articles & Blogs
Penetration Testing Anecdote Series
Authentication bypass due to weak verification of SAML Token
What is authentication bypass in web applications?
The web application vulnerability – authentication bypass occurs when there is improper validation of the user’s identity on the server-side.
Generally, a successful authentication bypass requires the attacker to have knowledge of either the username/email ID unlike the case of SQL injection where the attacker can attempt to log into the application using any user.
What is SAML?
SAML (Security Assertion Markup Language) is a standard for authenticating and authorizing users across multiple applications by leveraging the logged-in session of one application.
In simple words, you log into a dashboard where you see multiple applications like Salesforce, AWS, Slack, ADP, etc. and when you click on any one of the icons, you would directly get signed into that application.
Unlike other tokens, the SAML token is XML-based for transferring identity between two parties.
So, who are these two parties? 1. Identity Provider (IdP) 2. Service Provider (SP). IdP is responsible to authenticate the user and subsequently sending the token to the service provider and SP trusts the identity provider and authorizes/authenticates the user to access the requested application.
Some applications implement SAML for the clients to authenticate themselves and use the application. So, the question is what kind of verification is done by the SP in the back-end? Is it possible to modify the token and login to the application as another user?
In this blog, we’ll walk you through an authentication bypass mechanism that allowed us to log into the application as any user with just the knowledge of the username. This can be achieved due to insecure logic & validation implemented at the backend.
Understanding the authentication process
The application uses Okta which is an identity platform that offers authentication and authorization services for the application. Let’s say the target domain is testproduct.com. After hitting this domain, we get redirected to the Okta login page with a domain like testcorp.oktapreview.com which looks like the below screenshot.
Using valid credentials, we log into the Okta dashboard. In My Apps, we see all the applications for whom we could obtain direct access without re-entering the credentials.
Let’s assume our app testcorp.com is included in it. After clicking our app, we directly get signed into it.
We now attempt to understand the process of how we got logged into testproduct.com from testcorp.oktapreview.com.
By setting up an interception proxy – Burp suite, we observe a request where testcorp.com receives a SAML token with the parameter name SAML Response.
Bypass #1: Pre-remediation
The next request was responsible to authenticate the user, or in other words, activating the user’s session.
By changing the username value from 252233 to 252234, we were able to log into the application as a different user. We confirmed this by entering random number which gave us an error indicating that the user was invalid. Thus, confirming that username we used earlier was indeed valid.
By trying different values for the username parameter and repeating the above steps, we were able to log into the application as an administrator user.
Test Corp went ahead and implemented a fix to remediate the above vulnerability.
Bypass #2 : Post application of the first fix
Test Corp leveraged an encryption mechanism which prevented us changing the username value as the parameter was not unguessable.
We started looking at the different ways to decrypt the parameter through recon. We also wrote multiple scripts, but they weren’t successful in recreating the original value.
After many failed attempts we were curious to understand how the application knew which username parameter & value to encrypt, as we didn’t see any username being transmitted in the request via plaintext.
There was still a puzzle associated to the SAML token as we hadn’t looked at understanding it.
By using URL Decode then Base64 decode, we obtained decoded XML data containing the username 2522334.
The response had the encrypted username. Hence, sending a request by changing the username in the SAML token and encoding it back to its original format, resulted in a different encrypted username which caught our eye. So, we used this new username in the subsequent request with URL encoding which successfully logged us in.
So, the application was accepting the username from the SAML token & it then encrypted it. Subsequently, it was being sent in the request where the activation occurred.
Conclusion
Our understanding of the application led to the conclusion that rather than validating the token, the application extracted the username and verified whether it exists in their database or, not. This allowed an attacker to authenticate as any user, with a valid username.
Posted by:
Senior Security Engineer at Accorian