Evaluating Mobile Security Products: Network Interception

As described in our overview post on evaluating mobile security technologies, we are releasing a blog series to bring the community up to a collective understanding of the mobile threat landscape, explain our current thinking on evaluating mobile security products, and solicit feedback on both mobile threats as well as evaluation methodologies for the domain.

This post explores the third of four mobile threat scenarios: network interception threats against mobile devices. In addition to describing the threat, we outline potential approaches for evaluating mobile security product capabilities, challenges that exist, defensive opportunities, and areas where we could use community input.

We invite feedback from the community on all aspects of this research, whether better insights into the threats that need to be defended against, types of products to evaluate, or how to evaluate technologies against these threats. Please reach out to the ATT&CK Evaluations team (evals@mitre-engenuity.org) with any comments or questions you might have to help shape our future work in this space.

Network Interception Threats

Users often connect their mobile devices to networks that may pose an elevated risk of security threats, such as public unencrypted Wi-Fi networks (e.g., at a coffee shop or hotel) or cellular networks controlled by untrusted entities. According to the 2019 Verizon Mobile Security Index report, 81% of employees “[a]dmitted to using public Wi-Fi for work tasks, even if officially banned.” These networks provide adversaries with an opportunity to perform network interception attacks, where an adversary attempts to capture or manipulate network traffic.

Adversaries may use techniques such as a rogue Wi-Fi access point (T1465), rogue cellular base station (T1467), ARP spoofing, or DNS poisoning to route the mobile device’s network traffic through a system under the adversary’s control, in order to attempt to perform passive eavesdropping (T1439) or active manipulation of the network traffic (T1463). Plaintext traffic (such as HTTP) can be passively captured, while encrypted traffic (such as HTTPS) requires an active man-in-the-middle attack, where the attacker impersonates the server to the mobile device, captures or modifies traffic, then forwards the traffic to the legitimate server.

Captured network traffic may contain sensitive data such as financial or healthcare information, or credentials or tokens that an adversary could use to maintain access to enterprise resources.

Captured network traffic including an OAuth access token, which can be used to access the victim’s Gmail account

Many mobile threat defense (MTD) products highlight their capabilities to detect man-in-the-middle attacks, leading us to create and perform man-in-the-middle tests as part of our pilot evaluation effort.

In order for a man-in-the-middle attack to succeed, the mobile app needs to trust the certificate presented by the server when establishing an encrypted connection (unless the mobile app is mis-implemented, which happens more often than it should). An adversary could trick the user into installing a malicious CA certificate (the approach we use in our testing), or could illegitimately obtain a certificate from one of the many CAs trusted by default on mobile devices, whether through coercion, DNS hijacking, border gateway protocol (BGP) hijacking, or exploitation of a vulnerability in a CA.

We followed these steps in our tests:

• Installed a CA certificate whose private key we control onto the mobile device via a phishing attack, in order to enable the attacker to perform a man-in-the-middle attack.
• Tested whether the MTD products could detect the presence of an unwanted CA certificate. (Separately, we also verified the ability of EMM products to prevent new CA certificates from being installed.)
• Configured the mobile device’s default gateway to route all outbound network traffic through our computer.
• Ran mitmproxy on our computer to attempt to perform man-in-the-middle attacks on the mobile device’s network communication.
• Checked to see if the MTD products could detect the man-in-the-middle attacks.

A major challenge we face is that we’ve been unable to locate public threat intelligence of man-in-the-middle attacks, or other network interception attacks, occurring in the wild. It is possible that man-in-the-middle attacks are impractical in real-world conditions due to the defensive measures built-in to the mobile device platforms, which we detail below. It’s also possible that these attacks are not being detected or are not being publicly reported.

Below, we describe a potential test plan for evaluating mobile security product capabilities to address man-in-the-middle attacks.

Plan for network interception testing

Defensive Approaches

Apple and Google have recognized that the network should be treated as untrusted, and they have taken steps to provide built-in mitigations in the iOS and Android operating systems to defend from network interception attacks:

• iOS’s App Transport Security and Android’s Network Security Configuration features discourage applications from using plaintext network protocols and to strongly encrypt all network traffic.
• Android’s App Security Improvement Program can detect certificate validation vulnerabilities in apps submitted to the Google Play Store.
• Android apps by default do not trust user-installed CA certificates, and Android provides a “Network may be monitored” warning to users on the device notification screen when user-installed CA certificates are present. iOS requires users to go through multiple steps to trust new CA certificates.

Additional defensive approaches include:

• Mobile app vetting products and services can often detect network security vulnerabilities in apps and can be integrated into the app developer’s continuous integration / continuous deployment (CI/CD) pipeline, so that these vulnerabilities are addressed up-front at development time.
• Mobile security products (such as mobile threat defense agents) may be able to detect the use of hostile networks or the presence of man-in-the-middle attackers.
• Apps can use certificate pinning to associate servers with specific certificates or CAs, rather than trusting all of the CAs in the mobile device’s trust store.
• Certificate Transparency, by forcing CAs to publish all issued certificates into a public audit log, can be used to dissuade inappropriate certificate issuance and identify illegitimately issued certificates.

On both Android and iOS, enterprise mobility management (EMM) systems can set device policies that prevent the user from installing new CA certificates.

A policy prevents the user from adding new CA certificates

Help Inform Mobile Threat Intelligence

This post explores network interception attacks against mobile devices, with a focus on man-in-the-middle attacks, including how to test mobile security product capabilities, as well as descriptions of other defensive opportunities.

We’d appreciate your input. Do you have observations of other forms of network attacks against mobile devices? Are there additional test cases we should consider? Are there other defensive opportunities that we’re not aware of?

Additionally, we’d appreciate contributions of any observations of real-world man-in-the-middle attacks against mobile devices. Without real-world evidence of adversary use, we may not be able to include man-in-the-middle tests in future product evaluations.

In our next post, we’ll introduce our final threat scenario (at least for now) to continue the dialogue on mobile threats.

© 2021 MITRE Engenuity. Approved for Public Release. Document number AT0013