| Name |
Root/Jailbreak Detection Evasion via Debugging |
|
| Likelyhood of attack |
Typical severity |
| Medium |
Very High |
|
| Summary |
An adversary inserts a debugger into the program entry point of a mobile application to modify the application binary, with the goal of evading Root/Jailbreak detection. Mobile device users often Root/Jailbreak their devices in order to gain administrative control over the mobile operating system and/or to install third-party mobile applications that are not provided by authorized application stores (e.g. Google Play Store and Apple App Store). Rooting/Jailbreaking a mobile device also provides users with access to system debuggers and disassemblers, which can be leveraged to exploit applications by dumping the application's memory at runtime in order to remove or bypass signature verification methods. This further allows the adversary to evade Root/Jailbreak detection mechanisms, which can result in execution of administrative commands, obtaining confidential data, impersonating legitimate users of the application, and more. |
| Prerequisites |
A debugger must be able to be inserted into the targeted application. |
| Execution Flow |
| Step |
Phase |
Description |
Techniques |
| 1 |
Explore |
[Identify application with attack potential] The adversary searches for and identifies a mobile application that could be exploited for malicious purposes (e.g. banking, voting, or medical applications). |
- Search application stores for mobile applications worth exploiting
|
| 2 |
Experiment |
[Debug the target application] The adversary inserts the debugger into the program entry point of the mobile application, after the application's signature has been identified, to dump its memory contents. |
- Insert the debugger at the mobile application's program entry point, after the application's signature has been identified.
- Dump the memory region containing the now decrypted code from the address space of the binary.
|
| 3 |
Experiment |
[Remove application signature verification methods] Remove signature verification methods from the decrypted code and resign the application with a self-signed certificate. |
|
| 4 |
Exploit |
[Execute the application and evade Root/Jailbreak detection methods] The application executes with the self-signed certificate, while believing it contains a trusted certificate. This now allows the adversary to evade Root/Jailbreak detection via code hooking or other methods. |
- Optional: Hook code into the target application.
|
|
| Solutions | Instantiate checks within the application code that ensures debuggers are not attached. |
| Related Weaknesses |
|
CWE ID
|
Description
|
| CWE-489 |
Active Debug Code |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-68 |
Many languages use code signing facilities to vouch for code's identity and to thus tie code to its assigned privileges within an environment. Subverting this mechanism can be instrumental in an attacker escalating privilege. Any means of subverting the way that a virtual machine enforces code signing classifies for this style of attack. |
| CAPEC-121 |
An adversary exploits a sample, demonstration, test, or debug interface that is unintentionally enabled on a production system, with the goal of gleaning information or leveraging functionality that would otherwise be unavailable. Non-production interfaces are insecure by default and should not be resident on production systems, since they may reveal sensitive information or functionality that should not be known to end-users. However, such interfaces may be unintentionally left enabled on a production system due to configuration errors, supply chain mismanagement, or other pre-deployment activities.
Ultimately, failure to properly disable non-production interfaces, in a production environment, may expose a great deal of diagnostic information or functionality to an adversary, which can be utilized to further refine their attack. Moreover, many non-production interfaces do not have adequate security controls or may not have undergone rigorous testing since they were not intended for use in production environments. As such, they may contain many flaws and vulnerabilities that could allow an adversary to severely disrupt a target. |
| CAPEC-660 |
An adversary forces a non-restricted mobile application to load arbitrary code or code files, via Hooking, with the goal of evading Root/Jailbreak detection. Mobile device users often Root/Jailbreak their devices in order to gain administrative control over the mobile operating system and/or to install third-party mobile applications that are not provided by authorized application stores (e.g. Google Play Store and Apple App Store). Adversaries may further leverage these capabilities to escalate privileges or bypass access control on legitimate applications. Although many mobile applications check if a mobile device is Rooted/Jailbroken prior to authorized use of the application, adversaries may be able to "hook" code in order to circumvent these checks. Successfully evading Root/Jailbreak detection allows an adversary to execute administrative commands, obtain confidential data, impersonate legitimate users of the application, and more. |
|