Direkt zum Hauptbereich

Introduction to WS-Attacker: XML Signature Wrapping (XSW) on Web services

This post introduces WS-Attacker. We start with how to build it from source. After that we setup an example Axis2 Web service and finally we perform an XSW Attack on it.

Building WS-Attacker from Source

WS-Attacker has recently moved its sources from Sourceforge to Github. Thus, we download its source code using the following command:
% git clone https://github.com/RUB-NDS/WS-Attacker.git
Cloning into 'WS-Attacker'...
remote: Counting objects: 2984, done.
remote: Total 2984 (delta 0), reused 0 (delta 0), pack-reused 2984
Receiving objects: 100% (2984/2984), 90.40 MiB | 2.91 MiB/s, done.
Resolving deltas: 100% (1386/1386), done.
Checking connectivity... done.
% cd WS-Attacker

This clones the whole WS-Attacker repository from Github to our local storage. Next, we need maven and at least openjdk7 to build the tool (note that we use -DskipTests to increase the build speed):
% mvn clean package  -DskipTests
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO] WS-Attacker
[INFO] WS-Attacker-Libraries
[INFO] SoapHttpClient
[INFO] WS-Attacker-Framework
[INFO] WS-Attacker-Plugins
[INFO] WS-Attacker-Plugin_SoapAction_Spoofing
[INFO] WS-Attacker-Plugin_WS_Addressing_Spoofing
[INFO] WS-Attacker-Plugin_Options_Tester
[INFO] WS-Attacker-Library_XML_Utilities
[INFO] WS-Attacker-Library_Schema_Analyzer
[INFO] WS-Attacker-Library_Signature_Wrapping
[INFO] WS-Attacker-Plugin_Signature_Wrapping
[INFO] WS-Attacker-Plugin_Denial_of_Service
[INFO] WS-Attacker-Library_Signature_Faking
[INFO] ------------------------------------------------------------------------
[INFO] Building WS-Attacker 1.4-SNAPSHOT
[INFO] ------------------------------------------------------------------------

Depending on your PC's power and your Internet connection's speed, this may take a while. You can find the runnable JAR and all the attack plugins in the directory “runnable” afterwards.

Creating a sample Web Service that uses XML Signatures

% wget http://archive.apache.org/dist/axis/axis2/java/core/1.6.0/axis2-1.6.0-bin.zip
--2015-04-02 13:40:54--  http://archive.apache.org/dist/axis/axis2/java/core/1.6.0/axis2-1.6.0-bin.zip
Resolving archive.apache.org (archive.apache.org)...,, 2001:610:1:80bc:192:87:106:229
Connecting to archive.apache.org (archive.apache.org)||:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 20389041 (19M) [application/zip]
Saving to: 'axis2-1.6.0-bin.zip'

axis2-1.6.0-bin.zip                        100%[==========================================================================================>]  19.44M  5.40MB/s   in 4.3s

2015-04-02 13:40:59 (4.51 MB/s) - 'axis2-1.6.0-bin.zip' saved [20389041/20389041]
% unzip axis2-1.6.0-bin.zip

Next, we need to install rampart, the security module for axis2 which enable XML Signature processing:
% wget http://archive.apache.org/dist/axis/axis2/java/rampart/1.6.0/rampart-dist-1.6.0-bin.zip                                                      :(
--2015-04-02 13:43:53--  http://archive.apache.org/dist/axis/axis2/java/rampart/1.6.0/rampart-dist-1.6.0-bin.zip
Resolving archive.apache.org (archive.apache.org)...,, 2001:610:1:80bc:192:87:106:229
Connecting to archive.apache.org (archive.apache.org)||:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6905111 (6.6M) [application/zip]
Saving to: 'rampart-dist-1.6.0-bin.zip'

rampart-dist-1.6.0-bin.zip                 100%[==========================================================================================>]   6.58M  2.25MB/s   in 2.9s

2015-04-02 13:43:56 (2.25 MB/s) - 'rampart-dist-1.6.0-bin.zip' saved [6905111/6905111]

% unzip rampart-dist-1.6.0-bin.zip

We then need to “install” rampart in the axis2 directory as follows:
% cp rampart-1.6.0/lib/* axis2-1.6.0/lib
% cp rampart-1.6.0/modules/* axis2-1.6.0/repository/modules

We will now start a rampart sample that uses XML Signatures:
% cd  rampart-1.6.0/samples/policy/
% AXIS2_HOME="/tmp/axis2-1.6.0" ant service.02   

To start the service, we use ant and configure the Axis2 Home directory.

Obtaining the signed Message

To use WS-Attacker, we need to obtain a signed message. There are many approaches to achieve this. In this scenario, we start “Wireshark” and run the client sample script (from a second terminal):
% AXIS2_HOME="/tmp/axis2-1.6.0" ant client.02

<?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1"><wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Timestamp-1"><wsu:Created>2015-04-02T12:36:45.699Z</wsu:Created><wsu:Expires>2015-04-02T12:41:45.699Z</wsu:Expires></wsu:Timestamp><wsse:BinarySecurityToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="CertId-FFCBEBA22B6965E99814279782058481">MIICTzCCAbigAwIBAgIESy9O5zANBgkqhkiG9w0BAQUFADBsMQswCQYDVQQGEwJMSzEQMA4GA1UECBMHV2VzdGVybjEQMA4GA1UEBxMHQ29sb21ibzEPMA0GA1UEChMGQXBhY2hlMRAwDgYDVQQLEwdSYW1wYXJ0MRYwFAYDVQQDEw1TYW1wbGUgQ2xpZW50MB4XDTA5MTIyMTEwMzMxMVoXDTM3MDUwNzEwMzMxMVowbDELMAkGA1UEBhMCTEsxEDAOBgNVBAgTB1dlc3Rlcm4xEDAOBgNVBAcTB0NvbG9tYm8xDzANBgNVBAoTBkFwYWNoZTEQMA4GA1UECxMHUmFtcGFydDEWMBQGA1UEAxMNU2FtcGxlIENsaWVudDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAjBQM+kgC0Wm9hk9v4pjLSg5yK0Em2ulyDmODckWv4mZJ8YwJPVgqEIzwRiOnNBH3s+wFCw297zDsnEgDKSQrsPf1smVUOK/slyDPbqZ47Ewcs07nCPfNigncmpbcaluO3bMw9Oqj9VIYjrUHu5xCp2Fe39ZPbwOzLtAmT8b6iucCAwEAATANBgkqhkiG9w0BAQUFAAOBgQAnjPanrVjFVkxnhsj83RJA2tK//v99KpPf3do9VUI2yEgvBZUzH3q2jk3widwEcsJMHgbRr3VTFL7dNVdCYBcI1KiBY9SMa1XZ4RIHmw7gkJt1JTgjKBzfrout2z614KixRf4w7qkDacGxkNspXG/PSlh03Lfm5sb0vzH1aqBl3g==</wsse:BinarySecurityToken><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-2">
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#Id-1699113578">
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:Reference URI="#Timestamp-1">
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:KeyInfo Id="KeyId-FFCBEBA22B6965E99814279782058532">
<wsse:SecurityTokenReference xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="STRId-FFCBEBA22B6965E99814279782058543"><wsse:Reference URI="#CertId-FFCBEBA22B6965E99814279782058481" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" /></wsse:SecurityTokenReference>
</ds:Signature></wsse:Security><wsa:To>http://localhost:8080/axis2/services/sample02</wsa:To><wsa:MessageID>urn:uuid:4732fd77-3d09-4639-ba44-41618c2c4a4a</wsa:MessageID><wsa:Action>urn:echo</wsa:Action></soapenv:Header><soapenv:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Id-1699113578"><ns1:echo xmlns:ns1="http://sample02.policy.samples.rampart.apache.org"><ns1:param0>Hello world</ns1:param0></ns1:echo></soapenv:Body></soapenv:Envelope>

Using WS-Attacker

We use again the second terminal to start WS-Attacker:
% cd /tmp/WS-Attacker/runnable  
% java -jar WS-Attacker-1.4-SNAPSHOT.jar

We use the WSDL URL http://localhost:8080/axis2/services/sample02?wsdl and feed it into WS-Attacker:

We switch to the “Test Request” Tab and replace the XML Request with the one that we obtained in the previous section:

After sending the test request, a SOAP error message is received. Do not bother with it. We will use XSW to renew the timestamp. To go for it, move to the plugin configuration tab.

All we have to do in the plugin configuration tab, is to select and activate the Signature Wrapping Attack from the tree on the left. We can then configure the payload. Payload is the XML content that is going to be executed instead of the originally signed content. In this case, the XML message has to signed elements: The Body Element and the Timestamp element. For the first one, we just change the “Hello World” message to “Hello WS-ATTACKER”. For the Timestamp, WS-Attacker automatically detected that this is a timestamp element. It will update it automatically (see lower highlighting in the screenshot).
A common issue with the XSW Plugin is, that it will not go into the “Ready” state. This happens, when you have not configured any payload.
Next, we move to the “Attack Overview” tab and start the attack.

As we can see, Axis2 could be successfully attacked. We can also see the attack vector that was used.
More details can be obtained by right-clicking on the Signature Wrapping Plugin in the upper table and selecting “Analyze XSW responses”.

Beliebte Posts aus diesem Blog

CORS misconfigurations on a large scale

Inspired by James Kettle's great OWASP AppSec Europe talk on CORS misconfigurations, we decided to fiddle around with CORS security issues a bit. We were curious how many websites out there are actually vulnerable because of dynamically generated or misconfigured CORS headers. The issue: CORS misconfiguration Cross-Origin Resource Sharing (CORS) is a technique to punch holes into the Same-Origin Policy (SOP) – on purpose. It enables web servers to explicitly allow cross-site access to a certain resource by returning an Access-Control-Allow-Origin (ACAO) header. Sometimes, the value is even dynamically generated based on user-input such as the Origin header send by the browser. If misconfigured, an unintended website can access the resource. Furthermore, if the Access-Control-Allow-Credentials (ACAC) server header is set, an attacker can potentially leak sensitive information from a logged in user – which is almost as bad as XSS on the actual website. Below is a list of CORS misc…

Printer Security

Printers belong arguably to the most common devices we use. They are available in every household, office, company, governmental, medical, or education institution.
From a security point of view, these machines are quite interesting since they are located in internal networks and have direct access to sensitive information like confidential reports, contracts or patient recipes.

TL;DR: In this blog post we give an overview of attack scenarios based on network printers, and show the possibilities of an attacker who has access to a vulnerable printer. We present our evaluation of 20 different printer models and show that each of these is vulnerable to multiple attacks. We release an open-source tool that supported our analysis: PRinter Exploitation Toolkit (PRET) https://github.com/RUB-NDS/PRET Full results are available in the master thesis of Jens Müller and our paper. Furthermore, we have set up a wiki (http://hacking-printers.net/) to share knowledge on printer (in)security.
The hi…