Bypassing authentication using the Security Assertion Markup Language (SAML)
SAML or the “Security Assertion Markup Language” is used widely in commercial applications. It is an XML based markup language used to facilitate identity checks on larger-scale applications.
SAML is used for exchanging authentication and authorization data, particularly between identity providers and service providers. Today, we are going to talk about come common misconfigurations of SAML authentication, and how they can be exploited by attackers to bypass access control.
How does SAML work?
The most common use case for SAML is to facilitate browser-based Single Sing-On (SSO).
Single Sign-On (SSO)
But what exactly is Single Sign-On? Single Sign-On 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.
The implementation of SSO is easy if multiple services are located under the same parent domain. Like these two versions of Facebook:
These two services are located on the same domain, facebook.com. In this case, SSO can be easily achieved by sharing cookies across subdomains:
Set-Cookie: cookie=abc123; Domain=facebook.com; Secure; HttpOnly
(By specifying a cookie’s domain like this, the cookie would automatically be shared with all subdomains.)
However, cookies cannot be shared across different domains. So Facebook.com and Messenger.com cannot share cookies, because they don’t share a common parent domain:
And this is where SAML comes into play.
Managing user identity
SAML enables SSO by managing the interaction between three parties: the user, the identity provider, and the service provider.
The user is you, who has the right to access your information on a website. The identity provider refers to the server that is in charge of authenticating the user and passing on user information to the service provider. Whereas the service provider refers to the actual site that the user intends to access (in this example, Facebook.com, and Messenger.com).
This system allows companies with multiple web services to only manage a centralized source of user credentials (the identity provider), instead of keeping track of users for each site. It also eliminates the need for users to log in multiple times when using the services provided by the same company.
How to bypass SAML controls
As you can see from the diagram above, the key to accessing resources held by the service provider is in the SAML response. If an attacker can control the SAML response passed to the service provider, they can authenticate as someone else.
Locate the SAML response
First and foremost, an attacker must locate the SAML response. This can usually be done by intercepting the requests going between the browser and the service provider using a proxy. The SAML response will be sent when the user’s browser is logging into a new session for that particular service provider.
Note that the SAML response isn’t always passed in plain XML format. It might be encoded in base64 or other encoding schemes.
Analyze the SAML response
Once the SAML response is located, an attacker would analyze its content and see which fields are used for determining the identity of the user. Since the SAML response is used to relay authentication information to the service provider, there must be some fields that communicate that data.
For example, look for field names like “username”, “email address”, “userID”, etc. Try tampering with these fields.
Check the SAML signature
SAML usually uses a signature (and sometimes encryption) to ensure data integrity. But as I mentioned previously in the JWT post, signature-based security is not always well implemented.
You can read more about signature-based tokens in that post, but here, I will discuss some of the most common misconfigurations present in SAML implementations.
- Signature does not exist or is not verified
If the SAML response lacks a signature or if the signature of the SAML response is not verified at all, all you’d need to do is to tamper with the fields used for authentication. Then, suddenly, you’re in!
2. Signature is only verified when it exists
In this case, you could try removing the signature value from the SAML response. Sometimes, this is the only action required to bypass security checks. There are two ways that you can do this: empty out the signature field or remove the field entirely.
3. Predictable signature
When the SAML response signature used by the application is predictable, you can simply recalculate the signature and forge a valid SAML response.
4. Use of encryption with a weak signature
What if parts of the SAML response is encrypted? We’ll probably explore this in later posts, but encryption is not a good way to ensure message security. And there are plenty of ways to tamper with an encrypted message, even without breaking the encryption.
Especially when one of the above issues exists, and when the encryption scheme used is weak, the attacker can potentially control the entire message, thus hijacking the authentication process.
Reencode and send the SAML response
After tampering with the SAML response, you can simply reencode the message into its original form and send it back to the service provider. The service provider will use that information to authenticate you to the service. If you are successful, you can obtain a valid session with the victim’s account.
Other SAML security considerations
As with all user input, SAML messages should be sanitized before being used. Otherwise, depending on how the elements in the SAML response is used, attackers might be able to achieve SQL injection, stored-XSS, XXE and a whole host of other nasty web attacks.
Read more about SAML specifications and its history here!
Disclaimer: This post was written to bring attention to SAML vulnerabilities and help developers recognize common pitfalls. Please do not use this information to attack sites or impersonate others.
Trying this on systems where you don’t have permission to test is illegal. If you’ve found a vulnerability, please disclose it responsibly to the vendor. Help make our Internet a safer place.