MiTM Attacks
As virtually all mobile apps communicate with backend systems that require secure network communications, mobile app developers should adopt best practices for secure architectural design and coding techniques.
Man-in-the-middle (MiTM) attacks are essentially a form of digital eavesdropping that exploit a weakness in network communication. They occur when a malicious third party gets between a user’s mobile app and the backend server the device attempts to communicate with. The threat actor can intercept, read, and alter data sent between the two parties.
And worse, a variety of different kinds of MiTM attacks means developers must use multiple techniques to protect their apps. But it’s fairly easy for developers to take a few coding measures to guard against these threats when you fully understand how to code them.
All mobile app developers should use HTTPS for secure communication. MiTM attacks. however, are remote in nature and present tremendous risk to a mobile app user’s personal data because they nullify the confidentiality and integrity provided by HTTPS.
Despite a common misconception, mobile app MiTM attacks don’t only happen over unsecured Wi-Fi at the local coffee shop. In fact, any network device can be used to intercept traffic and the attacker doesn’t need to be in the same room or even on the same network. For example, a virtual private network (VPN) provider could force users to install and trust a malicious root certificate on their devices to gain full access to decrypt network communication.
Hackers can carry out MiTM attacks in many ways, such as using misconfigured self-signed certificates with weak private keys, fake Wi-Fi login portals, e-mail attachments, and free virtual private networks.
How MiTM Attacks Ensnare Users
Thanks to social engineering and phishing, some users can easily be convinced to make changes to their mobile devices to make them susceptible to a man-in-the-middle attack. The attacker’s weapon of choice is a malicious iOS profile or Android certificate.
Say someone visits a conference venue and urgently needs to connect to Wi-Fi. The user attempts to connect to a Wi-Fi SSID that was broadcast with a name similar to the legitimate access point. After being redirected to a captive portal that looks authentic, the user is instructed to download and install a device profile. A captive portal web page requires a user to enter information or accept terms after connecting with a Wi-Fi network before being granted access. These are commonly seen at coffee shops, hotels, and airports.
If a victim ignores vague and innocuous security warnings and installs the profile, the attacker gains access to network traffic and can decrypt nearly everything sent and received by the mobile device.
iOS Attacks With Malicious Profiles
On iPhones, those with iOS profiles can create custom configuration settings on the device. Network administrators commonly use this method to efficiently set up secure W-Fi access or VPNs on employee devices. Apple makes it easy to build custom iOS profiles with the free Apple Configurator 2.
Apple Configurator 2 allows you to add several settings to the profile including:
Custom certificates for installation
Network settings (e.g. what wireless network the device should join automatically)
Proxy settings
VPN settings
Here’s a screenshot of the tool’s UI:
You can see that the profile, in this case, is marked “not signed,” but an attacker can easily sign the profile using a code-signing certificate.
The malicious profile presented to the user contains a self-signed certificate. The certificate needs to be self-signed for the device to install it as a root CA. Clicking on “Install” takes the user to a page that warns the user that installing the certificate will add it to the list of trusted certificates on their device (see screenshot below). This warning clearly fails to convey the actual danger of installing the certificate — that network traffic could be compromised.
Once a user installs the profile, which adds the certificate to a device’s list of trusted certificates, an attacker that is able to redirect all network traffic through their proxy can basically decrypt all the HTTPS traffic sent and received by the device. From the attacker’s perspective, carrying out this kind of MiTM attack required very little time or effort.
Android Attacks via Rogue Certs
While profiles don’t exist for Android devices, an attacker could still trick an unsuspecting user into installing certificates onto the device using similar techniques. An Android user has to install the certificate manually using the device’s security settings by going to “Credential storage” and tapping “Install from storage.” The user then has to select the downloaded certificate file in the .cer format and install it.
Note that, by default, apps don’t work with user-installed CA certificates on Android 7.0 and up. Trusted credentials are now divided into two sections: user and system. Only system CAs are trusted by default. This provides a fantastic security feature that all platforms should adopt in the near future.
App developers can choose to let their apps work with manually added CA certificates, but they must understand the security ramifications of doing so. Also note that Android P only supports HTTPS for all network communication by default. Any HTTP endpoints must be explicitly defined in the Network Security Configuration file.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}