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, such as user credentials from a banking app.
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, 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 in a jailbroken or rooted phone?
Users jailbreak/root their phones all the time to get past the operating system 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.
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, a malicious app 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.
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 information at stake fall 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 that can work against such attacks, with varying degrees of effectiveness. We will analyze each of them and observe that no one solution is a panacea, but certain combinations of approaches appear to be reliable candidates.
A minimal approach to fight against such threats of jailbreaking/rooting is to employ jailbreak/rooting detection mechanisms in the banking apps. 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. And many apps do employ one or more of these methods. Although these methods can be circumvented with varying levels of difficulty, 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 the low-level functions and return values that correspond with non-jailbroken/non-rooted devices, etc. While it is important to have jailbreak detection mechanisms to let the hacker in the easy way, they cannot be completely relied upon.
So what other approaches can be employed?
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). While an SE can provide a good degree of security in general (in fact, it protects proprietary information about the application even when rooted/jailbroken), in a rooted/jailbroken phone, an attacker 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, cost implementation complexity of an SE-based solution is significantly high.
Software-based approach: 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 pilfer all details present in a banking application on a rooted/jailbroken phone. Even if techniques such as tokenization are applied to minimize the damage, a clever attacker can still do a lot of 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. Mistakenly, the binary app may 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 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.
A banking app in a jailbroken/rooted phone, still secured using white-box cryptography/app shielding techniques.
The final resort of defense is shielding the payment applications. Specifically, shielding involves various technologies such as white-box cryptography, secure code obfuscation, anti-debug protections and source code integrity protection. With this, even the HCE part of the hybrid solution can be protected.
In summary, rooted/jailbroken devices make it very easy for attackers to pilfer valuable payment information. There exist various defense approaches, one more effective than the other. The hybrid approach seems the most reasonable one, achieving balance between security and functionality. However, the HCE part of the technology still has its own attack surfaces which can be strengthened using application shielding technologies.