ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colm O hEigeartaigh (Closed) (JIRA)" <>
Subject [jira] [Closed] (WSS-33) Signature checking vulnerability
Date Mon, 03 Oct 2011 09:04:36 GMT


Colm O hEigeartaigh closed WSS-33.

> Signature checking vulnerability
> --------------------------------
>                 Key: WSS-33
>                 URL:
>             Project: WSS4J
>          Issue 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
> 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, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message