Intercepting traffic on an Android application.

Intercepting traffic on an Android application. Here we will see how to intercept traffic between the Android application and the server it communicates to; it describes what needs to be done and what conditions needs to be met in order to successfully execute a man-in-the-middle attack that compromises the communication. Also describes what certificate pinning is and why it is a required security control.

---

Securing the communication between client and server has always been paramount in providing clients with secure implementations under this model. Usually, when you try to intercept the traffic of a web application through a man-in-the-middle attack, you’ll get an in-browser notification that the communication may be at risk, as we will see down below this article, there are similar notifications for a mobile applications, however, they are not as intuitive to the end-user as those used for web applications.

Certain specific conditions has to be met in order to successfully intercept the traffic for an Android application.

In fact, intercepting the traffic for a mobile application is not that straightforward, there are certain significant conditions that needs to be met in order to successfully execute this attack and compromise the communication between an Android application and the backend server it connects to. These conditions include:

1. Ability to install the proxy’s CA certificate on the device.
2. The application trusts the user installed certificate.
3. Configuring the workstation as a router.
4. Ability to change the device’s Wi-Fi configuration.
5. Bypassing SSL pinning (if present).

Installing the proxy’s CA certificate on the device

In order to be able to intercept the traffic of an Android application, an attacker must first be able to install the attacker’s proxy certificate on the device, here, we need to first define what proxy application we will be using, in this case we will be using mitmproxy: a “swiss-army knife for debugging, testing, privacy measurements, and penetration testing. It can be used to intercept, inspect, modify and replay web traffic such as HTTP/1, HTTP/2, WebSockets, or any other SSL/TLS-protected protocols“.

Once you have downloaded and installed mitmproxy, navigate to ~/.mitmproxy and look for the CA certificate with a .cer extension:

After you have located the proxy’s CA certificate, use adb to push that file into the devices sdcard (/sdcard/), note that, unlike previous articles, in this case we will be using a physical device for our testing:

With the proxy’s CA certificate on your device, head to Settings > Lock screen and security > Other security settings (this may be different on other Android versions, I’m using 7.0), under the Credential Storage section, look for Install from device storage and look for the certificate you just pushed into the sdcard, once selected, hit the DONE button and you’ll be prompted to verify your identity, after verification, give a name to the certificate (mitmproxy in this case) and hit the OK button, if everything is fine, you’ll get a [certificate name] is installed message:

The applications trusts the user-installed certificate

According to the Android’s documentation: “by default, secure connections (using protocols like TLS and HTTPS) from all apps trust the pre-installed system CAs, and apps targeting Android 6.0 (API level 23) and lower also trust the user-added CA store by default“. This means that any app above API 23 will not trust the user-installed certificates (i.e.: what we did in the previous step), if the target application you are dealing with is targeting API 23 or lower, then you can just continue with the process shown below, otherwise, you will have to find a way to bypass this restriction, for instance, you can reverse engineer the application, edit the network_security_config.xml file to trust user-installed certificates and finally recompile and sign the application (more to come on this).

Apps targeting API 23 and lower trusts user-installed certificates by default. For apps above API 23 a workaround is needed for the app to trust these certificates.

If you are targeting API 23 or lower, then the next step will be to configure the workstation (where the proxy will be running) as a router.

Configuring the workstation as a router.

Before running the proxy on your workstation you need to me sure of two things: that the workstation is working as a router (ip_forward=1) and that there are iptables rules to route any TCP traffic to the port the proxy is running on. First we will set our workstation as a router, this will make it work a gateway, therefore, all traffic routed into it will be forwarded to the intended destination, doing this is fairly easy:

echo 1 > /proc/sys/net/ipv4/ip_forward

Now we need to create the required iptables rules, as shown below:

iptables -t nat -A PREROUTING -i wlp3s0 -p tcp --dport 443 -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -i wlp3s0 -p tcp --dport 80 -j REDIRECT --to-port 8080

Here, we are basically creating the pre-route iptables rules to redirect any TCP traffic destined to ports 443 or 80 to port 8080 through the wlp3s0 network interface, mitmproxy will be running by default on port 8080.

Changing the device’s Wi-Fi configuration

We need to configure our device’s WI-Fi to use the just configured workstation as gateway. To do this, on the device we go to Settings > Connections > Wi-Fi and do a long press on the network we’ll be using for our testing (the same network our workstation is connected to), on the pop up menu select Manage network settings and then Show advanced options, on the IP settings dropdown box switch from DHCP to Static and set the Gateway field to the ip address of the workstation (192.168.0.11 in this case), finally hit the SAVE button:

Intercepting with mimtproxy

Once the device configuration has been completed, head to the workstation and run mitmproxy in transparent mode (–mode transparent) and set the –showhost flag to use the host header to construct URLs for display:

./mitmproxy --mode transparent --showhost

This will bring up the the mitmproxy interactive console, by default, the proxy runs on port 8080:

Everything is setup and ready to test, go ahead and run the target application and come back to check the mitmproxy console, you’ll see some usual traffic along with the communication between the application and the backend server (securitygrind.com in this case):

You can use the arrow keys to navigate up and down the request list, once you have found the right request (number six in this case), you can inspect it by hitting enter.

A word on SSL certificate pinning

If you are not able to intercept the traffic with this process, it most likely means that SSL certificate pinning has been implemented for the target application, this means that the application has been instructed to check that the certificate’s public key used when establishing the initial SSL/TLS connection with the server is part of a trusted list of public keys that comes within the apk (either as a resource or hardcoded).

If the application has implemented SSL certificate pinning you will (most likely) not be able to intercept the traffic without having to the certificate’s private key. If you have access to the private key, then you will have to instruct the proxy to present the key when the application is starting an SSL/TLS connection, that way the proxy will be trusted and the traffic will be intercepted. Also, if name checking implemented, you will need to configure mitmproxy to present the certificate linked to a domain name or setup a DNS server of your own for this purpose (more on this to come).

Conclusion

The above article describes the process of intercepting traffic on an Android application. Securing the communication between client and server is a must when developing applications that handle sensitive data. Been able to intercept the traffic, without tampering the application in any sense, means that there is a high security risk, that the integrity and confidentiality of the communication could be in danger and that some changes needs to be done to the application immediately.

10 things you must do when Pentesting Android Applications.