[ http://issues.apache.org/jira/browse/WSS-33?page=comments#action_12366636 ]
Thomas Leonard commented on WSS-33: ----------------------------------- Please also add the NOTICE file created by the patch to svn. Thanks! > Signature checking vulnerability > -------------------------------- > > Key: WSS-33 > URL: http://issues.apache.org/jira/browse/WSS-33 > Project: WSS4J > Type: Bug > Reporter: Thomas Leonard > Assignee: Davanum Srinivas > Attachments: sig-security.patch > > [ This vulnerability was reported privately by email on Fri, 13 Jan 2006. > Making it public at the request of Davanum Srinivas. ] > Summary: given an example of a SOAP message signed (and optionally encrypted) > by some user, an attacker can invoke any method on any WSS4J-protected > web-service and authenticate as that user, despite not having their private > key. A suitable example message can be acquired either by sniffing (e.g., > with tcpflow) or by waiting for users to invoke one of my own web services. > This attack has been tested using the sample SecBindingImpl service provided > with WSS4J. > Full description: > When WSS4J checks the signature on an incoming message, it records the QNames > of the elements which were signed. Typically, this will just be > [<soap:Body>]. Services are expected to check this results vector to ensure > that the body was signed, and to discover the identity of the signer. > The problem is that only the QName of the element is provided; if the message > contains multiple elements with the same QName, it is not possible to tell > whether the required elements were signed. For example, consider this genuine > message: > <env> > <head> > <wsa:To>Werner</wsa:To> > <sig ref='#1'>Signed Thomas</sig> > </head> > <body id='1'> > signed-and-encrypted-data > </body> > </env> > If an attacker gets hold of this message, they can trivially forge a new > message by moving the original body into the header (or anywhere else > out-of-the-way) and then creating a new unsigned body without an id: > <env> > <head> > <wsa:To>Werner</wsa:To> > <sig ref='#1'>Signed Thomas</sig> > <body id='1'> > signed-and-encrypted-data > </body> > </head> > <body> > <malicious-operation/> > </body> > </env> > When WSS4J checks the signature, it finds the body with id='1' and verifies > the signature. It then records that <body> was correctly signed by Thomas. > Axis then invokes the malicious operation in the real <body>. When the > service checks, it thinks that the malicious operation was signed by Thomas. > Note that simply ensuring a message has only one <body> element is not > sufficient, since often other elements also need to be signed (e.g., endpoint > reference types) and there may be many of these. > Solution (I will attach a patch shortly): > - Instead of recording QNames, record the wsu:Id values. > - Ensure that wsu:Id values are unique. > - In an additional axis handler, get the wsu:Id of the real <body> element > and find a signature with that Id. If multiple elements must be signed, find > a single signature over all of them. > WSS4J should probably default to checking that the real SOAP body is signed > and store its signer on the Axis message context, to provide a > secure-by-default configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
