Portable mobile app traffic analysis
One of the phases of mobile application pentesting is to analyze network traffic, usually in order to inspect the kind of data exchanged between the mobile app and the end point its connecting to. It can be used to identify insecure mobile app communication, potential mobile app or server side vulnerabilities, or even insecure mobile app or server-side configurations to name a few.
Some background info...
There are two types of network traffic analysis approaches i.e. Passive analysis and Active analysis. Passive analysis is where traffic is collected and analyzed at a later point in time. Its where you dump network packets usually in PCAP (Packet Capture) or PCAP-NG (Packet Capture - Next Generation Dump File) format and proceed analyze them using network protocol analysis tools such as wireshark.On the other hand Active analysis, is where network traffic is intercepted and the packets are modified on the fly before they are forwarded to the respective intended destination. Ideally, this is a network based MiTM (Man In The Middle) attack, some examples of the such modifications that could be performed are injecting scripts into web pages, packet injection, media replacement. spoofing etc This can be done using tools such as Bettercap/Bettercap-ng, MITMf, Charles proxy, Burp Suite etc
My network analysis setup...
On this blog post, i will focus on passive analysis, however, in the near future i will look into an active network analysis setup. My goal was to monitor mobile network traffic from any specific app of interest. This means that i need an access point to provide internet access, the device that the app resides on, a tactic to capture/dump network packets and lastly the ability to analyze the packets in near real-time or passively.I also needed the setup to be easy to install, configure, highly portable, such that i can easily setup and analyze the network traffic of any app of interest at a moments notice, and can work anywhere that i have access to my laptop.
The network packet capture and analysis setup that i came up with, is as shown below. It might look a little complicated but it really isn't, as i shall illustrate its components and how to replicate it. I took a couple of tries to get it right, especially piping out the network traffic from the hotspot as well as analyzing the packet in real-time but it was definitely worth the effort. You tend to learn a lot more from setup failures.
Choosing an access point...
I started with trying to figure out the kind of access point to use. My first thought was an external USB Wireless adapter such as the TP-LINK WN722N or the ALFA Networks AWUS036 variant either the NEH, NHA or NH adapters. I did some digging online on setting up access points using USB adapters and the process seemed a bit tedious and time consuming to get up and running on a linux machine.I also considered a portable WiFi Router such as the TL-MR3020 flashed with OpenWRT. Flashing the WiFi router seemed like a good alternative however, i will need a power source for the router. So that won't work for me as well. I eventually settled on creating an access point on my rooted nexus 5 android device and used it as a hotspot. The android device used to create the hotspot must be rooted, so that you are able to dump network packets from the created hotspot’s interface.
Pro tip: It's wise to disable any automatic app updates on the device that will connect to the access point (the device running the app you are pentesting). This will also definitely include temporarily disabling any app updates over WiFi, so as to conserve your mobile data.
Setting up the analysis station...
I needed the following Virtual Machine network configurations setup before starting the Security Onion installation process.
- Adapter 1 - Internal network (monitor interface)
- Adapter 2 - Bridged (management interface)
- Adapter 3 - NAT (internet access)
How to install Security Onion is beyond the scope of this blog post, there are a couple of videos by Doug Burks on his YouTube channel showing how to go about it, alongside other neat videos on the variety of tools it ships with. A very important step while running the Security Onion setup, is to ensure the network interfaces are configured as indicated below.
- eth0 - sniffing (monitor) interface
- eth1 - management interface
- eth2 - internet access interface
Pro tip: Be sure to use a reliable and genuine USB cable that can consistently transmit data and current. Some android USB cables, mostly 3rd party ones, tend to only pass current used to charge the device but cannot transmit data reliably, which is a requirement for adb to work properly between the device and the VM.
To ensure the device can send packets to the Security Onion VM, i decided to reverse port forward a specified port that the access point will be sending traffic to. So that on the Security Onion VM, i can listen for packets on the same port. The communication channel sending the packets between the access point and the laptop would be via the USB cable, that was setup earlier. So i had to be careful it doesn't unplug while the hotspot was active.
The newer android debug bridge(adb) binary has the capability to implement reverse port forwarding using the command "adb reverse <local> <remote>" This is the logical opposite of 'adb forward', i.e. the ability to reverse network connections from the device to the host. in this case, <local> corresponds to the socket on the device and <remote> corresponds to the socket on the host.
The Security Onion package repository has a very old version of adb that does not support reverse port forwarding, so i needed to download the standalone Android SDK Platform-Tools. It contains the most recent version of adb alongside other useful binaries such as fastboot. To run adb, all you need to do is unzip the file, change directory into the folder, make the binary executable if need be and then execute it.
To setup the reverse port forwarding from the access point to the security onion VM, you run the following command inside the Security Onion VM:
- ./adb reverse tcp:1337 tcp:1337
- nc -l -v -s 127.0.0.1 -p 1337 | tshark -i -
- nc -l -v -s 127.0.0.1 -p 1337 | wireshark -k -S -i -
- nc -l -v -s 127.0.0.1 -p 1337 | tcpreplay -i eth0 -
Getting some network packets...
I needed a target device where my app of interest resides. This means the ability to dump the network packets for my app of interest and forward them to the Security Onion VM for analysis. In this case, i had two options, either to dump the packets on the device itself using a packet capture app or directly from the access point. Both these options had their benefits and drawbacks. i'll start with the option of capturing packets on the device running my app of interest.Option 1:
The SSL packet capture app for android is pretty neat. It sets up a VPN to capture network packets from the device. It also allows you to capture packets from the device itself or from a specific app of interest. This option is great when pentesting a specific app or a specific set of apps on the device. Since the app installs a user security certificate, the device will give a notification prompt that "Network may be monitored by an unknown third party". This is because by default the device only trusts system security certificates, so this should not worry you.I did tests on some banking, payment and social media apps just to get a feel of the kind of data i would get. I got a mix of encrypted and unencrypted traffic on the payment and banking apps. Including some great info as to the URLs where data is sent and retrieved from. Including some insight of the server side directory structure. Not to mention being able to see the structure of the soap request. On one app, i could even see the raw data being fetched from an enterprise cloud server alongside the API key for my requests. Here are some screenshots of the packets captured from some of the messaging apps i ran some tests on.
Whatapp screenshots
Telegram screenshots
Viber screenshots
On a particular social media app, it was interesting to note that i could send and receive chats but sending or receiving media was not successful because the app was doing some sort of certificate validation before facilitating any media requests. It was kind of weird for the app to do the certificate validation on media only and not on chats, which are also equally important.
The downside of this approach is that a number of client side mitigation can be setup within the app to ensure that either the device does not communicate with the end point provided that the VPN is up and running or if the packet capture app is trying to dump packets.
I came across Net Monitor (Privacy Friendly) that shows active network activity of installed apps on the mobile device. It provides connection information which includes local and remote socket information along with resolved hostnames and a protocol evaluation based on well-known ports. Known unencrypted and encrypted protocols are automatically marked. A detailed mode offers additional technical information of the connections. This is as per the app's description. I liked the fact that the app is privacy focused, so minimal permissions, no ads, no tracking and data collection from the device.
Whatapp screenshots
Telegram screenshots
Viber screenshots
Option 2:
A better alternative is dumping network packet is at the access point. The advantage of this approach is that the application will communicate with the end point as it normally would. Given that at this stage you are only mirroring off the packets passing through the access point. The disadvantage is that you will be dumping all the packets from the device the app is running. You will have to analyze the pcaps and focus on packets to and from the end points of interest. This means that you will need to find a way of identifying IP addresses of the end point the app of interest in communicating with, beforehand or on the fly.Provided that i am using a rooted nexus 5 as my access point, all i needed to do is, get shell access the device via the android debug bridge(adb) and determine the interface responsible for the WiFi hotspot. First you need to enable the WiFi hostspot under the device settings menu and then proceed to look for the interface using the netcfg or the ifconfig command via the adb shell. The IP address of the access point is usually 192.168.43.1/24 and the corresponding interface name will be either ap0 or wlan0.
In order to capture packets from the nexus device, we will need both the tcpdump and busybox binaries. The tcpdump binary for android can be obtained here and the busybox binaries can be obtained from here or installed via the play store. Its important to validate which arm version of the busybox binary works on the respective device you will use as an access point.
To prepare the access point setup, simply install busybox or use the binary provided above. Copy tcpdump to the device at /data/local/tmp (this is the default temp folder in android).
- adb push tcpdump /data/local/tmp
- adb shell "chmod 777 /data/local/tmp/tcpdump
- adb push busybox-armvxx /data/local/tmp
- adb shell "chmod 777 /data/local/tmp/busybox-armvxx
- adb shell
- cd /data/local/tmp/
- su
- ./tcpdump -i wlan0 -s0 -w - | ./busybox-armvxx nc 127.0.0.1 1337
If you installed busybox from the play store, use this command instead.
- ./tcpdump -i wlan0 -s0 -w - | nc 127.0.0.1 1337
I'll definitely write a follow up blog post on how to slice and dice the network packet collected using this setup, and maybe even give an overview on my tools of trade and how i utilize them in mobile app penetration tests.
A huge shout-out to Ruby for her invaluable assistance in writing this blog post, validating the research findings as well as providing some great pointers on designing the packet analysis architecture.
References
- https://www.tutorialspoint.com/android_penetration_testing/android_traffic_analysis_and_interception.asp
- http://resources.infosecinstitute.com/ios-application-security-part-11-analyzing-network-traffic-over-httphttps/#gref
- https://stanfy.com/blog/monitor-mobile-app-traffic-with-sniffers
