Something I've noticed recently is that most of the websites I've been asked to assess now seem to be "new, improved, and with an API".  Often the API is based on SOAP, and it's been an interesting discussion on how best to scan these new Web Services based on WSDL for vulnerabilities.

The simple way is to run the developers test suite, usually coded up as a project file in SoapUI, through BURP.  However, what folks are finding is that the proxy function within SoapUI simply doesn't work, especially for HTTPS.  And the SoapUI solution to get around this is pretty convoluted.  The solutions that folks have generally come up with have also in some cases been complex, and most of them include the step "change the SoapUI test for this case from HTTPS to HTTP" (counting on BURP to flip it back to HTTPS).  (http://ardsec.blogspot.ca/2012/08/soapui-to-burp-fuzz-away.html and http://gerionsecurity.com/2013/03/soapui-with-burp/  for instance lay out two ways to take this path).

These solutions against the grain for me, mostly because I'm lazy.  If I need to update all of the test cases in an API, that's generally somewhere between 1-3 mods per API call, and when the developer comes out with the next version (as they are wont to do), I have to do all of that all over again.  And if I miss one, that'll be the one that would have given me SQL injection or something else equally good.

So how do I get around this?

Simple.  I use the "Invisible Proxy" feature within Burp (any other product would call this "transparent" instead of "invisible" proxy).  Let's do this step by step:

You'll need two hosts - I use two VMs. Mainly because my mantra is that you really need a good reason to rn anything physical.  Install SoapUI on one, and Burp on the other.  I'm going to assume that these are both Windows boxes, but this works just as well with Linux of course

1/ Out of the box, run all the tests within the SoapUI project, as received from the developers

2/ Now flip out to a command prompt and dump your DNS cache, so you know which hosts are being called in the API (they're not always the hosts you think they are).  In Windows, this is:

ipconfig /displaydns

or, since you just want the hostnames and IPs (in short, the actual DNS records), run:

ipconfig /displaydns | find "Record"

Many Linux hosts don't do DNS Caching, so you might need to run tcpdump and capture unique dns queries instead (or extract the DNS records used by the SOAP tests from your local DNS Server logs, but that's not as reliable)

3/  Next, on the SoapUI machine edit the local hosts file (c:\windows\system32\drivers\etc\hosts, or /etc/hosts) and add a host entry for each of the API targets.  Instead of the real IP of the target, use the IP of the Burp machine, so that the Test Suite is directed at Burp.

4/ Over to Burp to the Burp machine, fire up Burp, and enable Transparent Proxy.   Be sure to enable it for the address you are targeting as proxy, or enable it for everything.  Also be very sure that you enable it for each port in use.  I've noticed developers lately have started using not just tcp/80 and 443, but have started getting "cute" with the https ports, often using 4443, 8443, 8843 and so on.  That pcap file created in step 2 might come in really handy, or you can just look at the various tests in the Test Suite to get all of these ports.  You'll need a proxy set up for each tcp port in use.

For instance, setting up port 443 will look like:

     and   

When you are done, your proxy Options screen should look like this �?? �??Invisible�?� indicates a port that is proxying transparently (note that your screen will vary depending on ports in use)

5/ Back to your SoapUI machine, re-run your API tests - they'll all show nicely in the Burp Target pane!

6/ Still in Burp, everything is now set up to use Scanner, Repeater, Intruder or any of the other Burp functions.  For instance, in Burp Scanner, the SOAP services above ended up with the issues listed below:

And yes, SQL injection was verified and worked, so did XML injection!

Interestingly, there is a security tab in SoapUI, where you can do some basic security tests - mostly looking for basic SQL Injection and XML Injection.  I�??m still playing with this �?? so far I�??ve been running both, and Burp is coming out ahead.  However the SoapUI app is showing XSS vulnerabilties that Burp does not.  Look for a second story on this after I've had some time to work it through.

Of course, the tools will only get you so far.  Once you have a list of possible vulnerabilities, you still need to manually verify each one.  And also of course, once you have the API all mapped out, playing with it manually (or with Repeater / Attacker and so on in Burp) will often net you your best findings.

What will you typically see?  Developers are getting the idea that XSS and SQL injection are bad things, so in well run dev shops I'm seeing this easy stuff crop up less and less.  However, every time I look at an API, I find this good stuff all over again.  SQL injection in the API is just too much fun !  XML injection is also very common (of course) - you'll find that if you put this in your report as a finding, you'll have to add a page on what exactly that is, and how it impacts the security of the application, and in turn how it impacts the organization.

So, in short, APIs seem to be offering up the new �??low hanging fruit�?�.  If you've found something cool in a SOAP API, please let us know in our comment form.  Or better yet, if you've found some other way to simplify proxying SoapUI through Burp or otherwise evaluating SOAP interfaces, please also let us know!

SoapUI plus Burp - it's like chocolate, but with more chocolate!

===============
Rob VandenBrink
Metafore