We live in a mobile, personal world, where more than 1.5 billion new mobile phones ship each year. Businesses that are most efficiently adapting to today’s “app economy” are the most successful at deepening customer engagement and driving new revenues in this ever-changing world. Where business opportunities abound, opportunities for “black hats” that conduct illicit and malicious activity abound as well.
Mobile app hacking is becoming easier and faster than ever before. Let’s explore why:
- It’s fast: Industry research found that in 84 percent of cases, the initial compromise took “just minutes” to complete.
- It’s relatively easy: There are automated tools readily available in the market to support hacking, and many of them are available for free!
- Mobile apps are “low-hanging fruit”: In contrast to centralized Web environments, mobile apps live “in the wild,” on a distributed, fragmented and unregulated mobile device ecosystem. Unprotected binary code in mobile apps can be directly accessed, examined, modified and exploited by attackers.
Hackers are increasingly aiming at binary code targets to launch attacks on high-value mobile applications across all platforms. For those of you who may not be familiar, binary code is the code that machines read to execute an application — it’s what you download when you access mobile apps from an app store like Google Play.
Exploitable Binary-based Vulnerabilities
Well-equipped hackers seek to exploit two categories of binary-based vulnerabilities to compromise apps:
Code Modification or Code Injection:
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 threat scenarios can include:
- A hacker or hostile user, modifying 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.
- A hacker injecting malicious code into the binary, and then either repackaging the mobile apps and publishing it as a new (supposedly legitimate) app, distributed under the guise of a patch or a crack, or surreptitiously (re)installing it on an unsuspecting user’s device.
- A rogue application performing a drive-by attack (via the run-time method known as swizzling, or function/API hooking) 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 threat scenarios may include:
- A hacker analyzing or reverse-engineering the binary, and identifying or exposing sensitive information (keys, credentials, data) or vulnerabilities and flaws for broader exploitation.
- A hacker lifting or exposing proprietary intellectual property out of the application binary to develop counterfeit applications.
- A hacker reusing and “copy-catting” an application, and submitting it to an app store under his or her own branding (as a nearly identical copy of the legitimate application).
You can see examples of these hacks “brought to life” on YouTube and a summary of Binary Exploits is provided in our graphic below. Whether your organization licenses mobile apps or extends your customer experience to mobile technology, the norm is that hackers are able to trivially invade, infect and/or counterfeit your mobile apps. Consider the following:
||Eight of the top 10 apps in public app stores have been hacked, according to Arxan State of Security in the App Economy Research, Volume 2, 2013. This means that anyone developing B2C apps shouldn’t assume that mobile app store-provided security measures are sufficient. Often these security measures rely on underlying assumptions, such as the lack of jailbroken conditions on the mobile device — an unsafe and impractical assumption today.
||In the case of enterprise-internal apps (B2E), conventional IT security measures such as mobile device management (MDM) and application policy wrappers can be valuable tools for device management and IT policy controls for corporate data and application usage, but they aren’t designed to protect against application-level hacking attacks and exploits.
Scroll to view full table
Time to Secure Your Mobile App
With so much of your organizational productivity riding on the reliable execution of your apps, and such a small a barrier for hackers to overcome superficial threat protection schemes, you could face significant risk unless you step up the protection of your application. It’s time to build trust in apps not just around them.
Application Hardening and Run-Time Protection are mission-critical security capabilities, required to proactively defend, detect and react to attempted app compromises. Both can be achieved with no impact to source code, via an automated insertion of “guards” into the binary code. When implemented properly, layers of guards are deployed so that both the application and the guards are protected, and there’s no single point of failure. Steps one can take to harden and protect apps at run-time are readily available.
Recent history shows that despite our best efforts, the “plumbing” of servers, networks and end-points that run our apps can easily be breached — so isn’t it high-time to focus on the application layer, as well?
UPDATE, 5/3/18, 3:50 AM EDT: Security Intelligence editors have updated this post to include more recent research.