I am going to discuss the basics of penetration testing Android applications over a series of blog posts. I recently did my first mobile app test and would like share my experiences of it. I also hope that these posts will provide some insight into the way mobile applications (specifically on the Android platform) can be tested. This particular post will cover the concept of performing a Man in the Middle (MiTM) attack on Android applications.
First of all, I should start with a bit of an introduction into Android…
Android is a software stack developed by Google and the Open Handset Alliance (OHA) for mobile devices. The security model is quite simple; Every application runs as its own user and group (it uses the same user group model as that of the Linux operating system), applications run under their own user and group ID’s for segregation of user processes. This in theory stops one application from manipulating another applications data. Every application runs inside its own instance of the Dalvik Virtual Machine. Applications interact using permissions which are agreed upon at the time of installation. The user either accepts these permissions or not, if not the application will not install. Security is managed through users and file permissions, the application permissions are set in the AndroidManifest.xml file part of the Application File Packages (.APK’s) which we will look at later. I guess its worth mentioning that all Android applications are developed in the Java programming language. The following is a diagram that depicts the Android software stack rather well:
More information about Android can be found here and is worthwhile reading.
To start with there are two main ways to go about testing Android applications; Using a physical device or using the Android Emulator. I am going to discuss using the Android Emulator in this post, most if not all the techniques can be applied to a physical device and for the purpose of this blog post the Android Emulator should suffice. One of the main issues I faced when testing an application on the Android Emulator was the fact I had no quick and easy way to edit or set the IMEI/IMSI/MSISDN numbers, however, I found this to be possible by patching the source code of the Emulator and I believe there are even patched versions on the internet which allow you to specify these pieces of information as command line arguments when starting the Emulator one example of this is here. The specific application I was testing, during authentication sent its IMEI/IMSI/MSISDN numbers along with the login credentials, it would then send an SMS to the MSISDN sent in the authentication request to verify the user. As the Emulator simply does SIM emulation it was not possible for this specific application to be tested on the Emulator and therefore I needed to perform the rest of my testing on a physical device. So you may encounter situations where the Emulator does not provide everything you need, however in most situations it is fine.
First of all it is necessary to install the Android SDK for the platform you wish to test from. I will not regurgitate this information as it is explained very well on the Android Developers web site, located here. Once you have the Android SDK installed, it is worthwhile adding the tools directory to your system path. I am running the SDK on Windows 7 platform so I added the following directory to my system path:
"C:Program Files (x86)Androidandroid-sdktools"
It allows for easy execution of the Emulator and related tools. Once this has been done, you will need to create an Android Virtual Device using the Android Virtual Device Manger (AVD Manager), so launch this application and you will see the following screen:
From here you have the ability to create an AVD based on the android version of your choice, for the purpose of this post I will create an AVD of Android 4.0.3, you have the ability to specify the SD card size, and any specific hardware requirements. To do this, click new and fill out the next screen, then click ‘Create AVD’. Once the AVD has been created you will be left with a screen that looks like this:
Now you have an AVD, you can begin your testing on/with. To update the available virtual devices (e.g. Android 2.3.3, 3.0, 3.1, 3.2, 4.0 and respective tools) you will need to run the Android SDK Manager:
From within there you can install the different versions of Android and respective tools for use when creating the AVD. Now back to the Emulator, you can start the Emulator from within the AVD Manager however I like to do this from the command line as you have more control over the options you pass it. For the list of available command line options you can use with the Emulator please take a look here. The ones that we are most interested in are:
So to start the Emulator and make all TCP connections through BurpSuite Proxy (as this is my proxy of choice) we can do the following:
Obviously you will need BurpSuite running in the background prior to executing the above command. The Emulator takes some time to boot up but when it does you should be presented with the following screen:
Excellent, now we have a platform on which we can test our Android applications. We can push all TCP connections through an HTTP/HTTPS proxy (BurpSuite) and also take packet captures of all network traffic using the -tcpdump option this should allow us to fully test any Android application and get a good overview of its security posture. Using BurpSuite allows us to manipulate any HTTP/HTTPS requests and response that are made in the client-server communication if the application is using a client/server model, not all do! To test that our traffic is going through BurpSuite, I suggest placing ‘intercept on’ in BurpSuite and quickly loading up the Android Browser, make a request to Google and you should see something similar to the following:
As you can see our web traffic is going through BurpSuite. So if any application that you are testing performs any communication over HTTP/HTTPS we can manipulate the requests and response and can effectively Man in the Middle the traffic which is just what we want. Any other traffic the application has will be caught using TCPDump. In order to get a packet capture of all network traffic you need to start the emulator with the following option: “-tcpdump capture_file.pcap”. Once you’ve booted the Emulator up, ran the application and closed the Emulator you can take the capture_file.pcap and load it into a tool such as Wireshark to view the packets as you would with any other pcap file. If you wanted to manipulate the other traffic that is not caught by BurpSuite, you could use a tool such as Echo Mirage or Mallory you will then be able to intercept and modify all requests, however thats a topic for another post.
Now we have the ability to intercept any HTTP/HTTPS traffic, one thing worth mentioning here is about SSL. We can MiTM SSL based browser traffic just fine, however when it comes to the android applications, any SSL error will cause the application to fail to load. By placing our proxy in between the Emulator and the internet we cause certificate errors and the application fails to load. There are two things we need to do; We need to make our BurpSuite root CA certificate trusted by the device and use a tool called Android Proxy to re-write the “CONNECT IP” to “CONNECT DOMAIN_NAME” so that no SSL errors are generated and our application loads successfully.
To add the BurpSuite certificate to the ca store on the phone, as of Android 4.x it was made very simple you can place it on the SDCARD and install from there using a couple of menu options, prior to Android 4.x you needed to pull the castore down from the phone, insert the certificate using the keytool program and then push the castore back to the device, this process is talked about very clearly here. To download you’re BurpSuite certificate follow the instructions located here you will need to export the certificate and save it locally, make sure that you export the root PortSwiggerCA certificate. Once you have the certificate, boot up the Emulator, once it is booted follow this process to get the certificate installed and trusted by the Emulator:
adb server is out of date. killing...
* daemon started successfully *
List of devices attached
C:Usersdusty>adb push PortSwiggerCA.crt /sdcard/
10 KB/s (1038 bytes in 0.095s)
We have now pushed the certificate to the /sdcard folder of the Emulator, we can now navigate through the menu options to install this. Go to the Settings Screen, Select Security and scroll down to ‘Install From SD Card’:
If you select this option, it will install the PortSwigger certificate (you may have to set a screen lock for you’re device, go ahead and do this). When the certificate is installed, the only thing left to do is setup the Android Proxy and we’re good to go. To do this, download the Android Proxy script, run it with: “python main.py”, you must be the Administrator to run Android Proxy. Then load BurpSuite up in the background and start you’re Emulator like so: “emulator -avd BlogPost -http-proxy http://localhost:8007 -dns-server localhost”. At this point you should be able to MiTM all HTTP and HTTPS traffic that is being sent from any of you’re Android applications. The following screen shots show this:
I navigate to an HTTPS enabled site..
and see the HTTPS traffic in BurpSuite without issues. This works across the board for applications and browser traffic. You should see something similar to this on the Android Proxy command line:
DNS server will listen on localhost:65
HTTP Proxy will listen on localhost:8007
Start emulator using command: emulator @AvdName -http-proxy http://localhost:8007 -dns-server localhost
==== Android Proxy Up and Running ====
DNS: pool.ntp.org -> 188.8.131.52
DNS: www.xkcd.com -> 184.108.40.206
PROXY: 220.127.116.11 -> www.xkcd.com
From this point onwards you can treat the Android application you are testing as a web application and the same methodology applies when manipulating the traffic between the application and server.
That is it for this blog post. In the next post I will discuss the other concepts of penetration testing Android devices, such as; application footprint analysis, reverse engineering the Android application and how to view the source code (or a loose implementation of it) and read the XML files that are contained within the .APKs. The next steps after being able to MiTM the Android application would be to do an footprint analysis of the application which is basically phone file system analysis this is probably the most tedious part of testing Android applications but it can sometimes yield fruitful results! After that taking apart the APK for the application would be the next step, these will be discussed in the following blog post.
Hope this proves useful to someone, any questions please leave a comment 🙂