New to CAPEC? Start Here
Home > CAPEC List > CAPEC-661: Root/Jailbreak Detection Evasion via Debugging (Version 3.9)  

CAPEC-661: Root/Jailbreak Detection Evasion via Debugging

Attack Pattern ID: 661
Abstraction: Detailed
View customized information:
+ Description
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.
+ Likelihood Of Attack

Medium

+ Typical Severity

Very High

+ Relationships
Section HelpThis table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.
NatureTypeIDName
ChildOfStandard Attack PatternStandard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.121Exploit Non-Production Interfaces
CanPrecedeStandard Attack PatternStandard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.68Subvert Code-signing Facilities
CanPrecedeDetailed Attack PatternDetailed Attack Pattern - A detailed level attack pattern in CAPEC provides a low level of detail, typically leveraging a specific technique and targeting a specific technology, and expresses a complete execution flow. Detailed attack patterns are more specific than meta attack patterns and standard attack patterns and often require a specific protection mechanism to mitigate actual attacks. A detailed level attack pattern often will leverage a number of different standard level attack patterns chained together to accomplish a goal.660Root/Jailbreak Detection Evasion via Hooking
Section HelpThis table shows the views that this attack pattern belongs to and top level categories within that view.
+ Execution Flow
Explore
  1. 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).

    Techniques
    Search application stores for mobile applications worth exploiting
Experiment
  1. 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.

    Techniques
    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.
  2. Remove application signature verification methods: Remove signature verification methods from the decrypted code and resign the application with a self-signed certificate.

Exploit
  1. 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.

    Techniques
    Optional: Hook code into the target application.
+ Prerequisites
A debugger must be able to be inserted into the targeted application.
+ Skills Required
[Level: High]
Knowledge about Root/Jailbreak detection and evasion techniques.
[Level: Medium]
Knowledge about runtime debugging.
+ Resources Required
The adversary must have a Rooted/Jailbroken mobile device with debugging capabilities.
+ Consequences
Section HelpThis table specifies different individual consequences associated with the attack pattern. The Scope identifies the security property that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in their attack. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a pattern will be used to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Integrity
Authorization
Execute Unauthorized Commands
Confidentiality
Access Control
Authorization
Gain Privileges
Confidentiality
Access Control
Read Data
+ Mitigations
Instantiate checks within the application code that ensures debuggers are not attached.
+ Example Instances
An adversary targets an iOS banking application in an attempt to compromise sensitive user data. The adversary launches the application with the iOS debugger and sets a breakpoint at the program entry point, after the application's signature has been verified. Next, the adversary dumps the memory region that contains the decrypted code from the address space of the binary. The 'Restrict' flag is then stripped from the application and the adversary resigns the application with a self-signed certificate. The application is now executed without the 'Restrict' flag, while trusting the self-signed certificate to be legitimate. However, the adversary is now able to evaded Jailbreak detection via code hooking or other methods and can glean user credentials and/or transaction details.
+ References
[REF-625] San-Tsai Sun, Andrea Cuadros and Konstantin Beznosov. "Android Rooting: Methods, Detection, and Evasion". Technische Universität Braunschweig. 2019-06-17. <http://lersse-dl.ece.ubc.ca/record/310/files/p3.pdf?subformat=pdfa>. URL validated: 2020-12-15.
[REF-626] Jose Lopes. "Who owns your runtime?". Nettitude Labs. 2015-10-12. <https://labs.nettitude.com/blog/ios-and-android-runtime-and-anti-debugging-protections/#hooking>. URL validated: 2020-12-15.
[REF-627] Suresh Khutale. "Android Root Detection Bypass by Reverse Engineering APK". InfoSec Institute. 2018-03-06. <https://resources.infosecinstitute.com/topic/android-root-detection-bypass-reverse-engineering-apk/>. URL validated: 2020-12-15.
[REF-628] Manuel Egele, Christopher Kruegel, Engin Kirda and Giovanni Vigna. "PiOS: Detecting Privacy Leaks in iOS Applications". 2011-02-09. <https://www.ndss-symposium.org/wp-content/uploads/2017/09/egel.pdf>. URL validated: 2020-12-16.
+ Content History
Submissions
Submission DateSubmitterOrganization
2020-12-17
(Version 3.4)
CAPEC Content TeamThe MITRE Corporation
More information is available — Please select a different filter.
Page Last Updated or Reviewed: December 17, 2020