Skip to content

Introduction to Pen-testing Android Applications Part 1…

by on June 7, 2012

Hello All,

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)\Android\android-sdk\tools"

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:


-http-proxy
-dns-server
-debug-proxy
-tcpdump

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:


C:\Users\dusty>adb devices
adb server is out of date. killing...
* daemon started successfully *
List of devices attached
emulator-5554 device

C:\Users\dusty>adb push PortSwiggerCA.crt /sdcard/
10 KB/s (1038 bytes in 0.095s)

C:\Users\dusty>

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:


C:\Users\dusty>python androidproxy.py
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 -> 1.1.1.2
DNS: http://www.xkcd.com -> 1.1.1.3
PROXY: 1.1.1.3 -> http://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 🙂

11 Comments
  1. tom permalink

    Hello dusty, thanx for the very interesting post. Would it be possible to write couple lines about the way,how to simulate imsi, msisdn in emulator. Also i am very curious about the second approach you mentioned – intercepting and manipulating requests send from physical device… thanx

    • dusty permalink

      Hello Tom,

      I am glad you liked it. The IMSI and IMEI numbers are hardcoded into the Emulator, these can be spoofed by editing the source code or using a hex editor. The following are some links that will help you do this:

      Android IMEI number and the Emulator
      Android Emulator patch for configurable IMEI, IMSI and SIM card serial number

      Security Compass have modified the source code to the Emulator so that you can spoof the IMEI and IMSI numbers when booting up the Emulator (by specifiying command line arguments), please take a look at the following link:

      Weaponizing The Android Emulator

      I have not yet found a successful way to change the Emulators built in MSISDN number, however there is a number that comes up when you go into the phones menu, mine is currently set to: “1-555-521-5554”. I assume this is also a hard coded value in the Emulator so it might be worth doing a search for that number and using the same method as for the IMEI, IMSI although i’ve not tried this, let me know if you manage to change it. There is an application on the Google Play that claims to be able to change the number it only works with a handful of Android devices with certain Mods, I don’t think it will work on the Emulator as it changes it on the SIM card, but here is a link just in case:

      How to add your mobile number to your phone
      My Phone Number

      In regards to intercepting and manipulating the requests sent from a physical device the method is very similar. What I tend to do is setup a fake wireless access point on a linux laptop using Airbase-ng, I then get the phone to connect to the fake wireless access point. That means you can sniff all traffic running through the access point (Using TCPDump / Wireshark) out to the internet and you can use iptables to manipulate where the traffic is being sent, e.g. to a proxy. This would be the perfect scenario for the Mallory tool to be used as you can capture all traffic then.

      Hope this helps, any further questions don’t hesitate to ask 🙂

  2. tom permalink

    Hello Dusty,
    thanx again for all the info as well as all the links you mentioned. I have grep-ed msisdn in sources and it looks like it should be possible to modify it.
    Regarding physical device – In my scenario I have to test the application, which uses implicit authentication while connected over 3G, which is based probably on msisdn, imsi…When you are connected over Internet (wifi), the authentication is based on login/password. My primary goal is to test implicit authentication. In example you described, I can use fake access point scenario, but the access point should be connected to the 3G modem provisioned with proper sim card (in order to have access to the service over 3G). I am not sure, if this case will trigger implicit authentication or not (probably not), but i think its worth trying.
    What I am looking for is a way, how to intercept and modify all requests directly in device on system level (using some android app like Tamper Data firefox plugin. Do you know, if something like this is possible? Even dumping all the corresponding network traffic into a file would be great for understanding the process of authentication.
    Thanx again for your feedback.

    tom

    P.S. This is my first mobile app pentest, so I am still looking around for right tools and information etc, so I really appreciate your patience 🙂

  3. Hi Dusty,

    (Sorry for my English, I’ve to improve it)

    Thanks for posting this information, is very useful but I’m having problems with the certificate. In my scenario, I have a virtual machine (Ubuntu) with the SDK installed. I emulated two android devices, one of them running 4.0.3, the other 2.3.

    I uploaded the .cert file in two ways. One of them, using the security menu through panel settings and the other was by the manual way. Both of them work properly, the PortSwigger cert is recognized as a trusted certificated for my android device.

    To be quickly, I have the following setup:

    – Burp proxy running on 127.0.0.1:8080
    – Android device emulated with the flags -http-proxy and -dns-server
    – AndroidProxy tool :

    · DNS server will listen on localhost:65
    · HTTP Proxy will listen on localhost:8007

    When I try to get access to Gmail for example, I have to validate manually the certificate. This action doesn’t seem to be valid when I’m running an application and I want to see the traffic between the app and the server.

    I’m not able to see where is the configuration error. I think everything is ok, but I’m not able to sniff the traffic in a properly way. Could you help me please?

  4. Nice first part on this topic.
    My question would be: how would i make the connection safer?
    In my concrete example, i’m gonna create a shopping app soon. You’ll need an account for it,that is stored serverside,just like orders are. My approach was to make Get-Requests with username and password as arguments all the time(when doing order-specific things,changing settings or so,not for just browsing the items in the shop). Password would be hashed of course.

    Which way would you suggest to handle things like these?
    Thanks for your answer already 🙂

  5. dev permalink

    Hello dusty: the burp cert is stored temporarily in sdcard and everytime I need to push that in sdcard for testing.. Is there is any way to store it permanently in the image?

  6. kumar permalink

    Hey Dusty,
    Must say a nice article explaining basic setup required before u jump in for testing. I am facing problem with the intercepting. I tried all the ways to intercept using Burp but no luck. A simple google site (without SSL) also not able to capture. Pls advice.

  7. hi dusty, would like to ask how do you run the androidproxy tool ? seems not working to me..

  8. Saman permalink

    Dear Dusty
    Hello
    Hope every thing is well with you.
    First of all, I really appreciate your useful Post.
    I want to test an android application in emulator. the first step of this application, a message
    send to the server and a kind of authentication occurs based on sending and receiving some messages.
    so I want to know how could I simulate a Sim card in emulator or by bypass this steps in order to test this application.

  9. I ought to admit that your post is really fascinating.
    I have spent lots of my spare time reading your content material.
    Thank you a whole lot!

Trackbacks & Pingbacks

  1. Mobile Device Penetration Testing Learning Resources - Hackers Mail

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: