Simply test the privacy of a mobile application's data streams

During audits conducted by Intrinsec on mobile applications, we found that numerous flaws could compromise the confidentiality of HTTP exchanges despite the use of SSL-encrypted streams (see here).

Smartphones and tablets may need to communicate through public WiFi networks where traffic interception is easy, the risk of information leakage, whether voluntary or not, is very real (see. here)

Certificate validation failures are sometimes due to development errors, oversights during test case creation, or the use of external libraries. In all cases, it's not always easy to verify, during code analysis, that the confidentiality of HTTP traffic from a mobile application is guaranteed.

Therefore, through this article, we wish to address mobile application developers and explain how, by carrying out a simple test, it is possible to validate that an Android or iOS application ensures this level of confidentiality.

Several tools are needed for this:

•  The Android and/or iOS SDK, or more precisely the associated emulator (as a developer you must use it).
• A web interception proxy performing an SSL cut, such as Burp Proxy (http://portswigger.net/burp/download.html) or OWASP Zap (https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project).

We will subsequently use Burp Proxy.

Step 1: Configuring the Burp interception proxy

This proxy will allow us to intercept HTTPS traffic to validate the application's behavior in case of an attack.

By default, Burp will open a socket on port 8080 of the machine's loopback port. If this port is already in use, you will need to use another one by configuring the application as follows:

When used within a corporate network, it may be necessary to proxy the output of the intercepting proxy; this can be done as described below:

The final step is to disable HTTP request interception, as the goal here is not to modify the requests made by the application on the fly:

At the end of this step we therefore obtain a proxy blocking SSL flows and listening on port 8080 (or another if you have modified it) of the loopback.

Step 2: «Proxyfication» of the emulators.

The goal is to route the emulators' traffic through the Burp interception proxy to study how the application behaves in the event of an SSL outage. This requires configuring the emulators to redirect their traffic through this proxy.

Proxying the Android emulator is easy because the `emulator` command, which launches an emulator, has a `-http-proxy` option. Simply use this option with `localhost:8080` as a parameter. It's also possible to add this option directly to the Eclipse debug or runtime configuration.

The iOS emulator, on the other hand, does not have an option to proxy it directly; therefore, it is necessary to configure the proxy at the macOS system level:

Step 3: Analysis of application behavior

The behavior of the application once proxyed allows us to verify whether it is still possible to use it normally in the event of an interruption of the encryption stream.

Analyzing queries in Burp helps identify several potential flaws:

• The presence of unencrypted HTTP requests could allow the interception of sensitive information (authentication credentials, cookies, business data, etc.).
• The presence of encrypted requests intercepted without the application ceasing to function or raising an alert to the user.

We recommend performing this simple test to validate the functionality of an external library or before deploying a new application to production. If defects are identified, a code review should be conducted to identify and correct them.