SoapUI to Burp - Fuzz away

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.

Read More

ASMX Webservices - XSS

I tested a few public Web services recently. 1 of them had a front end so it was easier to visualize but that apart it was quite tough, specially as numerous methods were so complex that the developers had a tough time trying to answer some of my questions.

Now assuming that the application that consumes the web services is not in testing scope, all you have is the .asmx and the .wsdl. At times, these methods might be invokable from the browser itself, via the ASMX web interface like this. Other times invoking is restricted to the local machine alone, in which case you have to use a third party client like SoapUI or write your own using a library. I wrote mine using a library called Suds (Python). Obviously, writing the client is more work and if the arguments that need to be passed are complex, it can be quite tricky.

There are 2 ways to test for SQL Injection or XSS. In my case I could invoke the methods via the browser, so that made it easier and I could find a SQL injection.

a) You can code your custom client and fuzz through that.
b) You can simply write a very simple client, with Burp set as a proxy. You can then use Burp Intruder or its inbuilt scanner to fuzz the application.

I wasn't lucky with the XSS though. The content type of the response was text/xml. I saw a few attack vectors for XSS in xml but all of them involved closing the existing XML tag but for any of them..I'd have to break out of the existing structure. And < and > were getting encoded..to &lt and &gt. So unless I could do that, I couldn't see anything anywhere that would make this vulnerable to XSS.

And much like my Flash post earlier, the content type is text/xml. So unless I could find a way to get a browser to forcefully treat it as text/html, there wasn't going to be a way to do this.

A colleague said this - "...In terms of triggering XSS it will be harder unless you can convince the client to render it using an XSLT" coz that would convert the XML into HTML. But I wasn't sure how I'd go about this. And then I ran out of time :).

So here I am. You guys know of how this is possible?

Update: I posted to the list and had a few ideas here.

Read More

Testing a Flex application

So I have been testing quite a bit recently. A while back I ran into an application which had a Flex frontend. The Flex UI talked to a backend server which ran Flourine FX. This eventually talked to a .NET application - MSSQL Db combination. The Flex client used AMF 3.0 to talk to the server.

This whole thread by the way is just a sort of a rant on how I could NOT do things and all the things I failed at. It offers no solutions. It is however interesting if you want to know what to avoid. If that's okay..read on.

Now I knew that Burp had support for AMF for sure. And the application was browser based, so everything should have been normal. Testing for SQL Inj, XSS, Authorization bypass tend to take the most time in a test. Usually though, if you can reliably intercept and replay traffic, it is quite doable. I had no reason to think that this would be anywhere different; considering that Burp talked AMF.

a) Authorization Test

Now, this particular app had 2 types of users: user & manager. So I tried to replay a manager request as a user, but it kept failing. So I think..okay..protected. Then I took a menu which both users had access to. Replayed request. Fail. Huh? Both have access, why should it fail? Something very funny going on. Or maybe I have no clue (more likely :)). The last test I did was trap a user request and replay it as the same user, inside the same session, inside the same TAB. Surely this should work?? FAIL. Huh?

Now I'm confused. This means that something is happening ON the client itself. Sent 2 user requests to Burp Comparer. Turns out there are 3 values that change with every request. They are: ClientID, MessageID(under body) and DSId (under body and then headers). Now the ClientID and DSId didn't seem like they were too important, as in, tampering with those didn't give me an invalid request. However anytime I touched the MessageID, I was rebuffed.

So drilling down further MessageID seems to be of the structure of a 32 bit Guid. Spoofing an older valid message ID or a newer message ID or a pre-generated but not sent (Dropped request) message ID all fail. There is nothing that comes back in the response either; like an Anti CSRF token in a hidden field. So I am sure it is nothing that is stored on the server. If it isn't though, how does it recognize just THAT ONE message ID? And no... it does not seem to be all client side either. This is because I could see AMF requests being sent; dropping them also caused an error.

b) SQL Injection and XSS

At this point I hit a limitation with Burp. In a normal request (non AMF) you can add, modify and delete parameters. Right? So in AMF, while I can still modify data in individual parameters, I cannot add or delete anything through Burp.

This probably has something to do with the structure of the request. I tried Charles too, but have the same problem. Now I can sit and manually put a single quote and < > in every parameter but I'd probably die before I complete the test. Meaning...I cannot fuzz every parameter reliably using Burp. That's cause although there is repeater and intruder support to parse AMF, it doesn't detect the exact places properly...so I can choose which parameters to fuzz.

The closest I came was to carefully look at the 'Raw' request which tended to be just 1 value and fuzz just that. I got a few errors here but nothing concrete from a SQL Inj perspective. Ditto XSS. I tried deblaze, Pinta and a ton of tools which are already out there on the OWASP Flash page. None worked. It almost certainly meant I'd have to write my own client specially for FlourineFX. A custom BlazeDS client written by a colleague also failed. On this particular engagement I ran out of time.

The last thing I wanted to talk about was that the Response content type was x-amf. So all the Stack overflow and Google threads I read, talked about how this was real hard to do. I bounced this off a few guys and everyone did say...If there is no HTML content type responses...you can't get JS to execute. Which made sense.

c) CSRF

The fact that the message ID was 'unspoofable' automatically gave this Flex app protection against CSRF. No token. No nothing.

So in a nutshell, its super hard to test for SQL, XSS, CSRF and Replay traffic with existing tools. Almost certainly a custom FlourineFX client has got to be written. How and when and by whom I don't know. Maybe I'll write one some day :)

You guys have any ideas on how anything could have been done better? I saw a talk on BlackHat12 which talked about this. I'll check that out. That apart..anything?

Read More

Free Mobile Doctor

Free period extension for Mobile Doctor

Dear Doctors,

For all you, who bought (or Buy) our AppStore Application 'Mobile Doctor'  until 30 June 2012,

we offer you for FREE the new version of the Mobile Doctor (a 459 euros gift )
www.vergdo.com

Please send us the receipt of your buy and we will send you the FULL APPLICATION WITHOUT ANY CHARGE.

Also we found a negative review of the mobile Doctor. 

Please contact us to resolve your problems or satisfy your requests. Our goal is Zero dissatisfied customers.

Read More

New Mobile Doctor for Free

Dear Doctors,
For all you, who bought (or Buy) our AppStore Application 'Mobile Doctor'  until 30 May 2012,

we offer you for FREE the new version of the Mobile Doctor.

Please send us the receipt of your buy and we will send you the FULL APPLICATION WITHOUT ANY CHARGE.

Also we found 3 negative reviews of the mobile Doctor out of more than 150 unit sold. Please contact us to resolve your problems or satisfy your requests. Our goal is Zero dissatisfied customers.

Vergas Dimitris

dvergas@advent.com.gr

Read More

Reverse Engineering - Android APK

There's nothing really complex about this post. In the past I've always maintained that reversing is kind of tough; and that's true if its an EXE,DLL etc. But in the case of an Android application; it really is very easy.

While all this information is already there, here is a very short blog post summarizing how you get from APK to Source. I used a Vuln app available here; but you can use anything really. Here goes:

1. Extract the APK to a folder. Its just a Zip file so any archiving program should do; I use the inbuilt Ubuntu GUI archiving tool.

2. Rename the folder to something like original_helloworld. That's because we will play around with all the files inside  and it might be nice to have an original copy somewhere to look at when needed.

3. Look at the file AndroidManifest.xml. It'll open in a Text editor but its largely binary; hence unreadable. Use Apktool to decode this XML file as well as every other XML file in the APK. You can get it from http://code.google.com/p/android-apktool/. Download the main apktool package (contains a JAR) and the platform specific one as well (contains the apktool binary). Run apktool . It'll run and give you all the XML files totally decoded; so you can now read them.

4. You now want to recover code. All code is in classes.dex. Think of Dex as Android Byte code which is reversible to Java Byte Code....which eventually is reversible
to Java code. So we first 'dedex'. You can either use the output of apktool above; which after running gives you its output in a folder called 'smali'. A slightly more
 'easy to read' format is given by dedexer though (less spaces; cleaner output) available at http://dedexer.sourceforge.net. You use it as follows to 'dedex' classes.d
ex - java -jar ddx1.22.jar -d /opt/Android/vulnapps/Tmp_test_apps/InsecureBankDeDexed /opt/Android/vulnapps/Tmp_test_apps/InsecureBank.apk_FILES/classes.dex. Look inside InsecureBankDeDexed for the output. So in a nutshell, after we DeDex we get Android Byte code.

5. Once you have Android byte code; since Android code 'looks' very much like Java, you can convert Android byte code to Java byte code. Use dex2jar downloaded from
http://code.google.com/p/dex2jar/ and run it as follows ./dex2jar.sh ../../vulnapps/Tmp_test_apps/InsecureBank.apk. This results in a JAR file getting created in the d
irectory where the APK is already present. The JAR file contains all the JAVA class files; namely the Java byte code - something that you get once you compile your Jav
a code.

6. The last step is to convert your Java byte code into actual Java code. You need something called a Java decompiler for this. You can download one called the Jd-Gui from here - http://java.decompiler.free.fr/?q=jdgui. Once its downloaded, unzip the JAR and store all its class files in a single folder like JavaClassFiles. Launch JD-GUI and select 1 class file. Save the source. Repeat for each class file [Painful I know :(]. You now have all the source code and can do some static analysis on the code :). There's probably some cooler way to decompile all the class files in a folder; but I won't dig too deep into that just now.

Largely this presentation was where I got almost everything from. Will write more when I do some static analysis.

Read More

Market app - Android 2.2

Was doing a test on an Android app (first ever ;)) and was trying to install an app which was available on Android market. As it turns out, the emulator doesn't have the app pre-installed. So I followed instructions here. That largely works except that despite following everything the app vanishes the next time around. So after more digging I came up on this thread which provided the missing piece. I'll sum it up quickly.

--- You need to edit files on the emulator which will prevent the emulator from checking if its a valid phone or not
--- You need to upload the packages for the Market app and the GoogleServicesFramework as those are not shipped
--- You can do both of the above only if you have WRITE access to the emulator's system directory.

So far everything is covered by Varun's blog. The 1 point which he hasn't made clear is that once you've pushed all your changes to build.prop, uploaded the 2 apps mentioned above and deleted SdkSetup.apk you have to sync your changes and save the temp image in which all these changes are made.

Think of it in this way..all the changes you make are temporary and made in a file /tmp/android-. The filename starts with emulator. Once you're done making your changes save this file somewhere. Shut the emulator down. Now rename the saved file to system.img and copy it into ~/.android/avd/.avd. Now boot the emulator. It should work.

I've said nothing new frankly. If you use Varun's post and the post on the XDA forums together, you will be able to do this. However I was stuck for quite a while here, so thought a few guys would benefit by me linking the two together :)

Read More