The basic story with the config files is that the more info you add in to them the less questions you will be asked by the program. The following represents the options that each mode will read in:<br>

+

The basic story with the config files is that the more info you add in to them the less questions you will be asked by the program.

+

+

The following represents the options that each mode will read in:<br>

Mode 1 will read in:

Mode 1 will read in:

Revision as of 09:40, 3 July 2008

WSFuzzer is a LGPL'd program, written in Python, that currently targets Web Services. In the current version HTTP based SOAP services are the main target. This tool was created based on, and to automate, some real-world manual SOAP pen testing work. This tool is NOT meant to be a replacement for solid manual human analysis. Please view WSFuzzer as a tool to augment analysis performed by competent and knowledgable professionals. Web Services are not trivial in nature so expertise in this area is a must for proper pen testing.

Overview

WSFuzzer is a GPL'd program, written in Python, that currently targets Web Services. In the current version HTTP based SOAP services are the main target. This tool was created based on, and to automate, some real-world manual SOAP pen testing work. This tool is NOT meant to be a replacement for solid manual human analysis. Please view WSFuzzer as a tool to augment analysis performed by competent and knowledgable professionals. Web Services are not trivial in nature so expertise in this area is a must for proper pen testing.

Goals

‡ To automate some of the more intense SOAP fuzzing processes that would be quite time consuming if performed manually
‡ To do attack vector generation in a dynamic and intelligent fashion based on the specific target
‡ Providing its functionality/resulting data to other tools in a seamless fashion
‡ To facilitate the repeatable use of known successful attack vectors
‡ To be part of a solid web application pen testing toolkit
‡ To be as easy to use within the spectrum of understanding, and working with, SOAP services

It is not the goal of WSFuzzer to replace human analysis. AAMOF WSFuzzer does not currently do any analysis of the results gathered. The job of analysis is left to the analyst/engineer running a given pen test.

This tool is ultimately meant to augment a pen testers job in respect to SOAP services.

Install

Tar and Gzip are used in concert to create the wsfuzzer* "gzipped archives". Hence they have the .tar.gz extension. The install process is to simply extract the files from this tarball (archive). To extract the program one can obviously use the tar and gzip commands separately. But an easier way takes into account that tar's -z option feeds the archive gzip after unpacking, Thus:

tar -xvzf wsfuzzer*.tar.gz

extracts all files from the gzipped archive and places them into a directory that reflects the version number. For example:

cd /to/location/of/tarball
tar -xvzf wsfuzzer-1.9.3.tar.gz

extracts all files to a directory named:

version1.9.3

based on the location of the tarball. So if the tarball is in dir:

/opt/wsfuzzer

one would end up with:

/opt/wsfuzzer/version1.9.3/

Upon proper tarball extraction the install is complete. You can move on to running the program.

Features

‡ Pen tests an HTTP SOAP web service based on either valid WSDL, known good XML payload, or a valid endpoint & namespace.
‡ It can try to intelligently detect WSDL for a given target.
‡ Includes a simple TCP port scanner.
‡ WSFuzzer has the ability to Fuzz methods with multiple parameters. There are 2 modes of attack/fuzzing: "individual" and "simultaneous". Each parameter is either handled as a unique entity (individual mode), and can either be attacked or left alone, or multiple parameters are attacked simultaneously (hence the name - simultaneous mode) with a given data set.
‡ The fuzz generation (attack strings) consists of a combination of a dictionary file, some optional dynamic large injection patterns, and some optional method specific attacks including automated XXE and WSSE attack generation.
‡ The tool also provides the option of using some IDS Evasion techniques which makes for a powerful security infrastructure (IDS/IPS) testing experience.
‡ A time measurement of each round trip between request and response is now provided to potentially aid in results analysis.

-e endpoint -n namespace -- -e and -n are used together
-e is the web service endpoint -- i.e. WSDL URL
-n is the web service namespace -- i.e. URI
When using -e and -n you will have to manually establish the method to be attacked
Example: python WSFuzzer.py -e "http://host/service/service.asmx" -n "urn:querySOAP"

--xml --- A text file of the XML payload to be used against the target

-h host -- A URL of the target host. This option will do some digging into the target URL, it will scrape for anything WSDL or DISCO related and construct a list of verified WSDL URL's
Example: python WSFuzzer.py -h http://host

--conf --- A file containing some config data so as to automate some of the normally interactive parts of WSFuzzer

--bauser username --bapass password --- these 2 optional arguments are used together whenever HTTP Basic Auth needs to be used
--bauser is a Basic Auth username
--bapass is a Basic Auth password to be used with the "bauser" username

--keyfile keyfile --certfile certfile --- these 2 optional arguments are used together whenever client-side certs need to be used
--keyfile is the PEM formatted file that contains the respective private key to be used
--certfile is the PEM formatted file that contains the X.509 certificate to be used with the "keyfile"

Configuration File Examples

The basic story with the config files is that the more info you add in to them the less questions you will be asked by the program.

Upon completion of a run the current output is based on a directory the prog will create. That dir is created within the root dir where the program is installed and run from. By default the pattern for dir creation is based on the string FuzzingResults-N. N is dynamically calculated based on existing directories fitting the pattern. So if you run the prog from "/opt/WSFuzzer" for instance you will end up with something like:

In the HeaderData dir you will find files that hold a Request / Response pair for each of the attacks sent to the target. One file has one Request and one Response. In some cases there will be no response if the attack Request caused some sort of crash on the server (500 status response, etc). Each one of the links in the Http Info column will provide you a path into the respective file as per the rest of the data in that row.

In reference to the "Round Trip" values:

M = milliseconds
S = seconds

This is a snippet from a run using the Static XML option (--xml)

python2.4 WSFuzzer.py --xml xpath.xml

Running WSFuzzer 1.9, the latest version

Local "All_attack.txt" data matches that on neurofuzz.com

Local "dirs.txt" data matches that on neurofuzz.com

Local "filetypes.txt" data matches that on neurofuzz.com

If you would like to establish the directory name for the
results then type it in now (leave blank for the default): xmltest
Since you are using the static XML feature we need some data from you...

Host to attack (i.e. sec.neurofuzz.com): 192.168.1.207

URI to attack (i.e. /axis/EchoHeaders.jws): /WSDigger_WS/WSDigger_WS.asmx
Unless some serious masking/spoofing is in place, it seems you are targeting a .Net host so you will need to use a SOAPAction header ...

Would you like to enable automated fuzzing to augment what you have already chosen?
This option generates a lot of traffic, mostly with a bad attitude &->
Answer: n

Parameter: query
Would you like to fuzz this param: y
Fuzzing this param
adding parameter

Would you like to enable IDS evasion(y/n)?
Answer: n
Not using IDS evasion

Shall I begin Fuzzing(y/n)?
Answer: y

Commencing the fuzz ....
Starting to fuzz method (xpath)

Generated 4 parameter based Attack Strings ...

Fuzzing completed for method (xpath)

The following represents an example of the payload contained as the content of the xml file passed in via the --xml switch. In reference to the example above, the file xpath.xml has the following as its contents:

This option (--xml) is ideal for the use of WSFuzzer when targeting .Net services/hosts. In order to use this option successfully you need to know/have the following in reference to your target:

‡ A valid XML payload. All you need to do is use whatever method you'd like to generate a valid payload based on your target. As a pen tester this is usually no problem since you are working closely with the target's developers/engineers.
‡ Proper host data in the form of host.domain or an IP address, i.e. sec.neurofuzz.com or 192.168.1.207
‡ Proper resource data (URI), i.e. /WSDigger_WS/WSDigger_WS.asmx
‡ If you are targeting a .Net service you will also need to know the value for a valid SOAPAction HTTP header, this could be the name of the method or a FQDN - it totally depends on how the target services were built. For instance in the example above the SOAPAction value is: http://foundstone.com/Stringproc/xpath

Here is a snippet from a run utilizing individual mode and no IDS Evasion:

Known Limitations/Issues

‡ The SOAP/WSDL lib's this prog uses are known to have some issues consuming some WSDL's created within .NET infratsructures. It really depends on how the WSDL was generated but the WSDL consumption lib's choke on some of these .NET based sets of XML. This is entirely subjective because we have also seen it work successfully against many .NET targets. The --xml feature should help on this front.
‡ We have gotten reports from a few users stating that the automated fuzzing is causing client side memory errors. Admittedly the automated fuzzing generates a lot of data and is intense :-) But that is one of the MO's of attacks so this is not accidental. As of version 1.7 we have toned down these type of attacks a bit and it seems to be playing nicer. So keep us posted on these types of issues but remember that the point with some of these attack vectors is to break the rules and force anomalies in order to see how the server side target holds up. In other words dont write me complaining about the fact that the tool is generating and sending bad XML, yes that is one of the things this tool purposely does.
‡ There is no GUI - Not quite sure that is entirely a limitation.

Feedback and Participation

We hope you find the OWASP WSFuzzer Project useful. Please contribute to the Project by volunteering for one of the Tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP WSFuzzer Project mailing list or view the archives, please visit the subscription page.

WSFuzzer is intended to benefit all of us in this application security field. It is entirely open source and to keep this tool as a useful player in a pen testers toolkit the project can use help in the areas of: