Efficient way to pentest Android Chat Applications
Article on how to setup environment to pentest the network calls of Android chat applications
Setting up a pentest environment for a single Android application to test its functionalities is simple. The process involves just setting up an Android emulator, installing the app, sending the traffic through a proxy tool like BurpSuite and playing with the traffic to find interesting behaviour.
When it comes to setting up pentest environment for an Android chat application, the setup slightly differs. This is not the case only for chat apps but also for other apps whose functionality (like multi-user authorization) could be completely understood only when running the app in two or more devices simultaneously. In this article, we’ll look at how to setup the Android chat app pentest environment using Genymotion emulator and BurpSuite.
Assumptions:
Before we continue with the article I assume that:
- You are trying to pentest the HTTP calls made by the app and are not interested in the implementation of the app (like Javascript enabled in WebViews, etc)
- The app doesn’t have any SSL pinning or root detection. Even if the app has, it is assumed that you have bypassed it successfully.
- The app supports x86 architecture based hardware as Genymotion emulates an x86 Android device. If the app only supports ARM, please use Android Virtual Device (AVD) instead of Genymotion. Please note that running apps on AVD might be comparatively slow.
- Two or more simultaneously running Android emulators are required for understanding and testing the functionality of the app.
- You were able to successfully setup Genymotion and BurpSuite Community Edition.
- Last but not the least, you have permission to test the Android app.
Setup the test environment:
Open Genymotion and download two device types. You can also feel free to download one device and create another clone of it.
After setting up the emulator devices, start them, drag and drop the apk file into the emulator windows to install the app. Fire up BurpSuite Community Edition. Goto Proxy → Options → Proxy Listeners and add two proxy listeners for the host’s IP address which is connected to the emulator, one on port 8080 and another on port 8081. You will understand why we added two ports if you manage to complete this article.
(Note: If you have installed VirtualBox & Genymotion and haven’t tweaked VirtualBox’s network settings, by default the Android emulator starts with 192.168.56.xxx IP address and your host is assigned with the IP address 192.168.56.1).
Start an emulator device, goto Settings → Wifi → (Long press Wifi network) Modify Network (the flow might change in some Android versions) and add proxy hostname as 192.168.56.1 and port 8080. Open the second emulator device, continue the same process but add the port as 8081.
Make sure you install Burp CA on both the emulators.
Now you have setup the pentest environment for the app. Open the app in both the emulators and you could see the traffic rushing through BurpSuite. The traffic includes HTTP calls to the target domain and sometimes its subdomains, a bunch of analytics services and the Android phone’s connectivity checks.
For an example, let us open https://m.facebook.com on default browser in both the emulators.
Lots of network calls in a few seconds.
It’s easy to get confused on which app on the emulators made which HTTP request. Even if you are not confused, don’t worry, you would get lost in an ocean of HTTP requests sometime after playing with the app.
Notice one interesting column called Listener port which would be hiding at the end of all columns by default. It maps the network calls with the BurpSuite attached ports through which they were proxied. This helps us understand which app on which emulator devices made the request. Later in the pentest, we could sort the HTTP requests based on the Listener port and check if some interesting requests were made by one app but not the other. We have setup the pentest environment, but its not efficient unless you tweak some BurpSuite settings.
BurpSuite tweaks:
Android apps are always built with analytics enabled. Even if analytics is not enabled by the app, there’s always connectivity checks by Android itself. If you intercept all traffic, you would end up intercepting the uninteresting analytics and connectivity check HTTP calls. Coming back to our example, let’s say we want to target requests made to any subdomain of facebook.com, i.e *.facebook.com.
Adding the target to scope:
Goto Target → Scope → Target Scope. Enable advanced scope control, click on Add button, enter .*\.facebook\.com$ in the Host or IP range and click OK. (If your target domain is targetdomain.com, then the hosts regex would be .*\.targetdomain\.com$ ). Now you can set the BurpSuite HTTP history tab to only show traffic for the target domain.
Intercepting HTTP requests only to the target requests:
Even after you add the target domains to scope, network calls to other non-target domains will be intercepted by default if the “Intercept” is on. To enable interception only on the target domains, goto Proxy → Options → Intercept Client Requests, click add, enter the same regex we had used earlier and click OK. In this example, the regex would be.*\.facebook\.com$ .
Download links:
- Genymotion : https://www.genymotion.com/fun-zone/
* requires registration - BurpSuite Community Edition : https://portswigger.net/burp/communitydownload
Unlock the latest in DevSecOps, Cloud, and Cloud Native Security. 🚀
Subscribe now and get my blog posts delivered straight to your inbox!
If you liked the article, please hit the 👏 button and have a look at AndroidTamer — an open source virtual platform for Android Security Professionals.
