What is jailbreaking/rooting?
Jailbreaking or rooting phones provides users with unprecedented freedom. However, because jailbreaking/rooting also removes crucial security features, such as sandboxing, hackers have an easier time stealing critical information from apps on jailbroken devices, such as user credentials from a banking app. Users are unwilling to stop jailbreaking/rooting their phones, so, the question is, how can banking apps secure themselves even on a jailbroken or rooted phone?
Users jailbreak/root their phones all the time to get past the operating system’s restrictions. For example, jailbreaking an iPhone removes the restriction that apps can only be downloaded from the iOS App Store; apps can now be downloaded from third-party app stores, such as Cydia. You can install custom themes, change the look and feel of the phone, play Nintendo games or even have your phone capture pictures of people who enter wrong passwords. Unfortunately, the fun and the freedom comes at a price: jailbreaking/rooting strips the phone of “sandboxing”, one of the most crucial security features of the operating system.
Problems with apps on jailbroken devices
Sandboxing provides strong protection against apps from accessing information in other apps or in the operating system files. For example, when a newly installed app tries to access your location, photos, or contacts, Apple asks for your explicit permission through a pop-up. When you remove the sandbox, the app can access all the private information on your phone. For example, malicious apps on jailbroken devices can compromise the system database and access the data folder of a banking app on your phone. If the information therein is unprotected, the hacker might well be able to access critical banking credentials.
There are numerous avenues of attack that make apps on jailbroken devices vulnerable. After jailbreaking/rooting a phone, the hacker might also try to reverse engineer the application source code and try to access hard-coded secrets, such as cryptographic keys. She may also try to exploit vulnerabilities, weaknesses and design flaws, such as credit card numbers stored without being encrypted, weak PINs, and not-secure-enough tokens. She might also try to tamper with the application source code and repackage it with malicious executables. In summary, the sensitive information that is being put at risk falls under one of the following three categories:
- cryptographic keys,
- sensitive credentials such as credit card numbers, email addresses and zip code, and
- proprietary information about the source code.
There are multiple approaches to protect apps on jailbroken devices, with varying degrees of effectiveness. We will analyze each of them and observe that no single solution is a panacea, but certain combinations of approaches appear to be the most reliable candidates for protection.
A minimal approach to fight against the threats of jailbreaking/rooting is to employ jailbreak/rooting detection mechanisms in banking apps or other high value targets. There are quite a few popular methods of detecting whether the host device is jailbroken or rooted. In general, they involve detecting the existence of files/directories that shouldn’t exist, certain changes in existing files/directories, detecting changes in values returned by low-level functions such as system(), etc. Many apps do employ one or more of these methods. Unfortunately, these methods can be circumvented with varying levels of difficulty and motivated hackers have figured out counter-mechanisms to get around most of them. For example, the attacker can change the names of the folders in question, intercept calls to low-level functions and return values that correspond with non-jailbroken/non-rooted devices. While it is important to have jailbreak detection mechanisms to prevent a hacker from getting in the easy way, they cannot be completely relied upon.
So what other approaches can be employed to protect apps on jailbroken devices?
Hardware-based approach: Banking applications, including user banking credentials and the associated cryptographic keys, can be hosted on a tamper-resistant hardware platform called Secure Element (SE). An SE can provide a good degree of security in general (in fact, it protects proprietary information about the application even when the device is rooted/jailbroken). However, apps on jailbroken devices are still vulnerable to attackers who can instruct the SE to sign and encrypt whatever they want, pretending to be the banking app. Also, the memory space and data transfer speed offered are limited. In addition, the implementation cost and complexity of an SE-based solution is high.
Software-based approach: One example of an exclusively software-based approach is Host Card Emulation (HCE), where banking apps and the associated details are stored in the operating system of the mobile device or a cloud-based SE. In comparison with SE, HCE is a simpler and cheaper technology. However, an attacker can still compromise all details present in banking and other apps on jailbroken devices. Even if techniques such as tokenization are applied to minimize the damage, a clever attacker can still do significant harm. For instance, from a cloud-based SE, the mobile device collects and stores a few limited-use tokens; the attacker can misuse these tokens. Furthermore, HCE lacks standards so the security techniques may not be correctly implemented, leading to deeper consequences. Additionally, the binary app may inadvertently contain unencrypted credit card information, payment history and personally identifiable information (PII) that an attacker can use in social-engineering attacks.
Hybrid approach: A hybrid approach uses both HCE and secure hardware and is called the Trusted Execution Environment (TEE); i.e., HCE + TEE. A mobile device with a TEE is composed of the “Rich OS” consisting of its hardware, OS and applications, and the “Trusted OS” on which only “trusted apps” will be executed using trusted hardware resources. While HCE + TEE is a reasonable middle ground between SE and HCE, there are still some major concerns that need additional treatment. Firstly, there can only be a limited number of TEE zones on a device. A certain amount of memory has to be set aside for each TEE so the more the device is secured, the less it is available for general purpose applications. Thus, not all payment applications are secured using TEE. Furthermore, the HCE part of the technology still retains some of the major drawbacks, including poor implementation with security vulnerabilities and potentially containing PII and other sensitive information which an attacker can access on a rooted/jailbroken device.
The final line of defense is shielding the payment applications themselves. Specifically, application shielding involves various techniques and technologies that harden the application against reverse engineering and other attacks. With this, even the HCE part of the hybrid solution can be protected.
Integrating application shielding, such as that offered by Intertrust’s whiteCryption solution suite, gives holistic protection capabilities to your apps. whiteCryption Code Protection uses a wide variety of advanced techniques, including source code obfuscation, anti-tampering protection, jailbreak/rooting detection, and many others. whiteCryption Secure Key Box (SKB) is a white-box cryptography solution that ensures cryptographic keys are kept secure at all times, even when in use. The whiteCryption application shielding system is already a trusted security solution for protecting apps in high value fields such as finance, health and automobiles.
In summary, the vulnerability of apps on jailbroken devices make it very easy for attackers to steal valuable data, such as payment information. Of the various device hardware and OS defense approaches that exist, a hybrid approach seems the most reasonable, balancing security with functionality. However, even a hybrid approach still contains significant security gaps, especially within the HCE element. This is why application-level protections that work in tandem with device-level protections are essential. Application shielding technologies can be used to harden the attack surfaces of the HCE element.