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.