Mobile Security Testing Guide
Introduction
Changelog
Frontispiece
Overview
Introduction to the Mobile Security Testing Guide
Mobile App Taxonomy
Mobile App Security Testing
General Mobile App Testing Guide
Mobile App Authentication Architectures
Testing Network Communication
Cryptography in Mobile Apps
Testing Code Quality
Tampering and Reverse Engineering
Testing User Education
Android Testing Guide
Platform Overview
Setting up a Testing Environment for Android Apps
Data Storage on Android
Android Cryptographic APIs
Local Authentication on Android
Android Network APIs
Android Platform APIs
Code Quality and Build Settings for Android Apps
Tampering and Reverse Engineering on Android
Android Anti-Reversing Defenses
iOS Testing Guide
Platform Overview
Setting up a Testing Environment for iOS Apps
Data Storage on iOS
iOS Cryptographic APIs
Local Authentication on iOS
iOS Network APIs
iOS Platform APIs
Code Quality and Build Settings for iOS Apps
Tampering and Reverse Engineering on iOS
iOS Anti-Reversing Defenses
Appendix
Testing Tools
Suggested Reading
Powered by GitBook
Have an account? Sign in

Testing Network Communication

Last updated 9 months ago
Edit on GitHub

Practically every network-connected mobile app uses the Hypertext Transfer Protocol (HTTP) or HTTP over Transport Layer Security (TLS), HTTPS, to send and receive data to and from remote endpoints. Consequently, network-based attacks (such as packet sniffing and man-in-the-middle-attacks) are a problem. In this chapter we discuss potential vulnerabilities,testing techniques, and best practices concerning the network communication between mobile apps and their endpoints.

Intercepting HTTP(S) Traffic

In many cases, it is most practical to configure a system proxy on the mobile device, so that HTTP(S) traffic is redirected through an interception proxy running on your host machine. By monitoring the requests between the mobile app client and the backend, you can easily map the available server-side APIs and gain insight into the communication protocol. Additionally, you can replay and manipulate requests to test for server-side bugs.

Several free and commercial proxy tools are available. Here are some of the most popular:

To use the interception proxy, you'll need run it on your PC/MAC and configure the mobile app to route HTTP(S) requests to your proxy. In most cases, it is enough to set a system-wide proxy in the network settings of the mobile device - if the app uses standard HTTP APIs or popular libraries such as okhttp, it will automatically use the system settings.

Using a proxy breaks SSL certificate verification and the app will usually fail to initiate TLS connections. To work around this issue, you can install your proxy's CA certificate on the device. We'll explain how to do this in the OS-specific "Basic Security Testing" chapters.

Intercepting HTTP requests with BURP Suite Pro

Intercepting Traffic on the Network Layer

Dynamic analysis by using an interception proxy can be straight forward if standard libraries are used in the app and all communication is done via HTTP. But there are several cases where this is not working:

  • If mobile application development platforms like Xamarin are used that ignore the system proxy settings;

  • If mobile applications verify if the system proxy is used and refuse to send requests through a proxy;

  • If you want to intercept push notifications, like for example GCM/FCM on Android;

  • If XMPP or other non-HTTP protocols are used.

In these cases you need to monitor and analyze the network traffic first in order to decide what to do next. Luckily, there are several options for redirecting and intercepting network communication:

  • Route the traffic through the host machine. You can set up your Mac/PC as the network gateway, e.g. by using the built-in Internet Sharing facilities of your operating system. You can then use Wireshark to sniff any Internet-bound traffic from the mobile device;

  • Use ettercap to redirect network traffic from the mobile device to your host machine (see below);

  • On a rooted device, you can use hooking or code injection to intercept network-related API calls (e.g. HTTP requests) and dump or even manipulate the arguments of these calls. This eliminates the need to inspect the actual network data. We'll talk in more detail about these techniques in the "Reverse Engineering and Tampering" chapters;

  • On iOS, you can create a "Remote Virtual Interface" instead. We'll describe this method in the chapter "Basic Security Testing on iOS".

Simulating a Man-in-the-Middle Attack

​Ettercap can be used during network penetration tests in order to simulate a man-in-the-middle attack. This is achieved by executing ARP poisoning or spoofing to the target machines. When such an attack is successful, all packets between two machines are redirected to a third machine that acts as the man-in-the-middle and is able to intercept the traffic for analysis.

For a full dynamic analysis of a mobile app, all network traffic should be intercepted. To be able to intercept the messages several steps should be considered for preparation.

Ettercap Installation

Ettercap is available for all major Linux and Unix operating systems and should be part of their respective package installation mechanisms. You need to install it on your machine that will act as the MITM. On macOS it can be installed by using brew.

$ brew install ettercap

Ettercap can also be installed through apt-get on Debian based linux distributions.

$ sudo apt-get install zlib1g zlib1g-dev
$ sudo apt-get install build-essential
$ sudo apt-get install ettercap

Network Analyzer Tool

Install a tool that allows you to monitor and analyze the network traffic that will be redirected to your machine. The two most common network monitoring (or capturing) tools are:

Wireshark offers a GUI and is more straightforward if you are not used to the command line. If you are looking for a command line tool you should either use TShark or tcpdump. All of these tools are available for all major Linux and Unix operating systems and should be part of their respective package installation mechanisms.

Network Setup

To be able to get a man-in-the-middle position your machine should be in the same wireless network as the mobile phone and the gateway it communicates to. Once this is done you need the following information:

  • IP address of mobile phone

  • IP address of gateway

ARP Poisoning with Ettercap

Start ettercap with the following command and replace the first IP addresses with the network gateway in the wireless network and the second one with the one of your mobile device.

$ sudo ettercap -T -i en0 -M arp:remote /192.168.0.1// /192.168.0.105//

On the mobile phone start the browser and navigate to example.com, you should see output like the following:

ettercap 0.8.2 copyright 2001-2015 Ettercap Development Team
​
Listening on:
   en0 -> AC:BC:32:81:45:05
      192.168.0.105/255.255.255.0
      fe80::c2a:e80c:5108:f4d3/64
​
SSL dissection needs a valid 'redir_command_on' script in the etter.conf file
Privileges dropped to EUID 65534 EGID 65534...
​
  33 plugins
  42 protocol dissectors
  57 ports monitored
20388 mac vendor fingerprint
1766 tcp OS fingerprint
2182 known services
​
Scanning for merged targets (2 hosts)...
​
* |=========================================>| 100.00 %
​
2 hosts added to the hosts list...
​
ARP poisoning victims:
​
 GROUP 1 : 192.168.0.1 F8:E9:03:C7:D5:10
​
 GROUP 2 : 192.168.0.102 20:82:C0:DE:8F:09
Starting Unified sniffing...
​
Text only Interface activated...
Hit 'h' for inline help
​
Sun Jul  9 22:23:05 2017 [855399]
  :::0 --> ff02::1:ff11:998b:0 | SFR (0)
​
​
Sun Jul  9 22:23:10 2017 [736653]
TCP  172.217.26.78:443 --> 192.168.0.102:34127 | R (0)
​
Sun Jul  9 22:23:10 2017 [737483]
TCP  74.125.68.95:443 --> 192.168.0.102:35354 | R (0)

If that's the case, you are now able to see the complete network traffic that is sent and received by the mobile phone. This includes also DNS, DHCP and any other form of communication and can therefore be quite "noisy". You should therefore know how to use DisplayFilters in Wireshark or know how to filter in tcpdump to focus only on the relevant traffic for you.

Man-in-the-middle attacks work against any device and operating system as the attack is executed on OSI Layer 2 through ARP Spoofing. When you are MITM you might not be able to see clear text data, as the data in transit might be encrypted by using TLS, but it will give you valuable information about the hosts involved, the protocols used and the ports the app is communicating with.

As an example, we will now redirect all requests from a Xamarin app to our interception proxy in the next section.

Span Port / Port Forwarding

As an alternative to a MITM attack with ettercap, a Wifi Access Point (AP) or router can also be used instead. The setup requires access to the configuration of the AP and this should be clarified prior to the engagement. If it's possible to reconfigure you should check first if the AP supports either:

  • port forwarding or

  • has a span or mirror port.

In both scenarios the AP needs to be configured to point to your machines IP. Tools like Wireshark can then again be used to monitor and record the traffic for further investigation.

Setting a Proxy Through Runtime Instrumentation

On a rooted or jailbroken device, you can also use runtime hooking to set a new proxy or redirect network traffic. This can be achieved with hooking tools like Inspeckage or code injection frameworks like frida and cycript. You'll find more information about runtime instrumentation in the "Reverse Engineering and Tampering" chapters of this guide.

Example: Dealing with Xamarin

Xamarin is a mobile application development platform that is capable of producing native Android and iOS apps by using Visual Studio and C# as programming language.

When testing a Xamarin app and when you are trying to set the system proxy in the WiFi settings you won't be able to see any HTTP requests in your interception proxy, as the apps created by Xamarin do not use the local proxy settings of your phone. There are two ways to resolve this:

WebRequest.DefaultWebProxy = new WebProxy("192.168.11.1", 8080);

  • Use ettercap in order to get a man-in-the-middle position (MITM), see the section above about how to setup a MITM attack. When being MITM we only need to redirect port 443 to our interception proxy running on localhost. This can be done by using the command rdr on macOS:

$ echo "
rdr pass inet proto tcp from any to any port 443 -> 127.0.0.1 port 8080
" | sudo pfctl -ef -

The interception proxy need to listen to the port specified in the port forwarding rule above, which is 8080

CA Certificates

If not already done, install the CA certificates in your mobile device which will allow us to intercept HTTPS requests:

Intercepting Traffic

Start using the app and trigger it's functions. You should see HTTP messages showing up in your interception proxy.

When using ettercap you need to activate "Support invisible proxying" in Proxy Tab / Options / Edit Interface

Verifying Data Encryption on the Network

Overview

One of the core mobile app functions is sending/receiving data over untrusted networks like the Internet. If the data is not properly protected in transit, an attacker with access to any part of the network infrastructure (e.g., a Wi-Fi access point) may intercept, read, or modify it. This is why plaintext network protocols are rarely advisable.

The vast majority of apps rely on HTTP for communication with the backend. HTTPS wraps HTTP in an encrypted connection (the acronym HTTPS originally referred to HTTP over Secure Socket Layer (SSL); SSL is the deprecated predecessor of TLS). TLS allows authentication of the backend service and ensures confidentiality and integrity of the network data.

Recommended TLS Settings

Ensuring proper TLS configuration on the server side is also important. SSL is deprecated and should no longer be used. TLS v1.2 and v1.3 are considered secure, but many services still allow TLS v1.0 and v1.1 for compatibility with older clients.

When both the client and server are controlled by the same organization and used only for communicating with one another, you can increase security by hardening the configuration.

If a mobile application connects to a specific server, its networking stack can be tuned to ensure the highest possible security level for the server's configuration. Lack of support in the underlying operating system may force the mobile application to use a weaker configuration.

Cipher Suites Terminology

ProtocolKeyExchangeAlgorithm_WITHBlockCipher_IntegrityCheckAlgorithm

  • The Protocol the cipher uses

  • The key Exchange Algorithm used by the server and the client to authenticate during the TLS handshake

  • The block cipher used to encrypt the message stream

  • Integrity check algorithm used to authenticate messages

EX: TLS_RSA_WITH_3DES_EDE_CBC_SHA

In the example above the cipher suites uses:

  • TLS as protocol

  • RSA Asymmetric encryption for Athentication

  • 3DES for Symmetric encryption with EDE_CBC mode

  • SHA Hash algorithm for integrity

Note that in TLSv1.3 the KeyExchangeAlgorithm is not part of the cipher suite, instead it is determined during the TLS handshake EX: TLS_AES_128_GCM_SHA256

In the following, we’ll present the different algorithms of each part of the cipher suite: Protocols:

Key Exchange Algorithms:

Block Ciphers:

Integrity Check Algorithms:

Note that The efficiency of a cipher suite depends on the efficiency of its algorithms.

In the following, we’ll present the updated recommended cipher suites list to use with TLS, these Cipher suites are recommended by both, IANA in its TLS parameters documentaion and Owasp TLS Cipher String Cheat Sheet:

IANA recommended cipher suites rfc8447 IANA_CIPHERS:

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_DHE_PSK_WITH_AES_128_GCM_SHA256

  • TLS_DHE_PSK_WITH_AES_256_GCM_SHA384

  • TLS_AES_128_GCM_SHA256

  • TLS_AES_256_GCM_SHA384

  • TLS_CHACHA20_POLY1305_SHA256

  • TLS_AES_128_CCM_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_DHE_RSA_WITH_AES_128_CCM

  • TLS_DHE_RSA_WITH_AES_256_CCM

  • TLS_DHE_PSK_WITH_AES_128_CCM

  • TLS_DHE_PSK_WITH_AES_256_CCM

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

  • TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256

  • TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256

  • TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256

  • TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256

Owasp recommended cipher suites Cipher_String_Cheat_Sheet:

  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA

Some Android and IOS versions do not support some of the recommended cipher suites, so for compatibility purposes you can check the supported cipher suites for Android and IOS versions and choose the Top supported cipher suites

Static Analysis

Identify all API/web service requests in the source code and ensure that no plain HTTP URLs are requested. Make sure that sensitive information is sent over secure channels by using HttpsURLConnection or SSLSocket (for socket-level communication using TLS).

Be aware that SSLSocket doesn't verify the hostname. Use getDefaultHostnameVerifier to verify the hostname. The Android developer documentation includes a code example.

Verify that the server is configured according to best practices. See also the OWASP Transport Layer Protection cheat sheet and the Qualys SSL/TLS Deployment Best Practices.

The configuration file of the web server or reverse proxy at which the HTTPS connection terminates is required for static analysis. See also the OWASP Transport Layer Protection cheat sheet and the Qualys SSL/TLS Deployment Best Practices.

Dynamic Analysis

Intercept the tested app's incoming and outgoing network traffic and make sure that this traffic is encrypted. You can intercept network traffic in any of the following ways:

Interception proxies like Burp and OWASP ZAP will show HTTP traffic only. You can, however, use Burp plugins such as Burp-non-HTTP-Extension and mitm-relay to decode and visualize communication via XMPP and other protocols.

Some applications may not work with proxies like Burp and ZAP because of Certificate Pinning. In such a scenario, please check "Testing Custom Certificate Stores and SSL Pinning". Tools like Vproxy can be used to redirect all HTTP(S) traffic to your machine to sniff and investigate it for unencrypted requests.

If you want to verify whether your server supports the right ciphersuites, there are various tools you can use:

  • nscurl - see Testing Network Communication for ios for more details.

  • ​testssl.sh which "is a free command line tool which checks a server's service on any port for the support of TLS/SSL ciphers, protocols as well as some cryptographic flaws".

Making Sure that Critical Operations Use Secure Communication Channels

Overview

For sensitive applications like banking apps, OWASP MASVS introduces "Defense in Depth" verification levels. The critical operations (e.g., user enrollment and account recovery) of such applications are some of the most attractive targets to attackers. This requires implementation of advanced security controls, such as additional channels (e.g., SMS and e-mail) to confirm user actions.

Static Analysis

Review the code and identify the parts that refer to critical operations. Make sure that additional channels are used for such operation. The following are examples of additional verification channels:

  • Token (e.g., RSA token, yubikey);

  • Push notification (e.g., Google Prompt);

  • SMS;

  • E-mail;

  • Data from another website you visited or scanned;

  • Data from a physical letter or physical entry point (e.g., data you receive only after signing a document at a bank).

Dynamic Analysis

Identify all of the tested application's critical operations (e.g., user enrollment, account recovery, and money transfer). Ensure that each critical operation requires at least one additional channel (e.g., SMS, e-mail, or token). Make sure that directly calling the function bypasses usage of these channels.

Remediation

Make sure that critical operations enforce the use of at least one additional channel to confirm user actions. These channels must not be bypassed when executing critical operations. If you're going to implement an additional factor to verify the user's identity, consider Infobip 2FA library or one-time passcodes (OTP) via Google Authenticator.

References

OWASP Mobile Top 10 2016

OWASP MASVS

  • V5.1: "Data is encrypted on the network with TLS. The secure channel is used consistently throughout the app."

  • V5.2: "The TLS settings are in line with current best practices, or as close as possible if the mobile operating system does not support the recommended standards."

  • V5.3: "The app verifies the X.509 certificate of the remote endpoint when the secure channel is established. Only certificates signed by a trusted CA are accepted."

  • V5.5: "The app doesn't rely on a single insecure communication channel (e-mail or SMS) for critical operations such as enrollment and account recovery."

CWE

  • CWE-308 - Use of Single-factor Authentication

  • CWE-319 - Cleartext Transmission of Sensitive Information

Tools

IETF

Android

IOS

IANA Transport Layer Security (TLS) Parameters

OWASP TLS Cipher String Cheat Sheet

NIST

  • FIPS PUB 186 - Digital Signature Standard (DSS)

General Mobile App Testing Guide - Previous
Mobile App Authentication Architectures
Next - General Mobile App Testing Guide
Cryptography in Mobile Apps
Contents
Intercepting HTTP(S) TrafficIntercepting Traffic on the Network LayerSimulating a Man-in-the-Middle AttackARP Poisoning with EttercapSpan Port / Port ForwardingSetting a Proxy Through Runtime InstrumentationExample: Dealing with XamarinVerifying Data Encryption on the NetworkOverviewStatic AnalysisDynamic AnalysisMaking Sure that Critical Operations Use Secure Communication ChannelsOverviewStatic AnalysisDynamic AnalysisRemediationReferencesOWASP Mobile Top 10 2016OWASP MASVSCWEToolsIETFAndroidIOSIANA Transport Layer Security (TLS) ParametersOWASP TLS Cipher String Cheat SheetNIST