The Problem

Often times when testing iOS applications, getting access to compilable source code is not possible and I’m forced to test the application using a physical device. In order to observe and manipulate the application’s traffic, I’ll typically connect the device to my wireless network, and then configure the iOS client’s wireless network settings to utilize a proxy of my choosing. However, during a recent mobile application assessment, I noticed that a significant portion of the application’s traffic was not being passed through my proxy, but rather, directly to the web service.

As this usually works quite well, I was unsure why iOS was unable to enforce my proxy settings.

After looking a bit deeper, I noticed that the application communicated with two web services; one of which utilized a non standard port (i.e. not 80 or 443). Because of that, the iOS proxy settings would be ignored and traffic would be issued directly to the web service.

The Solution

To work around this issue, I realized that I could simply set up a VPN server, and configure the iOS client to tunnel all traffic (not just HTTP), to a host of my choosing. From there it would be simple to intercept and manipulate the target traffic.

In order to simplify setup, I put together a short bash script to install and configure a PPTP server. I tested it primarily on Kali Linux, however it should work on most Debian based distros.

You can download that script, here.

And yes, as I imagine you’re thinking, I likely did go a bit overboard with the coloring.

Execution of the script will produce the following output:

pptp - 1

Next, you’ll need to configure your iOS device to use the PPTP VPN. You can find instructions on how to do so, here.

Once you have your client connected to the VPN, you’ll need to decide what proxy to use. In this particular case, as my traffic was still HTTP, albeit using a non-HTTP port, I chose to use Burp.  In order to tunnel the application’s traffic to Burp’s interface, we need to add the following iptables rule.

Please note that in the example below, we’re assuming that the application is using TCP port 5555 and that Burp is configured with the default port of 8080.

iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 5555 -j REDIRECT --to-ports 8080

And finally, we’ll need to make a few changes to our Burp proxy settings. First, we’ll need to instruct Burp to listen on all interfaces (or atleast our PPTP interface). Additionally, as our client isn’t aware that it’s traffic is being proxied, we’ll need to configure Burp to perform invisible proxying. This means that Burp will look to the HTTP Host header in order to determine where it should forward the incoming requests.

Burp - 1

You can find further information on Burp’s invisible proxy support here.

Alternatives

In the event that your application is using something other than HTTP, one alternative is Mallory, a transparent TCP and UDP proxy developed by the Intrepidus Group. Using Mallory, it’s possible to intercept and manipulate any binary protocol.