[ http://issues.apache.org/jira/browse/WSS-33?page=all ]
Werner Dittmann resolved WSS-33:
--------------------------------
Resolution: Fixed
This fix helps to close a security vulnerability. See additional comments for
example
code for WSS-33.
Patch submitted from "University of Southampton IT Innovation Centre"
> 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]
