Flinkd!

Recently, I’ve noticed a significant rise in the number of mobile applications making use of local encryption in order to encrypt request parameters prior to passing them over the wire. Not only does this make casual observation of the traffic more difficult, any type of parameter tampering/manipulation will likely fail unless the supplied payload can be successfully decrypted by the backend.

With that in mind, I developed a simple Burp Extender plugin that utilizes the IIntruderPayloadProcess interface in order to automatically encrypt payloads managed by Intruder. This way you can select an application request, identify the parameters that are encrypted, and select your payload listing as normal.

The only downside of this approach is that Intruder will show the fully encrypted payload within the results tab. In order to determine which payload was actually sent you’ll need to decrypt the payload by hand.

You can download the Netbeans project and JAR here.

(continue reading…)

Updated (2-11-15): I’ve written a new post which describes installing Google Play on Android 5.x.  You can find that post, here.

Before I begin, I just want to mention that what I’m about to describe is by no means new. There are several other posts out there which describe how to install the Google Play packages under the Android Emulator. However, today I needed to create a new AVD for a project I’m working on and after searching for a few minutes, I realized that most of these posts are outdated and contain broken links to the appropriate Google apps. As such, I’ve decided to wikify it here.

This document outlines the steps required using the latest version of the Android SDK (Revision 22.3) and is focused on Android 4.3 (API 18). Although Android 4.4 (Kit Kat) is out at the time of writing, the appropriate Google Apps package is not yet publicly available.

With that, let’s begin by launching the SDK manager. We’ll first need to ensure that Android 4.3 (API 18) is installed.

[pyoor@localhost tools]$ ./android sdk

If not, check the top level element, “Android 4.3 (API 18)”, click “Install 6 Packages”, and accept the license agreement.

Once installed, close the SDK manager and launch the AVD manager. Here we’ll need to create a new AVD which utilizes the Android 4.3 platform and has snapshots enabled so that any changes we make are persistent.

[pyoor@localhost tools]$ ./android avd

Next we need to pull down the appropriate Google Apps package. Using Android 4.3 (API 18) we must use the “20130813” package. You can find that package at the Goo.im page.

Please note that this package will only work for Android 4.3. For earlier versions of Android, please see the RootzWiki here. A full listing of packages can be found here.

Once downloaded, extract the archive. In order to install Google Play, we’ll need to push the following 3 APKs to our AVD (located in ./system/app/):

• GoogleServicesFramework.apk
• GoogleLoginService.apk
• Phonesky.apk

However, before we do, we need to make some minor modifications to our AVD. Let’s launch the newly created AVD using the following command. Note that we’ve specified a partition size of 512MB. This is to ensure that our AVD has enough capacity to install the Google Play Store and its dependencies.

[pyoor@localhost tools]$ ./emulator -avd Test -partition-size 512 -no-boot-anim

This may take several minutes the first time as the AVD is created. Once started we need to remount the AVD’s partition and modify the permissions of “/system/app/” as this is where our packages will be installed to.

[pyoor@localhost platform-tools]$ ./adb remount
[pyoor@localhost platform-tools]$ ./adb shell chmod 777 /system/app/

And finally, we can push these APKs to our AVD:

[pyoor@localhost platform-tools]$ ./adb push ~/system/app/GoogleServicesFramework.apk /system/app/
[pyoor@localhost platform-tools]$ ./adb push ~/system/app/GoogleLoginService.apk /system/app/
[pyoor@localhost platform-tools]$ ./adb push ~/system/app/Phonesky.apk /system/app/

Now if your emulator is as slow as mine it may take a few minutes for the package to be installed. You’ll know if the installation hasn’t yet completed if the launcher process repeatedly crashes on you 😉

After a few minutes, we should see the Google Play package appear within the menu launcher. After associating a Google account with this AVD we now have a fully working version of Google Play running under our emulator:

The Problem

Often times when testing iOS applications, getting access to compilable source code is not possible and I’m forced to test the application using a physical device. In order to observe and manipulate the application’s traffic, I’ll typically connect the device to my wireless network, and then configure the iOS client’s wireless network settings to utilize a proxy of my choosing. However, during a recent mobile application assessment, I noticed that a significant portion of the application’s traffic was not being passed through my proxy, but rather, directly to the web service.

As this usually works quite well, I was unsure why iOS was unable to enforce my proxy settings.

After looking a bit deeper, I noticed that the application communicated with two web services; one of which utilized a non standard port (i.e. not 80 or 443). Because of that, the iOS proxy settings would be ignored and traffic would be issued directly to the web service.

The Solution

To work around this issue, I realized that I could simply set up a VPN server, and configure the iOS client to tunnel all traffic (not just HTTP), to a host of my choosing. From there it would be simple to intercept and manipulate the target traffic.

In order to simplify setup, I put together a short bash script to install and configure a PPTP server. I tested it primarily on Kali Linux, however it should work on most Debian based distros.

You can download that script, here.

And yes, as I imagine you’re thinking, I likely did go a bit overboard with the coloring.

Execution of the script will produce the following output:

Next, you’ll need to configure your iOS device to use the PPTP VPN. You can find instructions on how to do so, here.

Once you have your client connected to the VPN, you’ll need to decide what proxy to use. In this particular case, as my traffic was still HTTP, albeit using a non-HTTP port, I chose to use Burp.  In order to tunnel the application’s traffic to Burp’s interface, we need to add the following iptables rule.

Please note that in the example below, we’re assuming that the application is using TCP port 5555 and that Burp is configured with the default port of 8080.

iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 5555 -j REDIRECT --to-ports 8080

And finally, we’ll need to make a few changes to our Burp proxy settings. First, we’ll need to instruct Burp to listen on all interfaces (or atleast our PPTP interface). Additionally, as our client isn’t aware that it’s traffic is being proxied, we’ll need to configure Burp to perform invisible proxying. This means that Burp will look to the HTTP Host header in order to determine where it should forward the incoming requests.

You can find further information on Burp’s invisible proxy support here.

Alternatives

In the event that your application is using something other than HTTP, one alternative is Mallory, a transparent TCP and UDP proxy developed by the Intrepidus Group. Using Mallory, it’s possible to intercept and manipulate any binary protocol.