Now a days many websites use SAML protocol for authentication and providing Single Sign On capability. For example, you can develop a website where you provide users the option of login with their gmail account so they do not need to register an account in your system. Users who already have a gmail account can simply click on the login link in your website where you redirect the user agent (i.e browser) to gmail. Then the users authenticate with gmail and after that get redirected back to your website. Inside your website, it captures the response sent by google and decides if the user successfully got authenticated to gmail. Upon a successful authentication, you treat the user as a valid user to your website (although the user may not have a registered account in your website) since your website trust google to provide identity. In SAML jargon, we can call Google as the Identity Provider to your website which is the Relying Party. Other than google, there are many third party Identity Providers who facilitate such capability which is providing Identity as a Service (IAAS). To make this scenario work, behind the scene we use SAML (Security Assertion Markup Language) [1] protocol. Following diagram explains the flow of this scenario.
In above diagram, the step 5 is where the trusted Identity Provider sends the SAML Authentication Response to the Relying Party website. The SAML Response is nothing but an XML message (when communication happens, the XML is base64 encoded and transmitted). A typical SAML Response would have the following formats. (Here I have explained the basic structure for simplicity). The Assertion element contains subject which carries the user identifier (i.e username) of the authenticated user. For integrity protection, XML signatures are used where assertion can be signed separately and the entire response (including assertion) also can be signed.
Not Signed
|
Response is signed, but assertion is not signed
|
Assertion is signed, but response is not signed
|
Both assertion and response are signed
|
<Response>
<Assertion>
<Subject>Tharindu</Subject>
</Assertion>
</Response>
|
<Response>
<Signature></Signature>
<Assertion>
<Subject>Tharindu</Subject>
</Assertion>
</Response>
|
<Response>
<Assertion>
<Signature></Signature>
<Subject>Tharindu</Subject>
</Assertion>
</Response>
|
<Response>
<Signature></Signature>
<Assertion>
<Signature></Signature>
<Subject>Tharindu</Subject>
</Assertion>
</Response>
|
The relying party can validate the signature/s (assertion and response) and decide if the message is not altered during communication (integrity is protected).
However although the response or assertion or both are signed using XML signatures, there are several well known XML signature wrapping (XSW) vulnerabilities in SAML protocol that are discussed in “On Breaking SAML: Be Whoever You Want to Be” research paper [3]. Following diagrams show how those vulnerabilities can be exploited by changing the structure of XML message of SAML response.
XSW1
| 
XSW2
|
XSW3
| 
XSW4
|
XSW5
| 
XSW6
|
XSW7
| 
XSW8
|
In above diagrams, red colored elements show the modified content of the message. Basically we can modify the subject inside the assertion (shown in red) and put another user’s username so that the relying party website will consider that the logged in user is that one. So simply we can pretend to be someone else and gain access to all the applications which the victim is authorized.
For this, we can use SAML Raider [2] which is an extension for Burp Suite that can be used for testing and manipulating SAML protocol based infrastructures. Basically, we can intercept the browser traffic when trying to login to the relying party website and when the SAML response is sent by the Identity Provider, we can capture it, modify using SAML Raider and forward to Relying Party. Here is an image of a SAML response captured using SAML Raider.
Once we capture the SAML response, we can simply select a particular XSW attack from the dropdown in SAML Raider and apply it. Then the original SAML response will be changed which is ready for the attack. An example XML structure for XSW6 attack is given below.
Original SAML Response
|
Modified SAML Response by SAML Raider
|
<Response>
<Assertion>
<Signature></Signature>
<Subject>Admin</Subject>
</Assertion>
</Response>
|
<Response>
<Assertion>
<Signature>
<SignedInfo></SignedInfo>
<Assertion>
<Subject>Tharindu</Subject>
</Assertion>
</Signature>
<Subject>Tharindu</Subject>
</Assertion>
</Response>
|
In the generated XML of SAML Raider, it does not show us which Subject element to modify to login as a different user. If we simply refer the above image, it is the 1st Subject element that appears in XML structure. However if we look at parent child relationship of the XML elements, actually we should modify the 2nd Subject element.
So the person who is testing this flow has to read the entire XML structure and and understand the parent child relationship of the elements and then identify the particular Subject element to be modified.
One thing is we can modify the image according to the order of the elements that appear in the XML structure as below so the person who is testing can simply check if the Subject element is the 1st one or 2nd one that he should modify. (If the image has same order of elements that appear so as in XML).
XSW6 - XML Structure 1
|
XSW6 - XML Structure 2
|
|  |
In this case we introduce a dependency with the code that generates the XML and the image that shows the order of elements. If the order gets changed later, we have to modify the image as well.
Since SAML Raider extension is open source, I modified the GUI of it adding a new text box as shown in below image, where the tester can simply enter the username of the victim account and generate the XML message.
Here inside the code, it will identify the particular Subject element that should be modified and it will automatically replace the original username of that with the victim’s username. This way, the tester does not need to know where to modify in the XML or else he may simply not be familiar with either SAML or XML even.
Considering this small feature improvement, the usability of the tool is heavily increased where even a user with less knowledge about XML or SAML can still use the tool and try out a signature wrapping attack on a SAML based system.
I hope to contribute to the original SAML Raider open source project with the code improvements I have done for improving the usability.
References
Tharindu Edirisinghe
Platform Security Team
WSO2
Excellent way of explaining, and fastidious piece of writing to obtain information concerning my presentation subject,
ReplyDeletewhich i am going to present in college.