This tutorial will describe how you can use the MitM attack to alter the default behaviour of a mobile application. As result, the application will return all its remote resources which normally are accessible just with a valid subscription.

You come up with a brilliant idea, developed the app and celebrated the release in the app store. The app is popular and you generate revenue via in-app purchases. Happy days! But how secure is your applications code and the data you sell? How quickly can this fortune turn around?

The application I will analyse is an online subscription-based book library. Once you have downloaded a book you can enjoy it offline until your subscription is valid.

Let’s do role-playing and for a second pretend you are a penetration tester evaluating your iOS application security to identify vulnerabilities. We’ll be using common methods attackers use to alter the intended behaviour of an application or to inspect sensitive data stored on the device. The aim of this exercise is not to turn you into a hacker, it is rather to make you more security conscious. Let’s call it ethical hacking.

Keep in mind no application is truly secure, a very determined and smart hacker can go a long way to find a vulnerability in your application. However, by following best practices we can push them to look for less informed and more vulnerable target.

Getting Started

I am not going to name the application because the vulnerability still exists at the moment of writing. They are doing an amazing job digitizing these unique stories and would be a shame to ruin their business. So pick your own app and follow the same principles described here to check how secure it is.

The library iOS app is subscription based, you pay a monthly fee and you have access to all the books while your subscription is valid. There are a few free books as well you can read even without a subscription.

Setting up the playground

Attackers usually use a jailbroken device but you can also use a Simulator as well. Some attacks do not even require a jailbroken device.

At the time when I started to write this article, the application in question used the native iOS frameworks. Setting up a MitM attach was as simple as adding a proxy to the iOS device and trusting the proxy’s certificate. I will not cover this scenario, there are plenty online guides. Check out Burp proxy’s tutorial “Configuring an ios device to work with burp“.

The app was later updated and now it is using another library that will bypass the device proxy settings and will access the remote API directly.

You should also install the SSL Kill switch app that will bypass the certificate pinning in case your app is using this security technique.

MitM #1 – iDB for pentesting iOS applications

Techniques used [Jailbreak needed]:

1. DNS spoofing
2. SSH tunneling
3. MitM proxy with Burp

Since our application won’t comply with the iOS proxy settings we need to be a little creative here. The steps to set up a MitM attack are the following:

1. Redirect the domain name for the remote API to the local device (iOS). Thie can be done by modifying the /etc/hosts file and adding an extra line: api.host.com 127.0.0.1. Now the application will resolve the domain name to the localhost and will try to connect on port 443 (https). Since no application will listen there we will need to solve this.

2. Map port 443 on ios device to port 8080 on the proxy device using ssh. This technique is used remote port forwarding and would look something like this:

ssh -L 443:localhost:8080 root@ios_device_ip

For further reading please see here: https://www.ssh.com/ssh/tunneling/example

3. Run Burp proxy and intercept connections (make sure you have the burp certificate installed in the iOS device as described in the link I mentioned earlier).
Initially, I tried to use the Charles proxy to analyse the traffic but I couldn’t make it work. Charles always returned the message “Invalid client request received: Failed to parse first line of request.” and “Unknown host: null” in the alert tab. Ultimately I gave up and used burp which worked without any issues.

The easiest way to achieve all the settings and mappings mentioned above is to use idb a tool to simplify some common tasks for iOS pentesting and research. You can follow this description on how to set up and run idb on macOS.

In order to find out the domain name, the app is using I used tcpdump on the device itself. This can be sometimes misleading since the reverse domain lookup for the IP can be different than the domain the app is using (multiple domain names can resolve to the same IP).

Now burp can accept connections. Make sure you check that invisible proxying is enabled.

MitM #2 – Transparent proxy

 There are a couple of benefits of implementing a transparent proxy.

1. Jailbreak not needed
2. You don’t need to know the domain name(s) the app is connected to (no need for DNS spoofing)
3. Regardless if the application is obeying the proxy rules or not you can intercept the communication.
4. It can be implemented on any port, not just the traditional (80, 443)

Setup on Linux.

Mitmproxy has a good description of how to set up a transparent proxy. Check out here. The few lines you need to run on Ubuntu 16.04 are (eth0 is the device with the internet access):

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8080

Setup on MacOS.

mitmproxy has a description how to set it up here. I tested this on macOS High Sierra and worked fine.

Enable IP forwarding:

sudo sysctl -w net.inet.ip.forwarding=1 

Place the following two lines in a file called, say, pf.conf:

rdr pass on en0 inet proto tcp to any port {80, 443} -> 127.0.0.1 port 8080

sudo pfctl -f pf.conf
sudo pfctl -e

Route traffic from the iOS device via the transparent proxy

This was the part missing from all the tutorials describing the set up the transparent proxy. While on the proxy side ports 80 and 443 are redirected to the transparent proxy (mitmproxy or Burp) I was missing the traffic from the device.

Basically, you are telling your iOS device that you are accessing the internet via the laptop running the proxy (that’s your gateway).

Vulnerability #1 – Manipulating the API data using MitM attack – Insufficient Transport Layer security

[Jailbreak not needed] Once the API traffic is routed via the proxy and the app is accepting data from it, we can just modify the data the app is receiving. To the app’s credit, it does ignore the device proxy settings and intercepting the data is more challenging.

The app will call a few calls including:

https://api.host.com/api/user
https://api.host.com/api/store

The first will return user-specific information like the subscription details. I could have modified this data but I was not sure what the exact values should be.

The second call will return the data for all the books, it will specify all the metadata and also which category they belong. Analyzing the data and the free books we can see that the app must be checking if a book is part of the free books category and if so it gives you full access regardless of your subscription status. If we modify the data and add the free category to all the books the app will give full access to everything regardless of our subscription status. This was possible due to data manipulation vulnerability. There is no verification if the data received was altered by a checksum for example.

In Burp we can set up a Match and Replace rule to add the book to the free category (id: 25):

Match: “categories”:\[\{“id”:“(\d+)“,“attributes”:\[(.*?)\]
Replace: “categories”:[{“id”:“25”,“attributes”:[“free”]

Vulnerability #2 – Insecure data storage (SQLite)

[Jailbreak needed] Using idb you can easily explore the contents of the database. Given the database is not encrypted at all we can modify the content and add every single book to the free category.

update book_categories set id_cat = 25;

Vulnerability #3 – Insecure data storage (stored resources)

[Jailbreak needed] Using idb it is easy to explore the locally stored files (ssh to the device will give the same result). The app will save all the books in a local folder in epub format. These can then be copied and used in other applications since the content is not protected in any way.

 

Vulnerability #4 – Poor Authentification and Authorization (resources via API)

[Jailbreak not needed] Using the proxy we can observe that the app is downloading the books from the following API endpoint:

https://api.host.com/api/download/234.epub 

Unfortunately, there is no authentification or any type of protection on the endpoints. Just iterating through the numbers, all the books can be downloaded without any issues. Anyone could just recreate a web version of the book library for free using the publicly accessible API.

Summary

Based on my limited testing, the applications failed to implement the following mobile security measures (I did not try to reverse engineer the application or check the code quality). Owasp Mobile Top 10 2016

• M1: Improper Platform Usage.
• M2: Insecure Data Storage.
• M3: Insecure Communication.
• M4: Insecure Authentication.
• M5: Insufficient Cryptography.
• M6: Insecure Authorization.
• M7: Client Code Quality.
• M8: Code Tampering.
• M9: Reverse Engineering
• M10: Extraneous Functionality

Best practices

M2: Insecure Data Storage

#1 Simplified iOS Application Pentesting Using idb – Daniel Mayer

#2 Bypassing OpenSSL Certificate Pinning in iOS Apps

#3 iOS Application Security Review Methodology

#4 Handling sensitive data

#5 Insecure Authorization

#6 Fully Validate SSL/TLS

#7 Insecure Authentication