Mobile Application Security – Man in the Middle (MitM) Attacks and unprotected local storage

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
MitM attack with ssh and dns spoofing
MitM attack with ssh and dns spoofing

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.

Port forwarding
DNS Spoofing
DNS Spoofing

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.

Transparent proxy setup for MitM attack

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

Change default route on the iphone

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

Encrypting sensitive values in an SQLite database using SQLCipher, which encrypts the entire database.  This will prevent modifying the database and add all the books to the free category.

Whenever you encrypt user data, aim to encrypt it using a randomly generated master key, which is also encrypted using a passphrase supplied by the user whenever data is accessed. This will prevent data from being easily recovered should an attacker extract the master key from the device. Due to the number of vulnerabilities in Apple’s data-protection APIs and keychain and the lack of device encryption on the majority of Android handsets, it is not recommended that the master key or a passphrase be stored on the device at all.  #

All the other files, like the .epub files, should be encrypted as well. They could be stored in the database as mentioned above. Alternatively, the Data Protection APIs built into iOS, combined with a complex passphrase, can provide an additional layer of data protection, but are not as secure as implementing additional, third-party verified cryptography.

M3: Insecure Communication

The app does not properly validate SSL/TLS certificate, leaving it vulnerable to man-in-the-middle (MITM) attacks.

Use certificate pinning to protect against MITM attacks. The apps should define the locations to which it connects (their backend server) and inherently trust the infrastructure to which they connect, therefore it’s acceptable (and often more secure) to use a “private” public-key infrastructure, separate from public certificate authorities. #6

Whenever that is not possible implement proper certificate validation, which consists of two parts:

  1. Certificate validation: Certificates presented to the app must be fully validated by the app and be signed by a trusted root CA.
  2. Hostname validation: The app must check and verify that the hostname (Common Name or CN) extracted from the certificate matches that of the host with which the app intends to communicate.

M4: Insecure Authentication

The app does not validate if the data was modified in transition. Using a basic checksum would allow the detection of any change in the received data. Whenever the app is requesting a remote resource it should revalidate the user subscription details and update the manipulated database values.

Avoid Weak Patterns 

  • Where possible, ensure that all authentication requests are performed server-side. Upon successful authentication, application data will be loaded onto the mobile device. This will ensure that application data will only be available after successful authentication;
  • If client-side storage of data is required, the data will need to be encrypted using an encryption key that is securely derived from the user’s login credentials. #7

Reinforce Authentication

  • Developers should assume all client-side authorization and authentication controls can be bypassed by malicious users. Authorization and authentication controls must be re-enforced on the server-side whenever possible.
  • Due to offline usage requirements, mobile apps may be required to perform local authentication or authorization checks within the mobile app’s code. If this is the case, developers should instrument local integrity checks within their code to detect any unauthorized code changes. #7

M6: Insecure Authorization

When downloading remote resources check the server roles and permissions and prevent unauthorised access.

  • Verify the roles and permissions of the authenticated user using only information contained in backend systems. Avoid relying on any roles or permission information that comes from the mobile device itself;
  • Backend code should independently verify that any incoming identifiers associated with a request (operands of a requested operation) that come along with the identify match up and belong to the incoming identity; #5

It would be recommended for developers of mobile apps to ensure all connections are made using secure transfer protocols; enforcing SSL certificate validation; encrypting sensitive data stored by the applications by using the iOS data protection API; improving jailbreaking detection; obfuscating the assembly code and using anti-debugging techniques to slow reverse-engineering attempts; removing debugging statements and information and removing all development information from the final products.

References:

#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

Csaba is passionate about Cyber Security, Pentesting and just making things work.

Leave a reply:

Your email address will not be published.

 

Site Footer

Sliding Sidebar