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.
The setup is very far from perfect, but it gets the job done. There are a few changes i will definitely
make to the setup. Any suggestions are welcome. I will now head over to illustrate
how to replicate the above setup for your own passive network traffic monitoring or in real-time.
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...
One thing i knew from the get go, is that i needed a suitable virtual machine with a wide variety of network analysis tools, to dissect the packets i will be collecting. What better distro to use other than
Security Onion. It ships with a ton of network analysis tools at your disposal. All i needed to do is install it on
VirtualBox using the ISO available on their github page
here. Be sure to install the Virtualbox extension pack on Virtualbox.
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
Once Security Onion was fully installed and the network interfaces properly setup. I needed a way to send network packets from the access point to the Security Onion VM for analysis. I decided to do this via the android USB cable. So i needed to enable a USB device filter for the Security Onion VM via the settings, so that when i connect the USB cable to the device and laptop (host machine), it would connect directly to the VM as opposed to the laptop (host machine). You may need to go to
Devices > USB on the Security Onion virtualbox instance menu, to select the specific device after plugin in the USB cable.
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
I also needed to setup the Security Onion VM to listen to the port specified above, and then pipe out network packets to the tool i wish to inspect the packets with. I started of with
tshark for the test run, using this command:
- nc -l -v -s 127.0.0.1 -p 1337 | tshark -i -
You can also forward incoming packets to either wireshark or
tcpreplay at interface eth0 so that you can utilize tools such a
Bro IDS to parse them. Here are the sample commands to use:
- 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
Both these apps provide the ability to see which IP addresses the app is communicating with, alongside the protocol and even the encryption status, where applicable. It also makes it much easier to later analyze the collected packets as they are app specific. As you can filter the packets based on the desired destination IP addresses.
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
Once this is done, i can now dump network packets from my hotspot interface and proceed to pipe it out to netcat using the command below:
- 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
If all went well, you should see come packets on the Security Onion VM, either on the terminal via tshark or on wireshark. If you use tcprelay you can view the raw bro logs that have been generated or simply use the Kibana dashboard.
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
