November 4, 2014 By Patrick Kehoe 3 min read

Most organizations engage in a broad range of application security activities across the software development life cycle, such as threat modeling, architectural risk assessment, source code review, penetration testing and application monitoring. These are important controls, but they aren’t sufficient in a mobile environment. Even if all the controls are implemented perfectly and you believe your code is free of vulnerabilities, a mobile app without protected binary code is at risk for a hack and could jeopardize the impact of all your other security work.

The following is a look at a typical hack or app break-in, and the challenges of common misconceptions about app store security.

Isn’t My App Encrypted to Prevent a Hack?

Yes, apps from Apple’s App Store are, in fact, encrypted. Unfortunately, it takes just a few minutes to decrypt an application using freely available tools. This is typically the first step in the break-in for an iOS app.

So, What’s the Big Deal if Someone Gains Access to My App?

Downloaded Android apps (or decrypted iOS apps) provide cybercriminals with access to the app in a binary code format. Apps with unprotected binary code are at risk because it is quite easy for cybercriminals to reverse-engineer binary code back to source code. Imagine your “flawless” app as a highly secure castle. By leaving the binary code unprotected, it’s like providing unfettered access to the information inside, including the blueprint for the castle and all its security controls.

It is also quite easy for cybercriminals to reuse or copycat an application and submit the hacked version to an app store under their own branding as a nearly identical copy of the legitimate application. Columbia University research recently revealed that nearly one-quarter of all Google Play apps are duplicates.

Download the complete 2016 report on the state of application security from IBM Partner Arxan

Isn’t It Really Hard for Cybercriminals to Hijack My Well-Written Application and Take Control to Perform Nefarious Activities?

Unfortunately, no — it’s not that hard to hack an app this way. For example, through method swizzling attacks, cybercriminals can attack critical-class methods of an application to intercept application programming interface (API) calls and execute authorized code without leaving a trace, with the code reverting back to its original form. Essentially, it involves modifying the mapping so that calling API “A” will actually invoke API “B” — and API “B” can store credit card information on another server, capture customer information and be configured to perform any number of unintended and undesirable activities.

You can see examples of these application hacks brought to life via this series of short videos. Sample tools used to perform these attacks are listed in the graphic below.

It’s Time to Secure Your Apps at Run Time

The risk of this typical app break-in is so real that OWASP, Gartner, Forrester and other leading security advisers are stressing the importance of protecting applications, particularly application binary code.

Gartner, for example, recently advised chief information security officers to “make application self-protection a new investment priority, ahead of perimeter and infrastructure protection” and that “every app needs to be self-aware and self-protecting.” Gartner has also identified self-protection as a key technology trend for 2015.

OWASP also sees the importance of protecting applications and their binary code by identifying a “lack of binary protection” as one of its top 10 mobile risks.

Protection against typical app break-ins and even more advanced break-ins can be realized through application hardening and run-time protection. Hardening and run-time protection can be achieved with no impact to your source code via an automated insertion of guards into your binary code. When implemented properly, layers of guards are deployed so that both the application and the guards are protected and there is no single point of failure.

Detailed steps you can take to harden and protect apps at run time are readily available and were reviewed in detail in our recent webinar, which is available on-demand. In this session, we explore typical break-ins in more detail and teach you about the types of guards you can use to protect your apps.

If you think like a cybercriminal and protect your applications against common mobile application attack vectors, chances are that your organization won’t be the next one making headlines by being linked to a significant app break-in.

More from Application Security

What’s up India? PixPirate is back and spreading via WhatsApp

8 min read - This blog post is the continuation of a previous blog regarding PixPirate malware. If you haven’t read the initial post, please take a couple of minutes to get caught up before diving into this content. PixPirate malware consists of two components: a downloader application and a droppee application, and both are custom-made and operated by the same fraudster group. Although the traditional role of a downloader is to install the droppee on the victim device, with PixPirate, the downloader also…

PixPirate: The Brazilian financial malware you can’t see

10 min read - Malicious software always aims to stay hidden, making itself invisible so the victims can’t detect it. The constantly mutating PixPirate malware has taken that strategy to a new extreme. PixPirate is a sophisticated financial remote access trojan (RAT) malware that heavily utilizes anti-research techniques. This malware’s infection vector is based on two malicious apps: a downloader and a droppee. Operating together, these two apps communicate with each other to execute the fraud. So far, IBM Trusteer researchers have observed this…

From federation to fabric: IAM’s evolution

15 min read - In the modern day, we’ve come to expect that our various applications can share our identity information with one another. Most of our core systems federate seamlessly and bi-directionally. This means that you can quite easily register and log in to a given service with the user account from another service or even invert that process (technically possible, not always advisable). But what is the next step in our evolution towards greater interoperability between our applications, services and systems?Identity and…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today