Signature checking vulnerability
--------------------------------
Key: WSS-33
URL: http://issues.apache.org/jira/browse/WSS-33
Project: WSS4J
Type: Bug
Reporter: Thomas Leonard
Assigned to: Davanum Srinivas
[ 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]
