I was recently testing another web service (lot of them recently) and was using SoapUI as a client to invoked the WSDL. You don't HAVE to use SoapUI; its just that it was the most popular tool out there and seemed to do its job.
So one of the main tests in a web service is to fuzz all the methods. For the new guys it just means the following:
a) Identify the method and find out what arguments it has
b) Find out what valid arguments need to be passed for the method to work
c) Fill each argument with a huge bunch of malicious data specific to SQL Inj or XSS or any other type of injection and see how the server reacts
Now you could do this manually and put in a ' , < , > , #, OR 1=1 and so on manually and see what responses you get back. That, I guarantee you is not going to be too much of fun after around 10 minutes max :). So you want to automate this process.
SoapUI has its own security scan from version 4.0 onwards and this is what a large number of people working with web services tend to use. I'm not sure what I was doing wrong, but the free version allowed me to scan just 4 specific parameters [username, password, request and one more]. It has a huge number of scans; SoapUI but if it is not going to allow to me to fuzz the parameters I want, it kinda is useless. Maybe its because I was using the free version and the Pro version supports scanning all parameters. Anyone tried that out? If not, no worries, I will ..sometime :)
So now I thought of chaining SoapUI to Burp and using Burp to do all my fuzzing instead. This turned out to be harder than I thought and frustratingly very little good help on how to do it. Note that it was a HTTPS connection; if its HTTP it is easy enough. SoapUI seems to have something called a HTTP Tunnel which I guess you have to configure with keystores and trust stores...but whatever I did I couldn't get it to work. And I couldn't find any other fuzzers which would reliably work. I am sure there might well be something...I was on a deadline though; you know how that goes.
So I pinged a few of my colleagues for help and Max helpfully suggested that I use stunnel to make the SSL connection to the server instead. That actually worked and I could get everything working. Here is what I did and why it worked.
a) Set SoapUI proxy settings to Burp - File: Preferences: Proxy Settings. Now load up any 1 request in the SoapUI request editor and edit its Endpoint to point to http://abcbank.com:443/blah/blah instead of https://abcbank.com:443/blah/blah. So it means...if you want a response for this method go to http://abcbank.com:443. This is just to ensure that the request gets to Burp...in the first place. If you keep the endpoint as https it gives you a 'Cannot cast to HTTP' error. I think that is because the proxy setting in SoapUI is ONLY for http.
b) Start Burp
c) Open Terminal (Ubuntu) ..probably CMD on Windows although untested and start stunnel as follows: sudo stunnel -cf -d 127.0.0.1:443 -r www.abcbank.com:443
d) Go to Burp - Options - Hostname resolution. This is the one to the left of the Alerts tab and set the hostname of the remote site to 127.0.0.1. So you should have an entry in there which is Enabled and says:
www.abcbank.com 127.0.0.1
e) Load the WSDL up in SoapUI and invoke any method. Look into Burp; you should see a request in its history. Look into stunnel; you should see some data getting written to its console [Service stunnel3 accepted connection from 127.0.0.1:50318]. Yay. Done :).
f) The request is now in Burp. Uncheck the Enabled box in the Hostname Options in Burp. Now have fun with Burp Intruder/Scanner as usual.
For the curious..what exactly happened and why did this work? Well to start off, we simply set a proxy for SoapUI, so anything from SoapUI will go to Burp. Now Burp, like any other proxy needs to forward a request it got to the destination, else it'd be useless rt? ;)
Now just like your browser resolves a hostname to try and open up a site for you, Burp needs to do that as well...but it first looks into its hostname section to see if you've hard coded something there. You have..in this case.. www.abcbank.com = 127.0.0.1. So the SoapUI request goes to 127.0.0.1.
What's the destination port when you sent it from SoapUI? 443. And we haven't changed that in Burp. Its just a different hostname..that's all. So the traffic gets sent to 127.0.0.1:443.
And what's listening on 127.0.0.1:443? Stunnel of course. And Stunnel has been configured with the -r argument to forward all its traffic to abcbank.com:443.. So stunnel, since it understands SSL..completes the HTTPS connection with abcbank.com and returns the response to Stunnel - Burp and then SoapUI as well. Very very neat :)
Oh and once you have all of SoapUI's requests in Burp, you don't need to use SoapUI any more; you can just use the awesome Burp. You also do not need Stunnel anymore..as Burp can understand HTTPS by itself. The reason we needed Stunnel was because SoapUI did not seem to directly understand SSL. I am NOT stating this as fact..because I'm not sure; but certainly, from what I searched and worked with, it isn't that easy.
I hope that helps anyone who is trying to get this setup. Again big thanks to Max, Google ;) and this post.
So one of the main tests in a web service is to fuzz all the methods. For the new guys it just means the following:
a) Identify the method and find out what arguments it has
b) Find out what valid arguments need to be passed for the method to work
c) Fill each argument with a huge bunch of malicious data specific to SQL Inj or XSS or any other type of injection and see how the server reacts
Now you could do this manually and put in a ' , < , > , #, OR 1=1 and so on manually and see what responses you get back. That, I guarantee you is not going to be too much of fun after around 10 minutes max :). So you want to automate this process.
SoapUI has its own security scan from version 4.0 onwards and this is what a large number of people working with web services tend to use. I'm not sure what I was doing wrong, but the free version allowed me to scan just 4 specific parameters [username, password, request and one more]. It has a huge number of scans; SoapUI but if it is not going to allow to me to fuzz the parameters I want, it kinda is useless. Maybe its because I was using the free version and the Pro version supports scanning all parameters. Anyone tried that out? If not, no worries, I will ..sometime :)
So now I thought of chaining SoapUI to Burp and using Burp to do all my fuzzing instead. This turned out to be harder than I thought and frustratingly very little good help on how to do it. Note that it was a HTTPS connection; if its HTTP it is easy enough. SoapUI seems to have something called a HTTP Tunnel which I guess you have to configure with keystores and trust stores...but whatever I did I couldn't get it to work. And I couldn't find any other fuzzers which would reliably work. I am sure there might well be something...I was on a deadline though; you know how that goes.
So I pinged a few of my colleagues for help and Max helpfully suggested that I use stunnel to make the SSL connection to the server instead. That actually worked and I could get everything working. Here is what I did and why it worked.
a) Set SoapUI proxy settings to Burp - File: Preferences: Proxy Settings. Now load up any 1 request in the SoapUI request editor and edit its Endpoint to point to http://abcbank.com:443/blah/blah instead of https://abcbank.com:443/blah/blah. So it means...if you want a response for this method go to http://abcbank.com:443. This is just to ensure that the request gets to Burp...in the first place. If you keep the endpoint as https it gives you a 'Cannot cast to HTTP' error. I think that is because the proxy setting in SoapUI is ONLY for http.
b) Start Burp
c) Open Terminal (Ubuntu) ..probably CMD on Windows although untested and start stunnel as follows: sudo stunnel -cf -d 127.0.0.1:443 -r www.abcbank.com:443
d) Go to Burp - Options - Hostname resolution. This is the one to the left of the Alerts tab and set the hostname of the remote site to 127.0.0.1. So you should have an entry in there which is Enabled and says:
www.abcbank.com 127.0.0.1
e) Load the WSDL up in SoapUI and invoke any method. Look into Burp; you should see a request in its history. Look into stunnel; you should see some data getting written to its console [Service stunnel3 accepted connection from 127.0.0.1:50318]. Yay. Done :).
f) The request is now in Burp. Uncheck the Enabled box in the Hostname Options in Burp. Now have fun with Burp Intruder/Scanner as usual.
For the curious..what exactly happened and why did this work? Well to start off, we simply set a proxy for SoapUI, so anything from SoapUI will go to Burp. Now Burp, like any other proxy needs to forward a request it got to the destination, else it'd be useless rt? ;)
Now just like your browser resolves a hostname to try and open up a site for you, Burp needs to do that as well...but it first looks into its hostname section to see if you've hard coded something there. You have..in this case.. www.abcbank.com = 127.0.0.1. So the SoapUI request goes to 127.0.0.1.
What's the destination port when you sent it from SoapUI? 443. And we haven't changed that in Burp. Its just a different hostname..that's all. So the traffic gets sent to 127.0.0.1:443.
And what's listening on 127.0.0.1:443? Stunnel of course. And Stunnel has been configured with the -r argument to forward all its traffic to abcbank.com:443.. So stunnel, since it understands SSL..completes the HTTPS connection with abcbank.com and returns the response to Stunnel - Burp and then SoapUI as well. Very very neat :)
Oh and once you have all of SoapUI's requests in Burp, you don't need to use SoapUI any more; you can just use the awesome Burp. You also do not need Stunnel anymore..as Burp can understand HTTPS by itself. The reason we needed Stunnel was because SoapUI did not seem to directly understand SSL. I am NOT stating this as fact..because I'm not sure; but certainly, from what I searched and worked with, it isn't that easy.
I hope that helps anyone who is trying to get this setup. Again big thanks to Max, Google ;) and this post.
0 comments:
Post a Comment