Project 16: SAML (15 pts.)

What You Need

Purpose

To learn how SAML works and perform a simple attack on a broken SAML implementation.

Setting up Burp

You need to set configure Burp to act as a proxy and Firefox to send traffic through Burp, as you did in a previous project.


Task 1: Analyzing the Normal SAML Process

Using Single-Sign On

In Firefox, open this page:

http://samlol.samsclass.info

The SAMLOL Challenge page opens, as shown below. Notice the URL--it begins with "sp.samsclass.info". This is my Service Provider.

At the bottom, click Login.

A new page opens, with a URL starting with "idp.samsclass.info", as shown below. This is my Identity Provider.

Log in with a username of user1 and a password of pwd

You are redirected back to the Service Provider, as shown below. You are now authenticated as "user1".

This is how "Single Sign-On" works, which is also called "Federated Identity Management". The Service Provider is trusting another system to act as an Identity Provider.

Most websites work this way now, allowing you to use some other service, such as Google or Facebook, as an identity provider. This way, you don't need to make a new account, and the Service Provider doesn't see your password. Instead, they see a digital identity token from the Identity Provider and accept that as proof of your identity.

Can we modify or forge that token? Of course we can, and if the Service Provider isn't careful, they can be fooled by the forgery :)

Understanding SAML

SAML (Security Assertion Markup Language) is a common method used for single sign-on.

In Burp, click the Proxy tab and the "HTTP history" sub-tab.

You can see the process, as shown below.

Adding SAML Raider to Burp

Burp has an extension for this. In Burp, click the Extender tab and the "BApp Store" sub-tab.

In the left pane, scroll down and click "SAML Raider". In the right pane, scroll down and click the Install button, as shown below.

Logging Out and In Again

In Firefox, in the "SAMLOL Challenge" page, click Logout.

On the next page, click Login.

Log in with a username of user1 and a password of pwd

Examing Requests with SAML Raider

In Burp, click the Proxy tab and the "HTTP history" sub-tab.

Scroll to the bottom of the list and find the items colored purple, as shown below.

These are the requests and responses that contain SAML fields that can be manipulated by SAML Raider.

In Burp, in the history list, click one of the purple requests. In the lower pane, click the "SAML Raider" tab, as shown above.

There are interesting buttons here, like "Remove Signatures", but they are grayed out, because you can't modify anything in the History.

Following the SAML Process

In Burp, in the history list, click the POST request to a Host of idp.samsclass.info and a URL containing loginuserpass.php. In the figure below, it is request number 26, and it's colored orange.

In the lower pane of Burp, click the Request tab and the Params sub-tab.

You can see the username and password being sent to the server here, as shown below. This is clearly where authentication began.

In the lower pane of Burp, click the Response tab and the Raw sub-tab.

Scroll down and find the hidden field named "SAMLResponse", as shown below.

This is a large blob of base64-encoded XML data. It contains security assertions and signatures which the client's browser can send back in future requests as proof of identity.

In Burp, in the history list, click the POST request made to a Host of sp.samsclass.info and a URL ending in default-sp. In the figure above, it is request number 27.

In the lower pane of Burp, click the Request tab and the "SAML Raider" sub-tab.

In the lowest pane, the XML contents of the SAMLResponse are shown. Scroll through it. There are many items, including two long SignatureValue fields.

Near the end, find the "uid" attribute, as outlined in green in the image below.

This attribute identifies the user that has been authenticated, and the SAMLResponse is treated like an ID card. If it passes validation checks, it proves that this request is really from "user1" and the application provides personal data for "user1".


Task 2: Attempting Response Forgery with an Invalid Signature

We'll try to trick the Service Provider into thinking we are "admin" by altering the SAMLResponse.

We don't have a way to correct the signature, so we'll just ignore that problem and see if the Service Provider falls for it. Maybe the Service Provider isn't actually validating the signatures. This happens frequently, because people have difficulty correctly configuring validation tests and just disable them.

Logging Out

In Firefox, in the "SAMLOL Challenge" page, click Logout.

Turning On Interception

In Burp, click the Proxy tab and the Intercept sub-tab.

Click the "Intercept is off" button, so the message changes to "Intercept is on", as shown below.

Logging In

In Firefox, click Login.

Burp intercepts the response and pops up an "Intercept" tab.

In Burp, click the Forward button until it stays grayed out. When I did it, it took three clicks.

Firefox should now show the login page, as shown below. Enter a username of user1 and a password of pwd and click the Login button.

Burp intercepts the response and pops up an "Intercept" tab.

Notice that this request does not have a "SAML Raider" tab in the bottom pane, as shown below. This request is not useful to us, so click the Forward button.

The next request is the one we want. In the lower pane, click the "SAML Raider" tab. In the lowest pane, scroll to the bottom and find the "uid" attribute, which is currently user1. Double-click it, delete the current value, and type in admin instead, as shown below.

Burp highlights the line in yellow to show that it has been modified.

In Burp, click the "Intercept is on" button to allow traffic to resume.

In Firefox, an error message appears, as shown below, saying "Reference validation failed". The Service Provider checked the signature, and detected our forgery attempt, so we did not win yet.


Task 3: Attempting Response Forgery without the Signature

We'll try to trick the Service Provider into thinking we are "admin" by altering the SAMLResponse. Since it rejected our previous attempt with an invalid signature, we'll try removing the signature altogether.

Logging Out

Firefox is showing an error message now, and it's not obvious whether we are still logged in or not.

In Firefox, open this page:

http://samlol.samsclass.info

Click Login.

If you see the "UNAUTHORIZED" message, click Logout and Click Login again, so you see the login page shown below.

Turning On Interception

In Burp, click the Proxy tab and the Intercept sub-tab.

Click the "Intercept is off" button, so the message changes to "Intercept is on", as shown below.

Logging In

In Firefox, enter a username of user1 and a password of pwd and click the Login button.

Burp intercepts the response and pops up an "Intercept" tab.

Notice that this request does not have a "SAML Raider" tab in the bottom pane, as shown below. This request is not useful to us, so click the Forward button.

The next request is the one we want. In the lower pane, click the "SAML Raider" tab.

In the the "SAML Raider" section, in the upper left pane, click the "Remove Signatures" button.

An orange message appears, saying "Message signature successful removed", as shown below.

In the lowest pane, scroll to the bottom and find the "uid" attribute, which is currently user1. Double-click it, delete the current value, and type in admin instead, as shown below.

In Burp, click the "Intercept is on" button to allow traffic to resume.

In Firefox, the winning page appears, with the flag, as shown below. My SAML configuration has a "fail-open" vulnerability, which misinterprets a missing signature as valid.

Saving the Screen Image

Make sure your screen shows the flag, as shown above.

Turning In Your Project

Email the image to cnit.129s@gmail.com with a subject of "Project 16 from YOUR NAME".


Posted 4-26-18

References

How to set up a broken SimpleSAMLPHP server