Evaluating Mobile Security Products: Phishing
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 second of four mobile threat scenarios: phishing threats against mobile devices. In addition to describing the threat, we outline potential approaches for evaluating mobile security product capabilities, challenges that exist, 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.
Phishing
The 2019 Verizon Mobile Security Index report states that “[e]nterprise users are three times more likely to fall for a phishing link when on a small screen (Android or iOS device) than when using a desktop OS, like Windows or macOS.” It also reports that 85% of phishing attacks occur outside of email. Other delivery methods for phishing attacks include SMS text messaging, web browsing, social networking, and chat apps.
As an example, Citizen Lab’s September 2019 report details a sophisticated adversary’s attempts to exploit iOS and Android devices using phishing as an initial access vector. A malicious web site was used to deliver exploits targeting the devices. The messaging app WhatsApp was used to send links to the malicious web site, and the links themselves were disguised using the bit.ly URL shortening service.
Adversaries may have varying motivations for performing phishing attacks. For example, phishing attacks may be an attempt to obtain the user’s credentials to other systems (T1598), may be used as an initial access vector to exploit vulnerabilities in the device (T1456), or may be an attempt to trick the user into installing a malicious app (T1476) or malicious configuration settings such as new certificate authority (CA) certificates that enable man-in-the-middle attacks (T1478).
In our pilot evaluation effort, we tested the ability of products to detect or block connections to well-known malicious URLs, including both http and https URLs. We tested with both the original URLs and URLs generated by the TinyURL shortening service. We did not address defending from the broader adversary objectives of phishing attacks here, but some of them are addressed in other threat scenarios.
Below, we describe a potential test plan for evaluating mobile security product capabilities to address phishing attacks. We would appreciate input from the community.
The above table shows defensive opportunities that exist at various stages against phishing attacks, but limitations exist:
- The tests are only performed using well-known malicious URLs, so the ability to detect new phishing web sites is not addressed.
- Filtering capabilities, such as iOS’s SMS filter, may only apply to inbound SMS/MMS messages, but phishing attacks can be delivered through other sources such as third-party chat applications.
- The Chrome web browser has capabilities to detect and block the user from visiting a suspected phishing website. On iOS, security apps can provide content blocker capabilities to the Safari web browser. However, these capabilities may not be present if alternate web browsers are used.
- Security apps on Android and iOS can register themselves as Virtual Private Network (VPN) clients, giving themselves the ability to route all device network traffic through the app and block outbound connections to known phishing websites. However, this approach precludes being able to use another device VPN (for example to connect to enterprise networks). It also may run into limitations as new protocols such as DNS over HTTPS (DoH), TLS version 1.3 and the encrypted Server Name Indication (SNI) extension are adopted, which incorporate new privacy protections that make it more difficult for an intermediary to determine the hostname of the server that is being connected to.
Beyond simply blocking the phishing attack itself, mitigations that prevent adversaries from achieving their objectives can be pursued as well:
- Credential phishing attacks can be mitigated by adopting phishing-resistant authentication methods such as WebAuthn or PKI-based mutual authentication.
- Device exploitation attacks can be mitigated by ensuring that device security updates are installed in a timely manner and decommissioning devices that no longer receive security updates. Exploitation of zero-day vulnerabilities for which updates do not yet exist is still a risk, but these exploits are likely only available to more sophisticated adversaries and reserved for high value targets.
- Enterprises can mitigate installation of malicious apps through phishing attacks by taking steps to detect or prevent app sideloading.
- Enterprises can impose policies to prevent user installation of new certificate authority (CA) certificates, including through phishing attacks. Additionally, Android applications default to not trusting user-added CA certificates, limiting the impact if the adversary is successful in causing the user to install a new CA certificate. iOS requires users to go through multiple steps to trust new CA certificates, limiting the likelihood that users will be tricked into installing and trusting new CA certificates.
This post explores what makes phishing attacks against mobile devices unique, potential test cases for evaluating mobile security product capabilities, and defensive opportunities.
We’d appreciate your input. Do you have observations of other forms of phishing attacks on mobile devices? Are there additional test cases we should consider? Are there other defensive opportunities that we’re not aware of?
In our next post, we will introduce another threat scenario to continue the dialogue on mobile threats.
© 2021 MITRE Engenuity. Approved for Public Release. Document number AT0012
