Architecting mobile banking apps against attackers

Hand in hand with 157% mobile penetration [1], mobile banking has seen widespread adoption and growth in South Africa, and is quickly becoming the preferred method of banking for many. Topically, the present COVID-19 pandemic may be fuelling this, as businesses encourage the use of mobile payments to shift transaction volume away from physical cash [2].

Through recent mobile application security assessments, we have observed one organized crime group taking advantage of this trend by stealing users’ smartphones, and targeting the mobile banking application on their device. The examples in this article are based on said assessments and the recommendations provided to financial services clients. Our aim is to share the findings with developers, that they may take them into consideration when developing mobile applications and educating their customers on security best practice. It will discuss: 

• Common development pitfalls and vulnerabilities in the context of a device that has been appropriated by an attacker 
• What such that attacker would likely target, given their goal of defrauding mobile banking users  
• The remediations available from development and education perspectives

What will attackers do with a stolen device?

Observed trends indicate the crime group in question was opportunistic in nature, but well organized. This conclusion is based on analysis (in the cases that F-Secure reviewed) of the consistency in its Modus Operandi (MO). The group demonstrated some level of technical competency through its employment of phishing. However, based on the fraud cases seen so far, a low level of sophistication can be assumed when it comes to finding and exploiting technical, application-level vulnerabilities.

The attackers have generally tried to steal devices while unlocked and in use by the victim. Though mobile phones are easier to snatch when users are distracted, this could also be an indication that the attackers are deliberately trying to do so in order get direct access to the applications on the stolen device.

Unlocked access to the device is useful to an attacker, but the ideal scenario would be to know the device unlock code, pattern, or password. This would allow them to add fingerprints, change settings, enable developer options, and so on. An attacker aiming to exploit technical vulnerabilities would likely want to jailbreak or root the device to gain privileged access to its operating system (OS), allowing them to bypass platform sandbox controls. Rooting and jailbreaking would generally result in a device restart, locking the device, thus further justifying the need to obtain device unlock credentials.

Some attack vectors do exist for compromising device unlock credentials, but they are highly situational. If a user uses a PIN code or pattern, it could be compromised through guesswork or shoulder surfing – i.e. peering over a user's shoulder while they are unlocking the device. Additionally, some device unlocking tools are available to law enforcement agencies, which are advertised as being able to unlock modern Android and iOS smartphones [3] . Should an attacker gain access to these tools, they could be useful in compromising unlock credentials. However, these tools are generally not freely available.

Once an opportunistic attacker has physical access to a device, their priority would be to scour it for stored credentials associated with the target application. Device access would likely also mean direct, authenticated access to the user’s email accounts, messaging applications, social media, and note-taking applications. If the user has stored or shared their credentials through any of these channels, compromising the credentials is as simple as finding them. Should the attacker manage to compromise the device PIN or password, and reuse it for the targeted application, this would also lead to a straightforward compromise.

It may also be possible that the targeted application stores authentication credentials insecurely. On rooted and jailbroken devices, the attacker can manually search through all of the application's assets for anything that might allow them to authenticate. If stored at all, credentials would likely reside in the secure storage mechanisms on Android and iOS. While these mechanisms can protect credentials from exfiltration, their effectiveness depends on how credentials are stored. Without appropriate protection from biometric authentication or encryption, they could be extracted on rooted and jailbroken devices.

Biometric authentication itself may present another attractive target. This is because insecure implementations can be bypassed through dynamic instrumentation [4]. For a biometric authentication mechanism to be secure, it has to rely on secure storage and cryptography. The complexity of implementing the mechanism is often overlooked, as public guides err towards practical, but insecure implementations. A common development pitfall is when an application does not invalidate the biometric authentication credential on the enrolment of a new fingerprint. If an attacker knows the device unlock code, they could then simply add their own fingerprint to the device and authenticate to the targeted application.

Application password reset and Multi-Factor Authentication (MFA) mechanisms often use email or SMS messaging as a second factor. This model can be ineffective when an attacker is in possession of a user's smartphone, as they will likely have access to its email and messaging applications.

Browser credential storage can be yet another avenue leading to account compromise. If the targeted application has an associated web application, users can store their credentials in the mobile browser to allow it to authenticate automatically. An attacker can use the mobile browser on the stolen device to authenticate to the web application; thereby removing the need to access the mobile application altogether, or as a means of accessing the mobile application later down the line, through a password reset or similar mechanism.

What can developers do to defend their applications?

Developers will benefit from considering the appearance of their application's attack surface, and who the likely threat actors are that would target it. The observed trend in South Africa in this instance is fraud being committed through mobile banking applications on stolen smartphones [5]. And from the assessment data collected, it is reasonable to estimate that the threat actor is a group with physical – and assumed unlocked – access to its victim's smartphones. 

From a technical perspective, the following areas can then be considered likely targets for the threat actor, and reviewed with the assumption that they have authenticated access to the device: 

• Biometric authentication
• Password reset mechanisms
• MFA mechanisms
• Local storage
• Device linking and unlinking mechanisms

Device linking is an important component of mobile application security, especially for banking applications. In the event a device is stolen, banks may unlink devices such that they can no longer be used to access a user's account. This can effectively reduce fraud, although it is reliant on the user notifying their bank as soon as the crime takes place.

The detection and response capability of an application is another important factor to consider. Detailed event logs are often critical in fraud investigations to determine whether technical vulnerabilities have been exploited. We recommend logging at least the following information:

• The unique device identifier (UUID or IMEI) to tie account-related actions to a specific device
• Detailed authentication events, including the authentication type (biometric, passcode, etc.), to determine which authentication channel was used to commit the fraud
• Password reset events to determine whether the attackers changed the user’s password to gain access to their account
• The device’s IP address, such that account activity can be linked to geographical areas
• Which application functions were used (transfers, beneficiary changes, payments, device linking, etc.) to help identify patterns in the fraud
• Device manufacturer, model, and OS version information, to determine whether the fraud can be tied to a specific device or mobile platform

In our assessments, fraudulent transactions were seen to be consistent and identifiable. With detailed logs, automated fraud detection mechanisms could be implemented based on simple detection rules, such as location, time, sizeable transfers to accounts not transacted with yet, etc. For example, a detection rule could be defined for maximum one-off payments to a new beneficiary or an unknown account. These rules will differ based on the activity the bank observes with their own clients, but can be an efficient way to reduce the number of successful fraudulent transactions. Automated rule-based detection mechanisms may be bypassed if rules can be determined or inferred, thus requiring a flexible approach, where rules evolve with attackers’ actions.

What can users do to protect themselves?

User behavior plays an important role in whether fraud attempts are successful. Therefore, user demographics and levels of technical understanding should also be considered by developers. An understanding of your userbase enables targeted user education campaigns to guide those customers in protecting themselves. Below are some recommendations banks with mobile applications can communicate to their customers.

• If a device is stolen, users should know to notify their bank as soon as possible. In most cases, this will allow the bank to unlink the device from their account and prevent access. 
• iPhone users can also use the Find My iPhone feature to remotely lock or erase the device if it lost or stolen. This feature is useful in removing any sensitive information and applications from the device. Android devices might have similar alternatives, but this depends on the device model and OS version.
• Make users aware of possible phishing attempts following the theft of their device. Targeted phishing campaigns could prove very effective, given the amount of personal information stored on a stolen device. Phishing is also frequently used to steal iCloud credentials [6] to disable the Find My iPhone feature, so that the smartphone can be re-enabled after “lost mode” has been enabled. 

Weak password security is a specific area that is frequently exploited across all fields of information security. Users can, however, limit their exposure by making it infeasible for passwords to be guessed or brute-forced by following some guidelines:

• Never reuse passwords across applications
• Never reuse the device lock PIN or password in other applications
• Never store passwords in note-taking applications as they are generally stored insecurely
• Never share passwords, especially through messaging and email applications
• Choose sufficiently long and complex passwords (i.e. a mix of upper and lowercase, special characters, numbers, and non-identifiable personal information)

Password length has the biggest impact on password strength [7]. To help users create long, but memorable, passwords, they can be advised to instead think of them as passphrases: combinations of words rather than letters. This increases both their security and usability. Password managers can be used to make it easier to follow these guidelines.

To ease the inconvenience of a complex password, biometric authentication may also be used, as it reduces the number of times a password needs to be manually entered. Users can normally still use a password or PIN if they cannot authenticate via the biometric sensor. Therefore, the biometric authentication mechanism is only as strong as the underlying password or PIN and should only be used in conjunction with a strong password, which then offers the best of both worlds in terms of security and convenience.

Concluding remarks

Mobile banking in South Africa has made a wide range of services more accessible and convenient. With this, comes a certain level of risk that developers and users need to be aware of. Attackers and crime groups will generally follow the path of least resistance to target their victims. The goal then should be to raise the bar such that targeting banking applications becomes a less lucrative endeavour. This can be achieved if developers and users are equally aware of the risks, and take active, collaborative steps to address the growing risk.

[1] https://www2.deloitte.com/content/dam/Deloitte/za/Documents/risk/za-The-future-of-payments-in-South-Africa%20.pdf

[2] https://techcrunch.com/2020/03/25/african-turns-to-mobile-payments-as-a-tool-to-curb-covid-19

[3] https://www.cellebrite.com/en/advanced-services

[4] https://labs.f-secure.com/blog/how-secure-is-your-android-keystore-authentication

[5] https://www.sabric.co.za/media-and-news/press-releases/mobile-phone-snatching-fraud

[6] https://krebsonsecurity.com/2020/01/phishing-for-apples-bobbing-for-links/

[7] https://pages.nist.gov/800-63-3/sp800-63b.html