Re: [wss] Recently discover WSS security threat

[Michael McIntosh <mikemci@us.ibm.com>]

"Hal Lockhart" <hlockhar@bea.com> wrote on 05/27/2005 02:12:59 PM:

> The following issue is being discussed in the WS-I BSP WG. I think 
> members of this TC will want to know about it. The TC may want to 
> adress it in some way under security considerations.

Just to give some background since the WS-I list is not public...

This issue boils down to that fact that an XML Signature over an element
which is reference in the signature via an IDREF protects the element from
modification and complete removal. It does not protect the element from
being moved around within the document. This is not typically a huge 
problem
when the document schema is rigid and validation is performed.

SOAP describes a processing model whereby header elements specify
processing targeted at roles/actors and with the mustUnderstand attribute
provided for the originator to indicate whether the header can be safely
ignored by the target if the target does not know how to process the
header.

When XML Signatures are applied to SOAP messages, the optional header
provides a convenient place for an attacker relocate signed elements.

Here is an example of the original, untampered with message:

<soap:Envelope>
  <soap:Header>
    <wsse:Security mustUnderstand="0">
      <ds:Signature>
        with references to "#theReplyTo" and "#theBody"
      </ds:Signature>
    </wsse:Security>
    <wsa:ReplyTo mustUnderstand="1" 
wsu:Id="theReplyTo">http://www.me.com/MyService</wsa:ReplyTo>
  </soap:Header>
  <soap:Body wsu:Id="theBody">
    Hello World.
  </soap:Body>
</soap:Envelope>

Here is the same message after being tamptered with:

<soap:Envelope>
  <soap:Header>
    <wsse:Security mustUnderstand="0">
      <ds:Signature>
        with references to "#theReplyTo" and "#theBody"
      </ds:Signature>
    </wsse:Security>
    <wsa:ReplyTo 
mustUnderstand="1">http://www.you.com/YourService</wsa:ReplyTo>
    <whatIsThis mustUnderstand="0"><wsa:ReplyTo mustUnderstand="1" 
wsu:Id="theReplyTo">http://www.me.com/MyService</wsa:ReplyTo><whatIsThis>
  </soap:Header>
  <soap:Body wsu:Id="theBody">
    Hello World.
  </soap:Body>
</soap:Envelope>

Since the signed elements have not changed, the signature will verify. 
However, the processing expected by the sender will not occur.

You can similarly use the actor/role attribute to cause a header to be 
ignored. For example:

<soap:Envelope>
  <soap:Header>
    <wsse:Security mustUnderstand="0">
      <ds:Signature>
        with references to "#theReplyTo" and "#theBody"
      </ds:Signature>
    </wsse:Security>
    <wsa:ReplyTo 
mustUnderstand="1">http://www.you.com/YourService</wsa:ReplyTo>
    <whatIsThis role="urn:Nobody"><wsa:ReplyTo mustUnderstand="1" 
wsu:Id="theReplyTo">http://www.me.com/MyService</wsa:ReplyTo><whatIsThis>
  </soap:Header>
  <soap:Body wsu:Id="theBody">
    Hello World.
  </soap:Body>
</soap:Envelope>

I had been working on a research paper on this subject for a while. A 
proposal was made in the WS-I wrt what a receiver should/must do when it 
is given a message containing signed elements that it did not expect. The 
proposal by Hal was to quietly ignore it. I saw this as eliminating one of 
the obvious countermeasures to this attack which would be for receivers to 
reject messages which contained signed elements in unexpected places.

> 
> Assume a receiver that has a policy that specifies acceptable trust 
> roots, etc. Assume that the policy states that the SOAP Body of any 
> request received must be signed. Further assume that there is some 
> kind of SOAP header, we will call the foo header, which is optional 
> but specifies important processing to be done on the message by the 
> receiver. The receiver's policy says that if the foo header is 
> present it must be signed. If the foo header is present, this 
> receiver can (and will) correctly process it.
> 
> The receiver has an implementation which consists of (at least) a 
> security layer and an application layer. When a message is received,
> the security layer verifies signatures, performs decryption, checks 
> passwords, etc. It may enforce some security-related policies as 
> well, but for example, it is not responsible for the SOAP 
> MustUnderstand logic. Once the security layer is finished processing
> a message it passes the message (with the decrypted data) on to the 
> application. It also passes along information relating to the 
> processing it did, for example, what parts of the message were 
> signed with what tokens, what was encrypted and so forth.
> 
> Now let us talk about attacks.
> 
> 1. If the sender is so foolish to sign something, e.g. the foo 
> header, and put nothing else under that Signature, there is a simple
> attack. (Assume the body is signed under a different Signature.) A 
> MITM attacker can simply remove the Signature and the foo header. 
> The receiver cannot tell they were ever present.
> 
> 2. So to prevent attack #1, the sender uses two <ds:References> in a
> single <ds:Signature> to sign the Body and the foo header. This is 
> where the Plain Brown Wrapper attack can happen. A MITM attacker 
> wraps the foo header in some made up header, let's call it the bar 
header.
> 
> Under the policies we have assumed above, the security layer will 
> verify the signature as being correct, because the text has not been
> altered, only moved to a new spot in the message. The body is 
> signed, so that policy is satisfied. The foo header is not seen, but
> that is allowed. 
> 
> The bar header is seen and not understood, but since it is marked 
> MU=F, the receiver is allowed to ignore it. Presumably the 
> application does not dig thru unknown SOAP headers looking for 
> elements it recognizes. Anyway, a foo element in a bar header may 
> mean something different from a foo header, since the app does not 
> know what a bar header is supposed to look like.
> 
> ------
> 
> Now there are some ways to fix this which I think would be incorrect
> in that they would result in reduced flexibility and brittle 
> applications which would break every time the network changes. These 
include:
> 
> Treat presence of foo header as mandatory.
> 
> Reject any message where too much is signed.
> 
> Reject any message with unknown stuff in it.
> 
> Specify the ds:Reference in such a way that intermediaries cannot 
> add SOAP headers.
> 
> ----
> 
> I am not completely sure what the best way to counter this is. One 
> approach is for the receiver to take special care. For example the 
> receiver might follow a rule like:  If you receive something with a 
> signature over something that your policy requires to be signed, you
> need to make sure you can process EVERYTHING under the same signature.
> 
> Another approach that has been mentioned is for the sender to use 
> some kind of Xpath expression in the reference list instead of an Id
> Attribute. I am concerned that this might prevent reasonable 
> intermediary actions, but I would have to see specific Xpath 
> expressions proposed before making a judgement.

//soap:Envelope/soap:Header/wsa:ReplyTo[@wsu:Id="theReplyTo"]

> 
> Hal
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>