WSDL Wizard: Burp Suite Plugin for Detecting and Discovering WSDL Files

Introduction

WSDL (Web Service Description Language) files often provide a unique and clear insight into web application functionality. They can be made public and accessible by client-side users or private. From an attacker’s point of view public WSDL files make finding vulnerabilities easier, however even if the files are private, any vulnerabilities will still exist. From the perspective of a penetration tester, depending on what kind of test it is, it may or may not be appropriate to ask the client for WSDL files before the test.

So how do we find the WSDL files which are public? What if there are no direct links to find during spidering? The WSDL Wizard plugin! There have been tools in the past such as OWASP’s WSFuzzer which do an average job when they work. I wanted to write a Burp Suite extension in python which would make WSDL file detection and discovery not only easy to use but also efficient and safe in terms of scope.

This plugin searches the current Burp Suite site map of a user defined host for URLs with the ?wsdl extension while also building a list of viable URLs to fuzz for 'hiding' WSDL files. Two different methods are available to check for ?wsdl files, using urllib2 (default) or Burp's API. The fuzzing method depends on which function is called in the code so switching is easy. When comparing efficiency against large site maps, urllib2 was about 30 percent faster. All found WSDL files are added to the existing site map and printed out in the Extender tab output section.

After we have our WSDL files it’s time to make use of them. I did a previous post called Automatic Web Services Communication and Attacks which discusses using tools such as soapUI to inject into SOAP requests.

WSDL Wizard Use

WSDL Wizard runs off all of the requests and responses in Burp’s Site Map of a user selected host. Before running the plugin it is beneficial to have as much information in the site map as possible. This plugin should be used at the end of the information gathering stage when you have near complete coverage of the application.

To run this plugin three things are needed:

• Burp Suite Professional v1.5.01+
• Jython standalone JAR file
• WSDLWizard.py

In the Extender > Options tab, select the location of your Jython standalone file.

In the Extender > Extensions tab load WSDLWizard.py

Now we are ready to use the extension. A menu option of ‘Scan for WSDL Files’ will appear if the user right clicks in the message viewer, site map table, or proxy history. In the following case I am running the plugin on OWASP’s WebGoat vulnerable application. In the site map there is already a valid request and response for the WSDL file.

The output from the plugin reports on the host which was scanned, the full URL of the detected WSDL file, and how many other viable URLs it fuzzed with the ?wsdl extension. In this case the WSDL file was detected and 29 files were fuzzed but no more found because there is only one in this application.

Using a site map without a WSDL file in it really displays the main feature of this plugin. It will detect /WebGoat/services/WSDLScanning as being a candidate to fuzz with the ?wsdl extension.

After running the plugin the output reports 1 WSDL file was fuzzed and adds that request and response to the current site map.

Now we have all the WSDL files and the real fun begins! I have now shown how to detect WSDL files and even discover new ones you never knew were there.

I hope everyone likes it. This is my first Burp plugin so feedback would be very much appreciated. Any comments, suggestions, or errors please comment on my blog or email me at SmeegeSec@gmail.com

Read More

SQLMap Plugin for Burp Extender

SQLMap is a popular tool for automating SQL injection detection and exploitation. Burp is a multifaceted intercepting proxy which is great for testing web applications. Applications are often used by attackers in attempts to communicate with a back-end so finding and fixing these vulnerabilities is a necessity. Wouldn’t it be great if we could integrate SQLMap into Burp instead of creating and modifying different SQLMap commands every time we find a different page or parameter?

We’re in luck as there is a project by the name of Gason (blog: blog.buguroo.com), which is a SQLMap plugin for Burp. A few other people have done ‘how-to’ blog posts on this plugin but I haven’t seen any address some of the errors people have been reporting (mostly with Windows) or how to implement it with Burp’s new extensibility API, Burp Extender, which was released Dec 10, 2012. I’m going to be discussing how to properly install and run this plugin in a Windows environment.

Setup

To get started, we need the following:

• Burp Suite Pro (free edition does not have Extender implemented, but the referenced blog above covers how to load the plugin into the free version).
• Gason Plugin
• SQLMap

Burp Extender allows us to add a .jar plugin into Burp (also supports python and ruby with a few extra steps). Start up Burp and go to the Extender tab. Click ‘Add’.

The extension type is Java, and just point to where the .jar file is on your local system. Click ‘Next’. At this point you should see the message ‘The extension loaded successfully’. Click ‘Close’.

Here we can see what it looks like when the plugin has been successfully loaded into Extender:

Working Around a Plugin Error

Currently when trying to run the plugin, a java.io.IOException error occurs. I believe this is a problem with how the plugin is called in Windows (other people have reported similar issues).

Java.io.IOException: Cannt run program sqlmap.py: CreateProcess error=193 %1 is not a valid Win32 application.

To get it to work, I used py2exe to make a sqlmap executable which I point to in the plugin rather than the sqlmap.py file. You can download a 7zip compressed archive of the sqlmap executable here. This does require some Windows dll files:

USP10.DLL - C:\WINDOWS\system32\USP10.DLL
OLEAUT32.dll - C:\WINDOWS\system32\OLEAUT32.dll
USER32.dll - C:\WINDOWS\system32\USER32.dll
COMCTL32.DLL - C:\WINDOWS\system32\COMCTL32.DLL
SHELL32.DLL - C:\WINDOWS\system32\SHELL32.DLL
OLE32.dll - C:\WINDOWS\system32\OLE32.dll
WINMM.dll - C:\WINDOWS\system32\WINMM.dll
gdiplus.dll - gdiplus.dll
SHLWAPI.DLL - C:\WINDOWS\system32\SHLWAPI.DLL
ADVAPI32.DLL - C:\WINDOWS\system32\ADVAPI32.DLL
msvcrt.dll - C:\WINDOWS\system32\msvcrt.dll
WS2_32.dll - C:\WINDOWS\system32\WS2_32.dll
WINSPOOL.DRV - C:\WINDOWS\system32\WINSPOOL.DRV
GDI32.dll - C:\WINDOWS\system32\GDI32.dll
DNSAPI.DLL - C:\WINDOWS\system32\DNSAPI.DLL
KERNEL32.dll - C:\WINDOWS\system32\KERNEL32.dll
IMM32.DLL - C:\WINDOWS\system32\IMM32.DLL
MSIMG32.DLL - C:\WINDOWS\system32\MSIMG32.DLL
COMDLG32.DLL - C:\WINDOWS\system32\COMDLG32.DLL

Ready to Attack!

I will be using the vulnerable web application Mutillidae set up on my local network to show how this works.

Make sure your browser is pointing to burp, make a request where an injection vulnerability may exist. After you make the request you can either intercept it or locate it in your history. Right click inside the request and select the ‘send to sqlmap’ option.

A separate window with options for sqlmap will open. Locate the sqlmap.exe file and add that to the bin path. Fill out any other options you want, as you change the options the command will update. Click ‘Run’.

Target URL: http://192.168.80.134/mutillidae/index.php?page=user-info.php&username=test-user&password=password&user-info-php-submit-button=View+Account+Details
Cookie: showhints=0; PHPSESSID=re8o3orsq4kkto0mblr73bbvi2
Bin path: C:\Python27\dist\sqlmap.exe
Command: C:\Python27\dist\sqlmap.exe --cookie="showhints=0; PHPSESSID=re8o3orsq4kkto0mblr73bbvi2" --risk=3 --level=3 -v 2 -p username -u http://192.168.80.134:80/mutillidae/index.php?page=user-info.php&username=test-user&password=password&user-info-php-submit-button=View+Account+Details

After running, a new tab opens up with an interactive command prompt. The tabs allow for multiple commands to be run at once. At this point the output is normal SQLMap.

The result? Vulnerable!

From here we can run another more specific attack based on found information or look for other injection points. If you have any comments or suggestions let me know. Enjoy!

Read More

Automating Web Services Communication and Attacks

Web services "describes a standardized way of integrating Web-based applications using the XML, SOAP, Web Services Description Language (WSDL) and UDDI open standards over an Internet protocol backbone." The description of a web service can be found in a file which describes how the service can be called, expected parameters, and what it returns.

In this post I will be showing how to use Burp, WebScarab, and soapUI to communicate with and test a web service. Topics include:

• Create a valid SOAP request and receive a response
• Automate a process to request and receive data
• Fuzz and look for more common web vulnerabilities such as injection

As an example I will be using WebGoat which is a vulnerable application I set up locally.

Steps:

1. Find the WSDL file which will end in ?WSDL or ?wsdl. It will look like this:

2. Create a SOAP request of your desired operation (get person's name, credit card, etc.) using WebScarab or soapUI. I will show how to use either one.

Using soapUI:

• Create a new project, enter the soap request URL ending in ?wsdl
• 
• If authentication is required, enter credentials
• 
• Choose which operation you want to use in your soap request and save the entire request for later
• 

Using WebScarab:

• Click on the WebServices tab and load the WSDL URL. Enter credentials if prompted
• 
• Choose which operation to request and execute it
• 
• Click the Summary tab and open up (double click) your POST request
• 
• In the request section, click the Text tab and save the entire request for later
• 

3. Now that we have the request open up a web proxy which can automate attacks such as Burp or ZAP and intercept the ?wsdl request. Replace the GET with POST and paste EITHER request in the body area. If you get an error back you may need to modify the header. For example, if you get "no SOAPAction header!" add "SOAPAction: " in the header.

The final request looks like this:

POST /WebGoat/services/WSDLScanning?WSDL HTTP/1.1
Host: 192.168.80.134:8080
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.8) Gecko/20100101 Firefox/10.0.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
SOAPAction: 
DNT: 1
Proxy-Connection: keep-alive
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=
Content-Length: 591

<?xml version='1.0' encoding='UTF-8'?>
<wsns0:Envelope
  xmlns:wsns1='http://www.w3.org/2001/XMLSchema-instance'
  xmlns:xsd='http://www.w3.org/2001/XMLSchema'
  xmlns:wsns0='http://schemas.xmlsoap.org/soap/envelope/'
>

  <wsns0:Body
    wsns0:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'
  >
    <wsns2:getFirstName
          xmlns:wsns2='http://lessons.webgoat.owasp.org'
    >
      <id
        xsi:type='xsd:int'
              xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
      >?</id>
    </wsns2:getFirstName>
  </wsns0:Body>
</wsns0:Envelope>

4. Send this request to Burp Intruder

5. Find the item you are requesting and which parameter it takes. soapUI will put a question mark '?' where this is, while webscarab will have whatever value was originally entered to get the request. Mark this as the only payload position.

6. Choose your payload set based on the type of data you are requesting. In this example I am requesting a first name based on an ID I send, so I am using intruder to send numbers 1-200 to see if any of those IDs are valid and return a first name.

7. Look at the Intruder results and find any outliers which usually indicate a good response or at least something which will give more information to work off of. In this example we see 3 valid responses, so the IDs 101, 102, and 103 correlate to a specific database entry.

Now that we have successfully communicated the same thing can be done for other operations to collect as much data as possible.

The next step is to do some fuzzing to look for injection or other attack vectors. This example shows sql injection being performed.

Read More

Checking read and write access to an FTP server

Having an FTP server which others can access is a dangerous thing. Allowing others to have write access is even worse. In most situations, whether anonymous FTP is enabled or not, only a small number of people should actually be able to write to the server. If you want to check if you have read and write access to a particular server I came up with a simple way in Ubuntu 12.04. This is a simple task but I go into detail because I want to definitively find out what kind of access I have, therefore I will be attempting to create a 'test' directory in every directory and based on the results will know my access

I created an FTP server locally using VSFTPD (http://en.wikipedia.org/wiki/Vsftpd). Most of the servers will not be local, so I will use FTPFS (http://en.wikipedia.org/wiki/FTPFS) to mount it locally to make things easier to work with. To do this I installed CurlFtpFS with the command 'sudo apt-get install curlftpfs.' This is the listing of the ftp server before we try writing to it:

Assuming that the FTP server is somewhere else, first we'll mount the server locally:

curlftpfs x.x.x.x ~/local-mount-folder

x.x.x.x is the address of the FTP server, and ~/local-mount-folder is a folder YOU create on your local file system, this is where you will access the FTP server. If you get an ERROR such as "bad mount point : permission denied" try running the command as root.

At this point I can check permissions but what I really want to know is if I have write access in any directory. Additionally I have seen cases where an anonymous ftp server said I had write access everywhere but would deny any write attempts.

For loop to create directory 'created-test-dir' in every existing directory on the server:

cd ftpmount
for k in $(ls -R | grep / | cut -d ":" -f 1); do mkdir $k/created-test-dir; done;

This uses 'ls -R' which gives a recursive listing of all subdirectories and contents, and so on. You will probably see output similar to "mkdir: cannot create directory './ftpmount/created-test-dir': Operation not permitted." This is ok because we know it is attempting to write to the ftp server. With a large ftp server this may take a while but much better than manually checking permissions.

The final step is to check if/where your 'test' directory was created:

cd ftpmount
find . -name created-test-dir

This will find any directories we may have created and also give you a list of where you have write access!

This sort of thing can be very helpful during a penetration test.

Read More