Pentesters Can Take Advantage of Weakness in SAML

When penetration testers examine the security of applications, we employ a number of tools. We recently wrote about keeping track of browser options. Another protocol that we use to test is the Security Assertion Markup Language (SAML), a popular XML-based authentication information exchanger for implementing single sign-on (SSO) authentication.

The protocol works like this:

A user accesses the application URL (the service provider).

The application initiates the SSO request and redirects the user to the SSO URL (the identity provider) if already not logged in.

The user enters valid SSO account details and the identity provider generates SAML response code and sent it to the service provider.

The service provider (application) verifies the SAML response code and authenticates the user.

This protocol considered secure, with the following advantages:

Users need to authenticate only once online to access different services, reducing the chances for identity theft and phishing attacks. Because SAML response code controls authentication attempts, users account details never leave the identity provider firewall.

The unique user accounts are taken care of by the identity provider, so users do not need to remember additional authentications for each application. This even eliminates separate action for each service such as changing or forgotten passwords, etc.

An administrator has one console to control all users.

In spite of this generally secure structure, however, we have observed interesting privilege escalation issues through SAML response tampering.

Here is the scenario:

To test authorization, we created two user roles.

Normal user, aka testuser, with limited access.

Administrator user, aka adminuser, with full access.

We launched the application SSO login URL and used testuser to log in.

We ran a man-in-the-middle login process using the Burp proxy server to examine the SSO login.

After entering testuser’s valid id and password, we observed that an intermediary request was used to generate the SAML response and make the SSO.

SAML assertion message generated from a successful authentication.

We intercepted the response for this request.

We copied the Base64-encoded SAML response and decoded the value using decoders available online.

While examining this decoded value, we saw that the value had a parameter “testuser.”

We replaced this value with “adminuser” and again encoded the value with Base64.

Login ID in decoded SAML response.

We placed this edited SAML response into the intercepted response in Step 5 and continued the traffic.

The result was that testuser’s privilege had escalated to a higher level user and that we had effectively logged on as adminuser.

This is one useful attack scenario while pentesting with SAML. Other SAML-specific attacks can be found in the OWASP SAML cheat sheet.

We recommend that application service providers validate user authorization based on the complete original SAML assertion message instead of only on a single element such as the “saml NameID” in the preceding example.

In this blog , we shared a real-time scenario while doing a penetration test. We didn’t look deeply into the cause. That is the responsibility of the service provider and identity provider for SAML. We could have used Burp Base-64 encoding and decoding for the response tampering. We gave a simple online reference for users not familiar with Burp or who use another proxy. We did not write with a specific client product in mind. We may in the future take a look at a detailed authentication process regarding weak SAML implementation.

In this blog , we shared a real-time scenario while doing a penetration test. We didn’t look deeply into the cause. That is the responsibility of the service provider and identity provider for SAML. We could have used Burp Base-64 encoding and decoding for the response tampering. We gave a simple online reference for users not familiar with Burp or who use another proxy. We did not write with a specific client product in mind. We may in the future take a look at a detailed authentication process regarding weak SAML implementation.

The SAML specification demands that a SAML assertion MUST be signed and a SAML implementation receiving an assertion MUST validate its signature. Hence this is a failure of a particular awkward SAML implementation rather than a weakness in the protocol itself as the title suggests. It would be good to include the software/vendor name of the SAML implementation in the title rather than generically referring to “SAML” to avoid confusion and to warn its users.