Tuesday, March 4, 2014

Today we will be looking at tampering with parameters using a proxy. This is a fairly common thing to do in web application assessments and most mobile application testing is an extension of that so we'll examine how to proxy DroidGoat's traffic through Burp.

Updating Burp Suite in MobiSec

MobiSec, unfortunately, does not come with the most up-to-date version of Burp Suite, 1.4. Currently 1.5 is offered so we'll just update to that. First we go to http://portswigger.net/ and download it to /opt/mobisec/pentest/burp and then we will edit the script that launches Burp which is located in /opt/mobisec/burp.sh and update the call to the jar.

Sure, we could just run the updated Burp Suite jar manually, but now when we run Burp Suite from the menu it'll run our updated version.

Proxy Our Android Traffic

Next, we'll configure our Android Virtual Device (AVD) so that it'll pass traffic through Burp Suite. GoatDroid gives up the ability to configure a proxy through the application itself, but we'll do it this way because it's a more generic approach that will allow us to proxy traffic when we're testing any other application. We'll crack open the script that is responsible for launching AVDs through the menu just to see how they do it, /opt/mobisec/android-emu.sh, and we'll add the necessary argument, -http-proxy, to proxy traffic and then save it to another script, say android-emu-burp.sh.

Burp Suite's proxy runs on port 8080 by default. If you change the port it runs on, then don't forget to update your script too!

Tying It All Together

Now, we'll run Burp Suite, run GoatDroid, then our AVD, and start looking at the traffic passed through. Poking around the FourGoats application, using goatdroid/goatdroid as our credentials we see that there is a section titled Rewards. Note: If Burp Suite is set to intercept traffic, it you will have to forward each and every request your app makes. You can go ahead and disable it for now by going to the Proxy tab and then the Intercept sub-tab and clicking the Intercept button so it reads, Intercept is off.

Within Rewards there is a tab to view My Rewards, which we don't have any...yet, and another tab to view Available Rewards. In order to unlock these achievements we'll have to checkin with the specified lat/long the requisite number of times.

So, let's see what traffic is involved with performing a check in. Go back to the initial screen and drill into the Checkins screen. You get an indication that your device does not have a GPS location and this might be an issue. If you go ahead and click on the Check In Now button you'll be greeted with an error message. Well bugger...

Fortunately there are two ways around this. Your machine that is running the AVD will have port 5554 open on localhost. From there you can set your coordinates with this command, geo fix <long> <lat>:

Great! This should give us the lat/long so we can forge one checkin for the Steak Master Bonus! Let's go back to the Checkin screen...

Rawr! There appears to be some precision errors doing it this way. Well, there is another method of setting the lat/long on the device and that is to use the Android Debug Monitor (ADM). ADM is a useful utility, that you can launch from MobiSec by running the monitor command. ADM will then launch and give you a great deal of insight on your AVD. Things such as the filesystem, network usage, CPU usage, memory allocations, etc are exposed. We will use ADM more in future posts. In the Emulator tab, you can also set the lat/long as well. Let's attempt to set it to the coordinates that match the One Free NY Mets Ticket achievement and hit send.

Unfortunately we run into the same kinds of precision errors so this is out as well.

Parameter Tampering

In lieu of setting the coordinates through the device, another option we have is to trap the network traffic the app is having with the web service and tamper with the parameters to fool the service. If Burp Suite is not set to intercept traffic, go ahead and enable it by going to the Proxy tab and then the Intercept sub-tab and ensure that Intercept is On. Let's go ahead and click on the Check In Now button to see what we have.

Here, we see that by clicking on the Check In Now button, we send a POST request to /fourgoats/api/v1/checkin, along with the parameters latitude=40.7548083333333334&longitude=-73.84512. This should be fairly straightforward now. We can either modify the parameters in the Raw tab or switch over to the Params tab and do it there. It can be cleaner to do it in the Params tab so we'll do that in this instance.

Now, we have our POST request with our tampered parameters. It's good to go so we'll send it on it's way and click on Forward to send it to the web service. Going back to the app we see our first sign of success.

The tampered POST request was accepted and FourGoats thinks we checked into the Peter Luger Steakhouse. Now, we just have to do this 11 more times to unlock the reward. Normally, you'd repeat the last few steps 11 more times, but Burp Suite can speed this portion up considerably. Click on the History sub-tab of the Proxy tab and identify the POST request that was responsible for sending the forged lat/long.

If you look at the Modified column, Burp Suite helpfully identifies items that you tampered with. This may help highlight the POST of interest. Right click on that item and select Send to Repeater.

Repeater is another tab in Burp Suite that will allow you to quickly and easily repeat POSTs or GETs. Click on the Repeater tab at the top and you should see the POST call you selected in the History sub-tab.

If you wanted to change any parameters, you could do that here similar to how you did it in the Proxy tab, but that's not necessary this time so we can just hit the Go button 11 more times. Let's go see our rewards to see if our trick worked.

Success! Let's go back to Repeater and punch in the other lat/longs and repeat the POST enough times to fulfill the other rewards.