RE: [wss] Recently discover WSS security threat

["DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>]

Here is the specific XPath expression I think you are looking for:

     <dsig:Signature
      xmlns:dsig="http://www.w3.org/2000/09/xmldsig#";
      xmlns:dsig-xpath="http://www.w3.org/2002/06/xmldsig-filter2";
      xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
       <dsig:SignedInfo>
         ...
         <dsig:Reference URI="">
           <dsig:Transforms>
             <dsig:Transform 
              Algorithm="http://www.w3.org/2002/06/xmldsig-filter2";>
               <dsig-xpath:XPath Filter="subtract">
                 /soap:Envelope/soap:Header/*
               </dsig-xpath:XPath>
               <dsig-xpath:XPath Filter="union">
                 id("123")
               </dsig-xpath:XPath>
             </dsig:Transform>
           </dsig:Transforms>
           ...
         </dsig:Reference>
       </dsig:SignedInfo>
       ...
     </dsig:Signature>

The dsig:Reference in the above example includes the entire soap
envelope minus all the headers plus the header with id "123" inline
inside of the soap:Header element.

If someone else adds headers in parallel to header with id 123, the
signature will still validate.

If someone else wraps header with id 123 in a "Plain Brown Wrapper", the
signature will fail.

&Thomas.

] -----Original Message-----
] From: Hal Lockhart [mailto:hlockhar@bea.com]
] Sent: Friday, May 27, 2005 11:13 AM
] 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_workgroups.php