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

How To Spoof PDF Signatures

One year ago, we received a contract as a PDF file. It was digitally signed. We looked at the document - ignoring the "certificate is not trusted" warning shown by the viewer - and asked ourselfs:

"How do PDF signatures exactly work?"

We are quite familiar with the security of message formats like XML and JSON. But nobody had an idea, how PDFs really work. So we started our research journey.

Today, we are happy to announce our results. In this blog post, we give an overview how PDF signatures work and on top, we reveal three novel attack classes for spoofing a digitally signed PDF document. We present our evaluation of 22 different PDF viewers and show 21 of them to be vulnerable. We additionally evaluated 8 online validation services and found 6 to be vulnerable.

In cooperation with the BSI-CERT, we contacted all vendors, provided proof-of-concept exploits, and helped them to fix the issues and three generic CVEs for each attack class were issued: CVE-2018-16042

DTD Cheat Sheet

When evaluating the security of XML based services, one should always consider DTD based attack vectors, such as XML External Entities (XXE) as,for example, our previous post XXE in SAML Interfaces demonstrates.

In this post we provide a comprehensive list of different DTD attacks.

The attacks are categorized as follows:
Denial-of-Service AttacksClassic XXEAdvanced XXEServer-Side Requst Forgery (SSRF)XIncludeXSLT

Practical Dictionary Attack on IPsec IKE

We found out that in contrast to public knowledge, the Pre-Shared Key (PSK) authentication method in main mode of IKEv1 is susceptible to offline dictionary attacks. This requires only a single active Man-in-the-Middle attack. Thus, if low entropy passwords are used as PSKs, this can easily be broken.