RE: [wss] Recently discover WSS security threat

["Hal Lockhart" <hlockhar@bea.com>]

In case it was not clear, I was not the person who discovered this problem and in fact until recently I was of the opinion that excessive signing was always harmless.

I am not exactly sure who first noticed the threat. It is possible that more than one person saw it around the same time. I believe Mike MacIntosh was the first person to notice that signed data indicated by an Id attribute could be moved around without breaking the signature and that this could lead to attacks. Mike also explained this particular threat to me and the rest of the BSP WG on a call more than a month ago. I believe Ron Monzillo also noticed some time ago that threats could arise when more text was signed than necessary, but I cannot say whether he anticipated this specific attack.

Hal

> -----Original Message-----
> From: Hal Lockhart 
> Sent: Friday, May 27, 2005 2:13 PM
> To: wss@lists.oasis-open.org
> Subject: [wss] Recently discover WSS security threat
> 
> 
> 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.
> 
> 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.
> 
> 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_workgr
oups.php