Avoiding XML signature attacks

The other day the security folks over at DUO security posted about a class of bugs in several popular SAML implementations: https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations

This is an excellent piece of work that shows how hard has turned out to be for implementors to do xml digital signature and encryption correctly. Writing security sensitive code is often hard because its not enough to make stuff that “works”, your code has to be “secure” aswell.

A lot of people have asked me and my collegues in the Swedish eIDAS project about how to avoid being affected by this bug and the DUO blogpost clearly sais that the software listed in the post is not the only software affected by this bug – its just the only software the DUO team looked at that was affected by the bug.

The further you get from the R&E federation community (where my $dayjob is), the more common it is to find custom SAML implmementations and there are probably a lot of these implementations that the DUO team never looked at.

I decided to do a writeup of my understanding of how to avoid this and a class of similar bugs that arise from not doing c14n correctly.

For the rest of this post I assume that you have a c14n and xmldsig library that “does the right thing” – the question facing you as a coder is this:

How do I safely apply my libraries to validate an xml signature and do something with the result?

The key to avoiding this sort of bug lies in a proper way to do xml signature validation.

Lets start by showing (pseudocode) how NOT to do it:

    xml = parse(some xml text)
    if (is_valid(xml)) {

This is BAD and dangerous. There have been numerous wrapping attacks published in the last few years – the latest one from DUO is just the last in a long row of similar attacks. The right way to do xml signature processing goes something like this:

    xml = parse(some xml text)
    valid_xml = validate(xml)
    if (valid_xml != NULL) {

The point is that the “validate” function should return the valid references (could be > 1 !) after c14n processing. Specifically the “validate” function should do reference processing, c14n and return the resulting valid XML trees.

This approach protects against a whole class of attacks including this latest one providing c14n is done correctly.

We strongly encourage all implementors to review their code and make sure you follow the above pattern (and avoid the anti-pattern).

This advise applies to more than SAML – anytime you do xml signature validation this is how you should do it. However if you are running SAML specifically then there is an additional measure you can take to avoid several attacks: encryption.

There is currently no known practical attack that can be launched against SAML implementations that use encrypted assertions. Using encrypted assertions therefore provides an extra layer of security against attacks.

Implementers should not rely on encrypted assertions to avoid these problems but should follow the patters described above. But for those who are using 3rd party software that may still be vulnerable, encrypting the assertion (or enforcing encrypted assertions in responses) will at least avoid any currently know attack that would lead to identity spoofing using SAML.

Thx to Stefan Santesson <stefan at aaa-sec.com>

Comments Off on Avoiding XML signature attacks

Filed under Uncategorized

Comments are closed.