On a fundamental level, smartphones are not very different from desktop computers and laptops. A customer’s smartphone might run software from both reputable and less-reputable sources, and similar to a computer they might not have received any security updates in a long time. Hence, it is a safe assumption that a large portion of the end-users of your app is vulnerable to security breaches of their smartphone operating system (OS), which makes your app, which also relies on the same OS, vulnerable as well.

Man-in-the-middle attacks, where the vulnerabilities are in the network itself, were one of the topics addressed in part 1 of this series. When we’re looking at the smartphone itself, we’re looking at a different class of vulnerabilities known as man-in-the-device style attacks. There are many ways for an attacker to gain access to the end-user device: They can use social engineering where they trick someone into installing a malicious app, they can exploit vulnerabilities in web browsers or advertising networks, or they can exploit badly programmed 3rd party apps - where even big players such as Facebook can be vulnerable. 

So, where do you have to look when you’re evaluating the security of your app? As with network attacks, it is a good idea to put yourself in the shoes of an attacker, and start with the easiest options first.

Overlays are a type of attack that’s fairly easy to check for. An example of an overlay is the “chat heads” that you can enable in Facebook Messenger on Android. The “heads” pop up on top of your running application, letting you know that there are messages for you to read. This use of overlay is not a security issue, however, the same mechanism can be used by an attacker to hide information in your banking app.

A goal for an attacker can be to trick the user into authenticating a fraudulent transaction, and an overlay showing something innocent on top of the payment details is one way of doing that. You can use the chat heads functionality in Messenger to check this with your application; if it does not flag overlays on top of your transaction details, it is certainly something you should look into.

The mechanism originally used by “chat heads” is being deprecated in the most recent version of Android (version 10), but users of the latest version of Android will always be a small minority – there is always a new version coming.

Modern smartphone operating systems run applications with high levels of separation, which means that a normal application won’t have access to the storage of another application. Another aspect of this is that one application shouldn’t have access to the user interface of another, except through defined mechanisms such as cut-and-paste. When dealing with technology such as screen readers, this can become an issue. A screen reader requires access to the text on the display to speak it out loud, and maybe an alternative interface for sending button presses. 

An example of how this can be exploited in this hack of Paypal, where a malicious app uses the accessibility interface to perform fraudulent money transfers right after the user has logged in. Well-known malware suites, such as Anubis include functionality to steal PIN codes using the accessibility interface, so this is functionality easily available to criminals.

Supporting accessibility is required these days, but it is still possible to verify that your app is protected against this type of attack. On Android, you can install the Android Accessibility Suite, and try to use a keyboard to control your app. If you can complete a transaction using only the keyboard your app might be vulnerable to this type of attack.

As mentioned above the apps, the user installs on their smartphone should not have access to the storage of other apps. As a user, one way to get around this restriction is to “root” or “jailbreak” your smartphone. While it is a common saying that a rooted device is less secure than an un-rooted device, the reality is a bit more complicated. The software that checks if a device is rooted or not only checks if the user has rooted the device, it does not check if there is any malware on the device with root access. This means that if you root your device, you’ll be able to do the same operations as malware can do, which can be useful for testing.

Your first task should be to check if your device is rooted or not and if the root detection works properly. There are good guides for all phones, but since you might not want to take the chance with your own phone you can easily root the Android emulator. For iOS, you’re forced to do the jailbreak on a device. If your app detects that the device is rooted the second task would be to try to check how good the detection is. The most trivial detection only checks if certain files are installed on the device, so by renaming the files you can get around the detection. There is an arms race between detection and evasion, so you’ll have to research the latest detection mechanisms.

But, let's assume that you have root access and can install your app in the rooted environment. The first thing you should verify is the local storage of your app. Do you have un-encrypted access to the local files, such as databases and encryption keys? If so, an attacker might be able to figure out exactly how the security of your application works.

The most technically advanced way to evaluate your app is to do local penetration testing of it, where you try to reverse engineer your app. There are a lot of resources on this topic online, but a good start would be to try to decompile and then recompile your app. A good starting place to start is watching this video on reverse engineering Android apps, and here is a good example of how this can be used in practice.

There have been cases where modified versions of well-known apps have been reverse engineered, modified and then distributed. The main threat from reverse engineering might actually be that an attacker can learn how to exploit potential vulnerabilities in your app, so it can be useful to do your own verification.

Hopefully, these two posts on mobile app security evaluations have given you some useful insight. The security of payment processes and strong customer authentication (SCA) is a topic that is certain to only become more important in the future, and the end-user is trusting us as an industry to provide secure user experiences.

By having a laser focus on the parts of an application an attacker would be most interested in, we aim to mitigate some of the concerns that our clients might have with their app security. 

For more information, dive into how our SCA solution works or check out the Okay use-cases.