owasp mobile top 10

Understanding the OWASP Mobile Top 10 Security Risks: Part Three (M8-M10)

Posted On

By Prateek Panda


As mobile applications continue to expand their scope and complexity, the security risk posed to businesses and their customers mounts. Even industries with stringent security requirements are rife with apps that violate the OWASP mobile top 10 recommendations for building secure apps. Our recent test of U.S. financial mobile applications found that 98% had at least one vulnerability and more than 70% contained at least one high-level security flaw. 

This blog post series takes a closer look at the mobile application security risks outlined by OWASP so developers and businesses can better understand these threats and how to counter them. In part one and part two, we delved into OWASP mobile top 10 risks M1–M3 and M4–M7, respectively. In this final post, we examine threats M8–M10.

OWASP Mobile Top 10 Threats: M8–M10

M8: Code Tampering

Code tampering is when hackers alter an app’s code to create a modified or fake version of it. These hacks can be malicious or relatively benign, but in all cases, the modified, non-authorized app will not act in the way the publisher intended.

Why it’s a problem

App developers or publishers need to remain in control of their assets and intellectual property, to protect both their customers and their business. Code tampering is one of the most common risks in the OWASP Mobile Top 10 list. Hackers create cloned versions of an app to use for their own purposes, subverting the publisher’s intentions and reputation. 

Some of the uses of code tampered apps include:

  • Pirated gaming apps skipping the need for payment for certain features
  • Banking or financial apps being tampered with to steal user details to commit fraud
  • Disabling or circumventing security controls
  • Counterfeit apps siphoning advertising revenue which should have gone to the publisher
  • Malicious, repackaged versions of apps that can infiltrate backend servers and IT systems

How apps are vulnerable to code tampering

Once hackers have reverse engineered an app’s code and understand its flow and logic, they have a range of possibilities to inject malicious code that alters the app’s properties and functions. This includes making direct changes to the app’s core binary, method hooking or swizzling, making changes to the resources within the application’s package, and redirecting or replacing system APIs to execute malicious code. This generally occurs on jailbroken or rooted devices, which make it easier for hackers to perform static or dynamic analysis on the app’s code.

What can be done

Since there are many access points and means by which a hacker can reverse engineer and tamper with an app’s code, apps should employ a wide range of anti-tampering security mechanisms. Recommended code tampering controls include:

  • Android rooting and iOS jailbreak detection: Put in place detection controls that include an accurate and complete set of algorithms that will detect a jailbroken or rooted environment.
  • Integrity checking with checksums: Use a sufficiently complex checksum arrangement to ensure that any attempt to alter code or disable a checker will be observed and flagged to the user.
  • Function caller verification: Prevent changes to the intended flow of function calls by adding extra authorization and verification protocols to the app’s code.
  • Anti-method swizzling: Particularly for iOS apps, method swizzling can be used to modify and remap method implementations. Security controls should detect these hacking attempts and execute a defensive action (such as sending a user alert, shutting down, or running in a sandbox mode).
  • Cross-checking cryptographic signatures: Verify cryptographic signatures and keys used in shared cryptographic libraries. 

whiteCryption Code Protection from Intertrust provides these tampering protections and more. Upon tampering attempts, it triggers automated defense actions such as blocking account access, halting command execution, deleting sensitive data, or shutting down the application.

M9: Reverse Engineering

Reverse engineering is the launching pad for most of the attacks on the OWASP Mobile Top 10 Threats list. It involves a hacker downloading an app and then performing analysis on its final core binary with a decompiler or debugger in order to identify its source code, algorithms, libraries, and other elements. It is essentially deconstructing and figuring out how an app works from the starting point of its final form.

Why it’s a problem

When an app is reverse engineered successfully, hackers are able to access a vast array of information that they can either steal and monetize in its own right, or use to launch further attacks on the app. The range of issues reverse-engineering creates for developers and publishers is extensive. It includes:

  • Cryptographic keys and ciphers being revealed
  • Back end server information being accessed
  • Intellectual property (including code and algorithms) being stolen
  • The discovery of vulnerabilities and opportunities for code tampering attacks 
  • Private data being exfiltrated by the hacker
  • The creation of malicious fake apps which can be used to steal data and commit fraud

All of these and many other issues (including other points on the OWASP Top 10 Mobile Threats list) mean that the publisher associated with the app faces considerable reputational damage, fees, and regulatory trouble if it has endangered its user’s data or devices.

How apps are vulnerable to reverse engineering

An app’s attack surface encompasses all of its source code. Attackers can use various tools to perform a cross-functional analysis of the app either statically or during run-time. Language metadata can also be used to gain a better understanding of the app’s binary string. The many means of analyzing an app can also be combined, with the end goal being the re-creation or understanding of its code.

What can be done

Mobile apps are vulnerable to reverse engineering through a variety of attack vectors but this can be countered by using strong code obfuscation and other protective measures. Intertrust’s Code Protection system is an industry-leading app security solution that specializes in protecting apps from reverse engineering through multiple methods, including:

  • Code obfuscation: By inserting dummy blocks or nonsense code, inlining functions, and replacing calls to subroutines with computed jumps, it becomes much more difficult for hackers to decipher the code. 
  • Control flow flattening: Separates all the source code’s blocks and puts them in a linear loop with a switch statement that controls the program flow instead of calling routines directly from other routines. This makes it nearly impossible for a hacker to understand how the app’s code flows.
  • Metadata obfuscation: Metadata, which hackers can use to better understand how an app’s code works, is often contained in the headers of executable files. Code Protection encrypts that metadata, protecting it from static analysis.
  • Binary packing: This describes the encryption of the app’s binary code, meaning a hacker can’t directly use a decompiler on the app. This prevents static analysis as the code is only decrypted during run-time.
  • Anti-debugging: Hackers use debuggers to disassemble and decompile code, which is essential in reverse engineering. Intertrust’s Code Protection can detect when someone is trying to use the app in a debugger, allowing it to take a defensive action.

M10: Extraneous Functionality

Rounding out the OWASP Top 10 list of mobile threats is a flaw that can often be benign or overlooked, but also has the potential to give a hacker easy access to dangerous abilities within the application. Extraneous functionality refers to elements such as switches, test code, log files, backdoors, or vulnerable admin end-points that get left behind or are poorly protected following development or an update.

Why it’s a problem

Depending on the nature of the extraneous functionality, the issues it can cause for the app owner vary. Some of the most serious results can be hackers gaining unauthorized access to the system’s back end, the ability to execute admin-level functions, or other access to functionality that would not be available to normal app users.

How apps are vulnerable to extraneous functionality

Since it’s not an intentional part of the app, extraneous functionality can be an issue as software engineers may not be searching for it when looking for bugs. To find these hidden vulnerabilities and exploit them, attackers will first analyze an app to find what functionalities there are. This gives them an idea of what is possible on the backend. They can also analyze log and configuration files to see if there are any endpoints or functions which have been left exposed. 

What can be done

There are a number of checks for backdoors or extraneous functionality that an app developer should make before releasing an application or publishing an update to it. These include:

  • Having a trusted third party manually revise the code
  • Examining and documenting all API endpoints
  • Revising information and descriptions contained in log statements
  • Removing all test code from final releases
  • Checking configuration settings to ensure no easy access to extra functionality is inadvertently granted

Conclusion

The OWASP Mobile Top 10 threats facing app developers and publishers are clear. For businesses especially, the risks need to be addressed and countered to prevent a number of potentially disastrous consequences. 

The damage that can be done is borne out by some serious statistics: 

With the rise of smartphones and app usage, addressing application security is an unavoidable necessity to guarantee business and revenue security. The best way to protect apps from the OWASP Mobile Top 10 threats is by using a security solution that employs a variety of in-app defense strategies. These must include protection from reverse engineering, code tampering, insecure key storage, and vulnerable coding.

Intertrust has developed an extremely resilient application shielding system that closes off attack vectors and directly counters the biggest risks of the OWASP Top 10. To find out more about our whiteCryption technology, read more here or contact our team.

Prateek Panda

About Prateek Panda

Prateek Panda is Director of Marketing at Intertrust Technologies and leads global marketing for Intertrust’s application shielding and device identity solutions. His expertise in product marketing and product management stem from his experience as the founder of a cybersecurity company with products in the mobile application security space.