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 10:52:00 UTC
[jira] Created: (WSS-33) Signature checking vulnerability
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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-33) Signature checking vulnerability
Posted by "Thomas Leonard (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (WSS-33) Signature checking vulnerability
Posted by "Thomas Leonard (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/WSS-33?page=all ]
Thomas Leonard updated WSS-33:
------------------------------
Attachment: sig-security.patch
[ This patch was previously sent privately on Mon, 23 Jan 2006 ]
Attached is a patch to fix this security problem. It changes the WSS4J API to return the set of signed wsu:Id values instead of the signed elements' QNames (I removed the old interface completely to force people to fix their programs).
Notes:
- It does not check that the Body is signed. It merely makes it possible for another handler to check this. Both client and service should check the signer of the Body (using the new ensureSignedTogether() method).
- For an RPC call, the client should normally also check that the reply is from the service it tried to contact (e.g., by comparing the Common Name from the certificate's subject with the host part of the Call's endpoint address).
- Possibly, we should default to enforcing this simple policy (the Body must always be signed), since it's what most people will require.
- This patch is against subversion revision 370794.
Legal issues:
The patch adds a NOTICE file and changes the copyright headers on the files I changed to "Copyright 2003-2006 The Apache Software Foundation, or their licensors, as appropriate". We copied this wording from Apache jackrabit, e.g.:
http://svn.apache.org/viewcvs.cgi/incubator/jackrabbit/trunk/jackrabbit/src/main/java/org/apache/jackrabbit/core/lock/XALock.java?view=markup
This was suggested to us by Davanum Srinivas:
http://issues.apache.org/jira/browse/ADDR-10
PS: If you commit this to subversion, please record that it came from "University of Southampton IT Innovation Centre" in the log message. 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-33) Signature checking vulnerability
Posted by "Thomas Leonard (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/WSS-33?page=all ]
Thomas Leonard updated WSS-33:
------------------------------
Attachment: sig-security.patch
[ This patch was previously sent privately on Mon, 23 Jan 2006 ]
Attached is a patch to fix this security problem. It changes the WSS4J API to return the set of signed wsu:Id values instead of the signed elements' QNames (I removed the old interface completely to force people to fix their programs).
Notes:
- It does not check that the Body is signed. It merely makes it possible for another handler to check this. Both client and service should check the signer of the Body (using the new ensureSignedTogether() method).
- For an RPC call, the client should normally also check that the reply is from the service it tried to contact (e.g., by comparing the Common Name from the certificate's subject with the host part of the Call's endpoint address).
- Possibly, we should default to enforcing this simple policy (the Body must always be signed), since it's what most people will require.
- This patch is against subversion revision 370794.
Legal issues:
The patch adds a NOTICE file and changes the copyright headers on the files I changed to "Copyright 2003-2006 The Apache Software Foundation, or their licensors, as appropriate". We copied this wording from Apache jackrabit, e.g.:
http://svn.apache.org/viewcvs.cgi/incubator/jackrabbit/trunk/jackrabbit/src/main/java/org/apache/jackrabbit/core/lock/XALock.java?view=markup
This was suggested to us by Davanum Srinivas:
http://issues.apache.org/jira/browse/ADDR-10
PS: If you commit this to subversion, please record that it came from "University of Southampton IT Innovation Centre" in the log message. 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-33) Signature checking vulnerability
Posted by "Thomas Leonard (JIRA)" <ji...@apache.org>.
[ 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-33) Signature checking vulnerability
Posted by "Thomas Leonard (JIRA)" <ji...@apache.org>.
[ 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
[jira] Resolved: (WSS-33) Signature checking vulnerability
Posted by "Werner Dittmann (JIRA)" <ji...@apache.org>.
[ 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Resolved: (WSS-33) Signature checking vulnerability
Posted by "Werner Dittmann (JIRA)" <ji...@apache.org>.
[ 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-33) Signature checking vulnerability
Posted by "Thomas Leonard (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/WSS-33?page=comments#action_12366617 ]
Thomas Leonard commented on WSS-33:
-----------------------------------
Here is an example showing how to use the new API from the client. Do this after using call.invoke(argValues):
MessageContext msgContext = call.getMessageContext();
SOAPBody body = (SOAPBody) msgContext.getResponseMessage().getSOAPBody();
Iterator results = ((Vector) msgContext.getProperty(WSHandlerConstants.RECV_RESULTS)).iterator();
X509Certificate serviceCert = WSSecurityUtil.ensureSignedTogether(results, new Element[] {body});
logger.debug("Response signed by " + serviceCert.getSubjectDN());
// check subject's CommonName matches endpoint...
> 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
[jira] Commented: (WSS-33) Signature checking vulnerability
Posted by "Thomas Leonard (JIRA)" <ji...@apache.org>.
[ 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-33) Signature checking vulnerability
Posted by "Thomas Leonard (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/WSS-33?page=comments#action_12366617 ]
Thomas Leonard commented on WSS-33:
-----------------------------------
Here is an example showing how to use the new API from the client. Do this after using call.invoke(argValues):
MessageContext msgContext = call.getMessageContext();
SOAPBody body = (SOAPBody) msgContext.getResponseMessage().getSOAPBody();
Iterator results = ((Vector) msgContext.getProperty(WSHandlerConstants.RECV_RESULTS)).iterator();
X509Certificate serviceCert = WSSecurityUtil.ensureSignedTogether(results, new Element[] {body});
logger.debug("Response signed by " + serviceCert.getSubjectDN());
// check subject's CommonName matches endpoint...
> 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