NOWSECURE NOW AVAILABLE IN THE MICROSOFT AZURE MARKETPLACE

Microsoft Azure customers gain access to NowSecure Mobile App Security and Privacy Testing for scalability, reliability, and agility of Azure to drive mobile appdev and shape business strategies.

Media Announcement
NOWSECURE NOW AVAILABLE IN THE MICROSOFT AZURE MARKETPLACE NOWSECURE NOW AVAILABLE IN THE MICROSOFT AZURE MARKETPLACE Show More
magnifying glass icon

Mobile banking Trojans: What can financial institutions do?

Posted by
Mobile banking Trojans: What can financial institutions do?

Last month, Russian authorities exposed a mobile banking Trojan plot1 that infected Android devices and forced a victim’s phone to initiate transfers from the victim’s bank account. In a separate incident, security researchers discovered a Google Play Bankbot Trojan2 published on the official store. A lot of people in the banking industry are curious about these events and wondering what they can do protect their customers from the losses and fraud that result from mobile banking Trojans. I spoke with NowSecure CTO David Weinstein to find out.

What exactly is a mobile banking Trojan?

David Weinstein: A mobile Trojan is mobile malware that disguises itself as a legitimate app. A mobile banking Trojan targets bank customers and banking apps specifically, often with the aim of transferring money or changing user information registered with the account. A mobile device is infected with a mobile banking Trojan when a user downloads it. Criminals can fool users into downloading a Trojan by dressing it up to appear like a legitimate app published on a third-party app store, or via phishing campaigns. In some cases, banking trojans have even made it onto the official Google Play store.

When a victim opens their mobile banking app on an infected device, a Trojan can overlay a bogus screen that imitates that banking app’s UI over over the top of the actual banking app’s UI. When performed convincingly, the idea is that the user will enter their banking credentials into that counterfeit UI so that the malware authors can swipe those credentials and use them to steal money out of victim’s banking accounts. Furthermore, SMS-based two-factor authentication tokens, often the last line of defense for stolen usernames and passwords, can also be captured by malware once it has access to appropriate permissions on the device.


Download our recent whitepaper “Mobile Banking Applications: Security Challenges for Banks.”


What can financial institutions do to help protect their customers against mobile banking Trojans?

Weinstein: The first line of defense should always involve education, usable security, and a healthy dose of following best practices. One of the trends is a resurgence of UI deception attacks. The attacks can be pretty convincing and take advantage of human behavior and programming. The best way to counter these types of attacks is a combination of educating users to be aware of them and enhancements at the OS level. Once a user has installed a piece of malware on Android, the OS is responsible for providing basic security primitives such as isolation between processes, and restricting access to files on the filesystem.

Some of this malware is straight up tricking users into giving away their usernames and passwords by presenting a very realistic looking login prompt. Implementing two-factor authentication (2FA) can help in some situations. But depending on the implementation, it’s not a cure-all. For example, Android malware from the “Cron gang”3 could intercept text messages sent by banks to their customers.  Two-factor authentication (2FA) implementations that employ time-based one-time passwords (TOTP), HMAC-based one-time passwords (HOTP), or specialized apps can help in some situations where the malware also steals text messages.

Google adding additional Android support to limit app overlay could also help. The tradeoff, however, may limit the creative ability of app developers to provide a desired UI effect.  Overlay malware/attacks are harder to execute on iOS thanks to some design decisions in the OS.  In the case of Android apps, banks can also make sure they follow mobile app security best practices such as implementing file permissions carefully (e.g., limiting the use of world-readable files, avoiding the use of shared storage locations, and using content providers carefully). We’ve designed automated tools to detect these types of flaws and they are built into our products.

From a security perspective, iOS has benefited from a very constrained and well-defined interface for apps to share information. However, iOS 11 appears to be adding support for “drag-and-drop”4 which may open the door to new attacks for Apple’s iOS. We’ll definitely want to keep an eye out for how these features evolve and their impact on security.


Read our recent blog post about Android overlay malware.


How can mobile banking Trojans take advantage of an app’s use of world-readable files?

Weinstein: While unlikely, a developer could (though this has been partially mitigated in some newer versions of Android) create a database of information, via SQLite for example, that stores whatever type of information. That might include cached requests, usernames, or other user-specific information. If those files are world readable, then any app on the device can potentially read them (again, this is harder to do in some newer versions of Android). Thus a malicious app on the device would presumably read this information and send it off for collection by the malware’s authors.

How can an app using shared storage in Android be taken advantage of by a mobile banking Trojan?

Weinstein: Shared storage is often used for larger data because of Android’s design. If there’s any type of app configuration data being stored in this shared storage area, then the next time the app reads it, the data could have been corrupted by other applications. An application that opens corrupted (attacker-controlled) data can potentially result in faulty logic, behave incorrectly, or worse can be a vector to exploit traditional vulnerabilities such as a buffer/heap overflow as might be found in media file formats. Anywhere we find a file parser that is loading untrusted data we must also consider the potential for an attacker to gain code execution.

What do Android developers need to watch out for in terms of content providers?

Weinstein: Essentially, the `ContentProvider` object allows apps to share data amongst themselves. Once a malicious app is installed, it can try and perform local attacks that would normally be more difficult to do remotely. Even though the app does not have elevated privileges, certain resources are easier to access when the malware is installed on the device. A malicious app installed on a device might try to abuse a banking app `ContentProvider` and gather app data from it. Anything related to hardening the app’s local attack surface and interfaces is a good design decision. Once the OS has been compromised, there’s nothing a developer can do. But until that point, an app should have well defined and protected public interfaces. We specifically test for vulnerable content providers, vulnerable inter-process communication (IPC) and SQL injection vulnerabilities in our products. This helps us consistently detect these common attacks.

What are the Android and iOS platforms doing to make it easier for developers in the banking industry to make their apps and their users more secure?

Weinstein: In many cases the Android and iOS platforms try to provide well defined ways to do the right thing, but a developer can at any time choose to go around those. An example of that is a developer finding something online and simply copying and pasting code from Stack Overflow or another forum into their app. Thus it becomes the OS’s responsibility to try and mitigate the residual attack surface. Because Android provides a more open platform to a degree, it’s just much easier for a developer to shoot themselves in the foot if they do go off the beaten path.

However, newer versions of Android include security enhancements that impose a much more restricted set of policies via new mandatory access controls. That reduces the likelihood of those mistakes being so costly, but there’s only so much the OS can do. A confused user, especially via UI deception, is apt to make a poor decision that is very difficult for the OS to mitigate. That’s because normally in tricky situations it devolves to asking the user to resolve something and thus the user is the ultimate authority. Ideally those types of situations are very limited.


Watch our webinar “Delivering secure mobile financial services (MFS).”


Can NowSecure help financial institutions make their apps more secure to help defend against mobile banking Trojans?

Weinstein: Absolutely! Here’s the hard sell: our security knowledge is baked into the tools we build and the products and services we offer. Frequent, consistent, and actionable security testing of your app is something we believe every developer and security organization should have access to. If you want to learn more about how to test your apps for the best practices I’ve mentioned, please get in touch!

 


1 http://www.reuters.com/article/us-russia-cyber-banks-idUSKBN18I0VE

https://www.securify.nl/blog/SFY20170502/sophisticated_google_play_bankbot_trojan_campaigns.html

3 http://blog.group-ib.com/cron

4 https://twitter.com/schukin/status/872150286411812864