If this threat is related to a published CVE, provide one or more CVE numbers.
Possible Countermeasures:
Follow secure coding guidelines
Protect application binary from code tampering attacks and malware insertion, by ensuring following security controls are built into the applications -
a. Ensure binary code of the software application has not been modified by computing (during protection time) and verifying the checksum (during runtime)
b. Swizzle detection controls to ensure the Objective-C runtime will not invoke the adversary’s malicious form of the method rather than the original and safe one
c. Debugger Detection or Anti-Debug controls to detect whether the application process is running in debugger
d. Jailbreak / Root Detection controls to detect whether the application is running on a jailbroken device
e. Hook detection detection controls to detect whether an attacker is attempting to override a user-defined function in the application
f. Android Root Detection controls to detect whether the application is running on a rooted device
g. Software Diversification and Randomization techniques to eliminate BORE (Break Once Run Everywhere) attack tools
h. Resource verification control to verify resource files or shared library in the Android APK, at runtime, have not been altered or tampered
Leverage vulnerability/penetration testing and ensure that known risks – including those identified in the OWASP mobile top 10 list, in particular, are addressed
References:
Additional Information:
Hackers are increasingly targeting binary code to launch attacks on high-value mobile applications. A few easy steps and widely available (and often free) tools make it easy for adversaries to directly access, compromise, and exploit application’s code -
a. Analyze or reverse-engineer the binary, and identify or expose sensitive information (keys, credentials, data) or vulnerabilities and flaws for broader exploitation
b. Lift or expose proprietary intellectual property out of the application binary to develop counterfeit applications
c. Modify the binary to change its behavior. For example, disabling security controls, bypassing business rules, licensing restrictions, purchasing requirements or ad displays in the mobile app — and potentially distributing it as a patch, crack or even as a new application
d. Inject malicious code into the binary, and then either repackage the apps and publish it as a new (supposedly legitimate) app, distribute under the guise of a patch or a crack, or surreptitiously (re)install it on an unsuspecting user’s device
On behalf of Prashanth Thandavamurthy of Arxan Technologies, Inc.
New Threat
Threat Category: Application: Vulnerable Application/Malicious or privacy-invasive application
Threat: Installing malicious code or modifying program instructions to cause the program to perform unauthorized operations.
Threat Origin: OWASP Mobile Top 10 2016 - M9
https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10
Exploit Example:
https://www.owasp.org/index.php/Technical_Risks_of_Reverse_Engineering_and_Unauthorized_Code_Modification
https://www.owasp.org/images/b/b9/OWASP_Mobile_App_Hacking_(AppSecUSA_2014)_Workshop_Content.pdf
https://arxan.wistia.com/medias/cv1rh3lpqf
https://arxan.wistia.com/medias/iubm2r6al8
CVE Example:
Possible Countermeasures:
References:
Additional Information: Hackers are increasingly targeting binary code to launch attacks on high-value mobile applications. A few easy steps and widely available (and often free) tools make it easy for adversaries to directly access, compromise, and exploit application’s code -
a. Analyze or reverse-engineer the binary, and identify or expose sensitive information (keys, credentials, data) or vulnerabilities and flaws for broader exploitation
b. Lift or expose proprietary intellectual property out of the application binary to develop counterfeit applications
c. Modify the binary to change its behavior. For example, disabling security controls, bypassing business rules, licensing restrictions, purchasing requirements or ad displays in the mobile app — and potentially distributing it as a patch, crack or even as a new application
d. Inject malicious code into the binary, and then either repackage the apps and publish it as a new (supposedly legitimate) app, distribute under the guise of a patch or a crack, or surreptitiously (re)install it on an unsuspecting user’s device