You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by "Thomas Leonard (JIRA)" <ji...@apache.org> on 2006/02/16 11:18:01 UTC
[jira] Commented: (WSS-33) Signature checking vulnerability

    [ http://issues.apache.org/jira/browse/WSS-33?page=comments#action_12366614 ] 

Thomas Leonard commented on WSS-33:
-----------------------------------

Here is an example of how to use the new API. This is a slightly simplified version of the PEP Provider in GRIA (http://www.gria.org/). If the SOAP message contains a resourceID header then both it and the body must be covered by the same signature. Otherwise, just the body must be signed.

public void invoke(MessageContext msgContext) throws AxisFault {
	Message request = msgContext.getRequestMessage();

	SubjectDescription currentUser = null;
	String primaryContext = null;

	// Get the <resourceID> and <body> elements
	SOAPHeaderElement resourceElement = getResourceElement(msgContext.getRequestMessage());
	SOAPBody body = msgContext.getRequestMessage().getSOAPBody();

	// Check that they are signed
	if (resourceElement != null) {
		currentUser = ensureSignedTogether(msgContext, new Element[] {resourceElement, body});
		primaryContext = XMLUtils.getChildCharacterData(resourceElement);
	} else {
		currentUser = ensureSignedTogether(msgContext, new Element[] {body});
	}


> 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org