Think Your Mobile App is Hack Proof Think Again

In today’s mobile app economy, time to market and quality are critical to stay competitive. Developers race against the clock to create amazing apps, and considerable time is spent to test it again and again; agile and automation plays a big part into this. The goal is a release that is user friendly and resilient as defect-free as possible, offering a product that deepens customer engagement and drives new business revenue. The process is repeated – until the next security hack. 

In the worst cases, a hack exposes a company to serious risks, and the impact for businesses and users can be devastating. Imagine having your mobile health app reprogrammed to instruct you to deliver a lethal dose of medication. Or your mobile finance app draining your bank account by redirecting funds.

Even with so much time spent on app development, ensuring app security still too often remains an afterthought. Unlike web applications, mobile software is uniquely exposed to various binary risks, since by its nature, application code must be released "out into the wild". In other words, attackers are free to directly access, compromise, and exploit an app’s binary code. 

Today, development of mobile apps moves faster than the security needed to protect them. A majority of applications are still distributed without any form of binary protection. This provides susceptibility to malware, code modification or other forms of tampering that compromises application integrity. Here are some ways hackers can tamper with your app, via the binary code: 

This is the first category of binary-based vulnerability exploits, whereby hackers conduct unauthorized code modifications or insert malicious code into an application’s binaries. Code modification or code injection tactics can include:

Binary Patching 

Here a hacker modifies an app’s binary code to change its behavior by augmenting its execution path. 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. 

Repackaging 

A hacker can inject malicious code into the binary, and then either repackage the mobile apps and publish it as a new (supposedly legitimate) app, distributed under the guise of a patch or a crack, or surreptitiously (re)install it on an unsuspecting user’s device.

For a hacker to modify an iOS app, they must first defeat Apple’s code encryption and code signing technology included with each app in the Apple App Store, which could be done easily with downloaded tools, development toolchain and a jailbroken device. Then, the app can be modified and hosted on a third-party site available for download. Anyone with an iOS device can download and execute these compromised apps from these third-party sites. 

Majority of iOS apps are developed still with Objective-C, which supports the dynamic redirection of method invocations from one method to another. This handy feature is called method swizzling, and is typically used when an application needs to perform method substitution or method extension. 

A hacker can leverage this feature to redirect Objective-C method calls to malicious code that can be provided via an external library. In turn, the runtime invokes a malicious form of the method rather than the original safe one. The end result is a rogue application that can perform a drive-by attack to compromise the target mobile app (in order to lift credentials, expose personal and/or corporate data, redirect traffic, etc.)

Reverse Engineering or Code Analysis 

This is the second category of exploitable binary vulnerabilities, whereby mobile app binaries can be analyzed statically and dynamically. Using intelligence gathered from code analysis tools and activities, the binaries can be reverse-engineered and valuable code (including source code), sensitive data, or proprietary IP can be lifted out of the application and re-used or re-packaged. Reverse engineering or code analysis tactics include:

Android APK Reverse Engineering 

In the case of Android apps, hackers can easily leverage an app’s binary code, via a download on Google Play, to recreate its original source code. The process entails converting the Android app into its Java bytecode equivalent, using a free tool. The tools provides a set of Java-class files stored which can be used to reverse engineer the app’s code, in a remarkably accurate recreation of the original code. 

Here, hackers often use freely available tools to provide quick analysis of an unprotected app. A hacker is then able to easily counterfeit an app or steal sensitive information embedded in the app about its producer. This attack is often used as a springboard for other attacks, such a binary patching, code injection or method swizzling to conduct fraud or steal a user’s identity. 

String tables represent the “low-hanging fruit” of information gathering attacks. So much of an application can be discovered, both the client app and the server side that it talks to. For example, all your web entry points, something hard coded keys or credentials, or just methods that you call, are mostly visible as literal string objects as static, and more so at runtime. A hacker will perform basis string analysis using the universally available strings utility to inspect the app’s interval string table to inspect for clues as to what to inspect or attack next. 

This enables a hacker to identify sensitive algorithms, identify the nature of these algorithms, discover hardcoded passwords, understand internal database designs, and much more. They can leverage such information as a springboard for reverse engineering tactics. 

Understanding application internal structures and methods via Class Dumps

Another example, the classdump tool can be used to get a detailed understanding of the app’s symbols, class interfaces, and associated method prototypes. 

This type of attack is very useful on its own as a form of reverse engineering. It is often used as a stepping stone to more sophisticated attacks involving method swizzling by leading to method interception by API hooking and other unauthorized app behavior modifications. The hacker will then typically conduct fraud or identity theft against the victim.  

With the prevalence of avenues and ease in which hackers can exploit an app via the binary code, developers need to rewire their thinking. In a world where the next hack is a matter of “when will it happen” rather than “if it will happen,” developers need to focus on implementing self-protection security controls within the app as much as the quality of the app itself. 

Many developers use traditional techniques to confirm that code is secure, via vulnerability tests on their code and remediation of areas with conventional risk. However, unless the binary code is hardened, via the an automated insertion of “guards,” the application is still vulnerable to prevailing risks. And with all the emulation, dynamic loading/linking, virtualization and container technologies, your applications are completely transparent at runtime for hackers to inspect.

Today, code can be hardened with no impact to source code. When implemented properly, the result is secure binary code, protecting the application from infiltration from hackers. Security remains a key area for developers to consider. After all, what good is a high quality app if it is vulnerable to exploitation by hackers?