Are you afraid that after everything you’ve done to build your app that it might not be hack proof?
A hack can expose a company to serious risks and the negative impact can be devastating. Imagine having your mobile health app reprogrammed to instruct you to deliver a lethal dose of medication. If it isn’t hack proof, your mobile finance app could be draining bank accounts by redirecting funds. Does a link from your app go to a website that has been hacked? If so, the app store will suspend and possibly terminate your app license. You can learn more about that here, but this article discusses issues you might have with the app itself.
Unlike web applications, mobile software is uniquely exposed to various binary risks. And today, the development of mobile apps often 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 can compromise its integrity.
Here are some ways hackers can tamper with your app, via the binary code:
Code Modification or Code Injection
This is the first category of binary-based vulnerability exploits. Hackers conduct unauthorized code modifications or insert malicious code into an application’s binaries. Code modification or code injection tactics can include binary patching, repackaging and swizzling.
Binary Patching
Here hackers could modify an app’s binary code to change its behavior by augmenting its execution path. They could disable security controls, giving them the ability to bypass business rules, licensing restrictions, purchasing requirements, and in-app ad displays. Then they could distribute it as a patch, a 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 (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. This 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.
Swizzle with Behavioral Change
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. It is typically used when an application needs to perform method substitutions or method extensions.
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.)
Have I got your attention yet? App Developers must protect themselves from binary risks. Part Two of this article will discuss the second category of exploitable binary vulnerabilities. You can read about them here.
Thanks to App Developer for help in writing this article.
Leave a Reply