Intercept web calls from mobile applications

by Vinnie Vanhoecke — on  ,  ,  , 

cover-image

Introduction

During mobile penetration tests I usually have to set up a local access point to connect my mobile testing devices to it. This access point is set up via a USB wifi dongle on my penetration testing laptop. By setting it up on my penetration testing laptop I have more control about where the traffic should go from the mobile devices. For example I could use some iptable rules to forcefully redirect all HTTP(S) traffic to my proxy server to intercept all the web requests and responses.

Setup Overview

In order to set up a mobile access point you will need a USB wifi dongle which supports access point(AP) mode. These WIFI dongles usually have an atheros chipset inside. You can find them on almost any IT web shop. I use the following USB dongle: TP-LINK TL-WN722N I made an easy script which can create an AP on a linux system with hostapd & dnsmasq. https://github.com/VinnieV/WIFI-AP The following image shows how my setup looks like when I perform mobile penetration tests. Mobile setup

My devices are connected to my mobile hotspot, broadcasted by my WIFI USB dongle. The traffic received from the mobile devices are either send to my burp proxy server by configuring iptable rules on my pentesting laptop or configure the proxy settings on my mobile devices.

Important to note is that Burp should be configured to listen on the interface of the access point (or just listen on all interfaces) and when SSL pinning is in place sometimes enabling the invisible proxy is mandatory. The invisible proxy setting will then convert the non-proxy style requests to proxy requests in order to work sufficiently. This can happen when the application is not using the proxy settings correctly. More info on invisible proxy

Burp - Listen Interface

Burp - Invisible Proxy

How to handle SSL pinning

It happens that the mobile application I am testing is protected with SSL pinning. SSL pinning makes sure that HTTPS traffic can only originate from a server with a specific public certificate. It does that by checking the signature of the certificate to match a certain value. If we use the burp proxy which also intercepts the HTTPS traffic, the app would receive the signature of the burp certificate which will not match the value which is checked in the code. This results in a failed check and the application will fail to work or ignore the burp suite proxy.

Luckily most implementation of SSL pinning are insecure or it can be bypassed with root privileges on the mobile device. I will go a bit more in depth on the following techniques to bypass the SSL pinning implementation:

  1. SSL killer on iphone and sslunpinning on android use it on a rooted mobile device.
  2. Sometimes the implementation just checks if the certificate is present in the certificate bundle pushed by the web application. By just adding the our certificate to this bundle the check will still succeed and we will be able to see the HTTPS traffic. In order to do this you will need to use mitmtool.
  3. Bypass it manually by patching the code which is handling the SSL pinning.

1. SSL unpinning application

On rooted Android phone the most easy way to bypass SSL pinning is with xposed framework and the SSL unpinning application. Install the application and just select the application you want to enable the bypass on. If the application is using the Android native library calls to perform SSL pinning it will be successfully bypassed. The application does that by hooking these functions and always returning a positive result.

On a jailbroken iOS device this can be achieved by installing SSL killer. This will add an option to the settings menu of your iOS device to disable SSL pinning on the mobile device.

2. Implementation fail

Sometimes the implementation of the SSL pinning is not properly designed that it only checks if the certificate is in the certificate chain. The code could look like this (pseudocode):

function SSLcheck():
    for cert in certChain:
        if cert == theCorrectCert:
            return True
    return False

A developer could assume that this implementation makes the application more secure, however it is actually making the application less secure. An attacker could now intercept communication originating from this mobile application when performing a MITM attack without the application returning any warnings about invalid SSL certificates. All an attacker needs to do is when the mobile application establishes an SSL connection and the server sends the public certificates add the proxy self-signed certificates as leaf certificate. So the SSL check will succeed and the communication will be encrypted using the leaf certificate which belongs to the attacker.

This technique can be easily tested using mitmproxy by starting the proxy with following option set to true:

mitmproxy Upstream Option

3. Manual bypass

If all the previous steps fail then it might be necessary to bypass the SSL pinning by reversing the SSL pinning implementation of the mobile application and patching the code to always accept the certificates. There are two common ways to do this:

  • Change the legitimate certificate to your proxy certificate
    Probably somewhere in the code there could be string or some data where the signature of the actual valid certificate is stored. By just changing this value to the certificate to the one of your proxy you could easily bypass the SSL pinning manually.

  • Hook it
    If you identified the function where the SSL certificate is verified for SSL pinning you could hook this function and always return a positive result. This could be done with the popular tool Frida.

I hope I could you a bit with this guide in case you come across a test where you need to do this. Happy hacking!