The XML Signature Standard
The XML Signature standard is an immensely complicated beast, designed by a working group involving all the big names, and intended to be a one-size-fits-all solution to building tamper-resistant XML documents. Unfortunately, as is often the case, one-size-fits-all becomes the-only-size-fits-nobody.
In a normal application of digital signatures, we take a document to be signed, run it through a cryptographic hash function, and then apply a digital signature algorithm to the hash. If the document received is exactly identical, the signature will validate, whereas if even a single bit changes, the signature becomes invalid and the document is rejected.
Unfortunately, XML Signatures have one killer feature - the standard allows us to sign part of the document instead of the whole document, and embed the signature within the same document it’s supposed to be validating - so called inline signatures. The signatures do this by containing a “Reference” to the part of the document they sign, usually by referring to the “ID” attribute of an XML element, but in theory allowing anything in the XPath standard to be used as an expression. I can, in theory, write a signature anywhere within a document that refers to the “third to last <foo> element”, or equally vague expressions.
When validating an XML signature it’s not enough to ask the question “is this a valid signature from this signer?”. We also have to ask “is this signature present, referring to the right part of the document, applying all the right canonicalizations, from the expected signer AND valid?”. All too often, at least one of these checks is not implemented.
Getting Started with SAML Raider
While all attacks described here can be carried out without many tools, SAML Raider1, a Burp proxy plugin, is a useful tool for testing the common cases.
Checks
As described above, signatures can appear in various places within the SAML message and cover various parts of the message. By keeping the content of the message but adding new parts and modifying the structure of the remaining parts, we can craft messages that are still technically signed correctly, but may be interpreted by SAML libraries as having crucial parts signed when they are not.
Whenever the Service Provider is supposed to check something, there’s an opportunity for them to fail to do so or do so incorrectly, giving us an opportunity to bypass the signature. Enable Burp’s interception, capture the SAML request, and try these transformations. Each one should be done against a fresh, valid log-in attempt, as there is usually a nonce preventing us from replaying the same request repeatedly.
For repeated attempts, you may benefit from intercepting a single endpoint only in Burp using interception options like this:
Is a Signature Required?
The SAML standard requires that all messages passed through insecure channels, such as the user’s browser, be signed. However, messages that pass through secure channels, such as an SSL/TLS back channel, do not have to be. As a result of this, we’ve seen SAML consumers that validate any signature present, however silently skip validation if the signature is removed. The software is essentially presuming that we’ve already checked that a message coming from an insecure channel is signed, when this isn’t the case.
The impact of this is the ability to simply remove signatures, and tamper with the response as if they weren’t there. SAML raider can test this one pretty easily:
Is the Signature Validated?
Validating XML signatures is extremely complicated, as the standard expects a series of transformation and canonicalization steps to be applied first (e.g. to ignore the amount of white space). The difficulty of this makes it extremely hard to validate signatures without a fully featured XML Signature library behind you. The impacts of this are:
- Developers don’t generally understand the internals of signature validation.
- Intermediate tools, such as web application firewalls, have no idea whether signatures are valid or not.
- Libraries may have configurable options, such as lists of permitted canonicalization methods, which are meaningless to the developer.
The difficulty of implementing this standard, and the somewhat arcane nature of it, leads to the issues we will now look at.
First, testing whether the signature is validated at all is simple - change something in the supposedly signed content and see if it breaks.
Is the Signature From The Right Signer?
Another stumbling block is whether or not the receiver checks the identity of the signer. We haven’t seen this one done wrong, but SAML Raider will make this fairly easy to test.
Copy the certificate to SAML Raider’s certificate store:
Save and self-sign the certificate, so we have a self-signed copy of the same certificate:
Now we can re-sign the original request with our new certificate, either by signing the whole message or the assertion:
You could identify which of those two options is normally used by your recipient, or just try each of them.
Is the Correct Part of the Response Signed?
How XSW Attacks Work
The SAML standard allows signatures to appear in two places only:
- A signature within a
<Response>tag, signing the Response tag and its descendants. - A signature within an
<Assertion>tag, signing the Assertion tag and its descendants.
The SAML standard is very specific about where signatures are allowed to be, and what they are allowed to refer to.
However, nobody implements XML signatures in all their gory complexity for use in SAML alone. The standard is generic, and so are the implementations and software libraries built for it. As a result, the separation of responsibilities looks like this:
- The XML Signature library validates according to the XML Signature standard, which allows anything to be signed from anywhere.
- The SAML library expects the XML Signature library to tell it whether or not the response is valid.
Somewhere in the middle of these two components, the rules about what we have to sign are often lost. As a result, we can often have our signature refer to a different part of the document, and still appear valid to the recipient.
By copying the signed parts of the document, and ensuring the signatures point to the copies, we can separate the part of the document that the XML Signature library checks from the part of the document that the SAML library consumes.
Automated XSW
SAML Raider will automate the most common attacks of this form for you:
Try selecting each of those options from the drop-down, clicking “Apply XSW” and sending the request on. If this doesn’t cause an error, try doing it again and changing the username or other user identifier in each place it appears in the SAML XML.
Limitations of SAML Raider
While SAML Raider will test the common cases, there are a few attacks that require a deeper understanding:
- Producing a response that will validate against an XML schema (requires hiding the shadow copy inside an element that may contain
xs:any). - Bypassing validation when both the Response, and Assertions within it are signed and checked.
- Bypassing XML signatures in non-SAML contexts, for example SOAP endpoints using WS-Security extensions.
Manual XSW
If SAML Raider’s out-of-the-box options don’t work, you may want to try a manual approach:
- Decode the Base64-encoded content to access the SAML Response XML.
- Check that the signature’s
<Reference>tag contains the ID of a signed element. - Copy the signed content somewhere else in the document (often the end of the
<Response>is OK, if XML Schema validation is in play try finding somewhere to copy it that doesn’t break the schema.) - Remove the XML signature from the copy, leaving it in the original. This is necessary as the XML encapsulated signature standard removes the signature that is being validated. In the original document, this was the contained signature, so we have to cut it out from the copy.
- Change the ID of the original signed element to something different (e.g. change a letter).
- Change the content of the original assertion.
- Re-encode as Base64, put in to the request and forward on.
If the signature validation points to the copy, it will ignore your changes. With practice, you can complete this process pretty quickly if strict time limits on requests are in play.
SAML Pentest Checklist
- Does the SAML response pass through the web browser?
- Is it signed? If not, try changing the content.
- Is it accepted if we remove the signatures?
- Is it accepted if we re-sign it with a different certificate?
- Do any of the eight transforms baked in to SAML Raider produce a result that is accepted?
- If you change such a response, is the modified response accepted?
- Might one of SAML Raider’s limitations noted above apply? If so, you may neeed.\
please do comment below if you have any question.
