M8: Code Tampering

Threat Agents

Application Specific

Typically, an attacker will exploit code modification via malicious forms of the apps hosted in third-party app stores. The attacker may also trick the user into installing the app via phishing attacks.

Attack Vectors

Exploitability EASY

Typically, an attacker will do the following things to exploit this category:

  • Make direct binary changes to the application package’s core binary
  • Make direct binary changes to the resources within the application’s package
  • Redirect or replace system APIs to intercept and execute foreign code that is malicious

Security Weakness

Prevalence COMMON
Detectability AVERAGE

Modified forms of applications are surprisingly more common than you think. There is an entire security industry built around detecting and removing unauthorized versions of mobile apps within app stores. Depending upon the approach taken to solving the problem of detecting code modification, organizations can have limited to highly successful ways of detecting unauthorized versions of code in the wild. This category covers binary patching, local resource modification, method hooking, method swizzling, and dynamic memory modification.

Once the application is delivered to the mobile device, the code and data resources are resident there. An attacker can either directly modify the code, change the contents of memory dynamically, change or replace the system APIs that the application uses, or modify the application’s data and resources. This can provide the attacker a direct method of subverting the intended use of the software for personal or monetary gain.

Technical Impacts

Impact SEVERE

The impact from code modification can be wide ranging in nature, depending upon the nature of the modification itself. Typical types of impacts include the following:

  • Unauthorized new features;
  • Identity theft; or
  • Fraud.

Business Impacts

Application / Business Specific

The business impact from code modification typically results in the following:

  • Revenue loss due to piracy; or
  • Reputational damage.

Am I Vulnerable To ‘Code Tampering’?

Technically, all mobile code is vulnerable to code tampering. Mobile code runs within an environment that is not under the control of the organization producing the code. At the same time, there are plenty of different ways of altering the environment in which that code runs. These changes allow an adversary to tinker with the code and modify it at will.

Although mobile code is inherently vulnerable, it is important to ask yourself if it is worth detecting and trying to prevent unauthorized code modification. Apps written for certain business verticals (gaming for example) are much more vulnerable to the impacts of code modification than others (hospitality for example). As such, it is critical to consider the business impact before deciding whether or not to address this risk.

How Do I Prevent ‘Code Tampering’?

The mobile app must be able to detect at runtime that code has been added or changed from what it knows about its integrity at compile time. The app must be able to react appropriately at runtime to a code integrity violation.

The remediation strategies for this type of risk is outlined in more technical detail within the OWASP Reverse Engineering and Code Modification Prevention Project.

Android Root Detection Typically, an app that has been modified will execute within a Jailbroken or rooted environment. As such, it is reasonable to try and detect these types of compromised environments at runtime and react accordingly (report to the server or shutdown). There are a few common ways to detect a rooted Android device: Check for test-keys

  • Check to see if build.prop includes the line ro.build.tags=test-keys indicating a developer build or unofficial ROM

Check for OTA certificates

  • Check to see if the file /etc/security/otacerts.zip exists

Check for several known rooted apk’s

  • com.noshufou.android.su
  • com.thirdparty.superuser
  • eu.chainfire.supersu
  • com.koushikdutta.superuser

Check for SU binaries

  • /system/bin/su
  • /system/xbin/su
  • /sbin/su
  • /system/su
  • /system/bin/.ext/.su

Attempt SU command directly

  • Attempt the to run the command su and check the id of the current user, if it returns 0 then the su command has been successful

iOS Jailbreak Detection

Example Attack Scenarios

There are a number of counterfeit applications that are available across the app stores. Some of these contain malware payloads. Many of the modified apps contain modified forms of the original core binary and associated resources. The attacker re-packages these as a new application and released them into third-party stores.

Scenario #1:

Games are a particularly popular target to attack using this method. The attacker will attract people that are not interested in paying for any freemium features of the game. Within the code, the attacker short-circuits conditional jumps that detect whether an in-application purchase is successful. This bypass allows the victim to attain game artifacts or new abilities without paying for them. The attacker has also inserted spyware that will steal the identity of the user.

Scenario #2:

Banking apps are another popular target to attack. These apps typically process sensitive information that will be useful to an attacker. An attacker could create a counterfeit version of the app that transmits the user’s personally identifiable information (PII) along with username/password to a third-party site. This is reminiscent of the desktop equivalent of Zeus malware. This typically results in fraud against the bank.

References

“Adversaries have hacked 78 percent of the top 100 paid Android and iOS apps in 2013.”

“86 percent of applications tested lacked binary hardening, leaving applications vulnerable to information disclosure, buffer overflows and poor performance. To ensure security throughout the life cycle of the application, it is essential to build in the best security practices from conception.”

“Our results show that 86.0% of them (Android Malware) repackage legitimate apps to include malicious payloads; 36.7% contain platform-level exploits to escalate privilege; 93.0% exhibit the bot-like capability.”

“While Apple is known for screening apps before they are allowed to sprout up in its walled garden, clearly fake apps do get in. Once they do, getting them out depends on developers who raise a fuss.”

“It’s not uncommon to search the Google Play app store and find a number of knock-off or “fake” apps aiming to trick unsuspecting searchers into downloading them over the real thing.”

“The site offers apps for free that would otherwise cost money, including big-name titles.”

“For critical applications, such as transactional ones and sensitive enterprise applications, hardening should be used.”

  • [9] Gartner report: Emerging Technology Analysis: Mobile Application Shielding, March 26th, 2013:

“As more regulated and sensitive data applications move to mobile platforms the need to increase data protection increases. Mobile application shielding presents the opportunity to security providers to offer higher data protection standards to mobile platforms that exceed mobile OS security.”

  • [10] Gartner report: Proliferating Mobile Transaction Attack Vectors and What to Do About Them, March 1st, 2013:

“Use mobile application security testing services and self-defending application utilities to help prevent hacking attempts.”

  • [11] Gartner report: Select a Secure Mobile Wallet for Proximity, March 1st, 2013:

“Application hardening can fortify sensitive business code against hacking attempts, such as reverse engineering”

  • [12] Forrester paper: Choose The Right Mobile Development Solutions For Your Organization, May 6th 2013:

“5 Key Protections: Data Protection, App Compliance, App-Level Threat Defense, Security Policy Enforcement, App Integrity”

“In most cases, the 2,140 copycat developers that were found reassembled the apps almost identically, adding new advertising SDKs to siphon profits away from the original developers.

“But one of his more worrying findings came from disassembling the apps themselves … what he found was hardcoded development credentials within the code. An attacker could gain access to the development infrastructure of the bank and infest the application with malware causing a massive infection for all of the application’s users.”

“Number of mobile malware samples is growing at a rapid clip, increasing by 20-fold in 2013… It is trivial for an attacker to hijack a legitimate Android application, inject malware into it and redistribute it for consumption. There are now binder kits available that will allow an attacker to automatically inject malware into an existing application”

Watch Star