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 :)
In Burp, click the Proxy tab and the "HTTP history" sub-tab.
You can see the process, as shown below.
In the left pane, scroll down and click "SAML Raider". In the right pane, scroll down and click the Install button, as shown below.
On the next page, click Login.
Log in with a username of user1 and a password of pwd
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.
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".
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.
Click the "Intercept is off" button, so the message changes to "Intercept is on", as shown below.
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.
In Firefox, open this page:
Click Login.
If you see the "UNAUTHORIZED" message, click Logout and Click Login again, so you see the login page shown below.
Click the "Intercept is off" button, so the message changes to "Intercept is on", as shown below.
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.
Email the image to cnit.129s@gmail.com with a subject of "Project 16 from YOUR NAME".
Posted 4-26-18