Protecting Banking Apps Against Malware Threats

Here we explain why additional security mechanisms, beyond the mobile OS security features, are needed to protect mobile banking applications from malware and related threats.

Some Examples of Mobile Banking Malware 

Cerberus: New Android Banking Malware for Rent 

Cerberus is banking malware that is offered “for rent” by a criminal group on some deep net websites. The “business” model of Cerberus is a subscription-based service.

The malware is known as a sophisticated “swiss knife” offering many “modules” including a keylogger, a module that takes screenshots, a module than scans for data, especially credit card data, etc.

Cerberus belongs to the family of similar banking malware, including Anubis, Red Alert, Exobot, LokiBot, and BankBot. It is very good at mimicking the login screen of many legitimate banking apps which allow it to steal data and credentials. 

The interesting fact is that Cerberus has built-in “anti-anti-malware” techniques that allow it to escape many countermeasures. For example, it can detect user activity in order to avoid detection by anti-malware systems and dynamic analysis. 

Gustuff: The Android Banking Trojan Targeting 100 Banking Apps

Gustuff has targeted approximately 100 banking apps. It has also targeted users of cryptocurrency apps, e-Commerce websites, and payment services, such as Western Union, PayPal, and BitPay.

Gustuff has been labeled as a “weapon of mass infection.” It infects its target by initially sending an SMS that contains a link to an Android package file. That package file is the setup for the trojan. Once installed, the phone’s list of contacts is transmitted to a central server that will use it to send additional SMS and spread the virus further.

Gustuff is a new generation of malware. It has been shown to enable phishing of credentials and automation of bank transactions for over 100 banking apps and 32 cryptocurrency apps.

Mobile Banking Users Need Help to Combat Malware

In 2017, Symantec estimated that there was a cumulative amount of 27,000 mobile malwares operating mainly from insecure third-party app websites, whereas 5,932 new malware variants appeared during the year. The latter figure increased by 40 percent in 2018 with 2,328 new mobile variants [1]. 

When publishing an application, bank and payment service providers should consider the risks that their application will be reversed or hacked via malware. The first task is to educate their customers: 

• Customers should always install the software updates;
• Customers should never install files from links in SMS;
• Customers should never disable the built-in Android security that prevents installing apps downloaded from unknown sources;
• Customers should not root or “jailbreak” their tablets or phones.

But this is far from being enough to create strong security for their mobile apps. Hackers are malicious by nature and will always find a flaw in the system.

Mobile OSs are Vulnerable by Nature and Need Additional Security

Banking apps cannot rely on mobile OS security features alone and Android is the prime target for attacks in the mobile space. 

PSD2 Highlights Mobile Banking Application Vulnerabilities

Payment Service Directive 2 (PSD2) allows mobile banking to use third-party applications and eventually, social websites. Therefore, developers may be forced to use potentially not-very-secure remote APIs, which opens the door to additional threats. For example, The API that connects the mobile phone app with the third-party server could be reverse-engineered and attacked by hackers. The cryptographic key used by the API could also be located in the mobile app code and exploited by criminals. Additional app-specific defense mechanisms can help protect the applications in such cases.

Fake Applications Are Now Routinely Found in Official Mobile App Stores

Large companies like Google or Apple seem to be unable to completely prevent fake applications from being distributed through their secure web stores, Google Play and Apple Store. Such fake apps can take partial or even total control of the mobile phone, steal data, and impact other banking applications installed on the same phone or tablet.

While there are some cases of apps containing malware that are allowed to be published on the official app stores, the app stores are still a much safer place than sideloading apps from unknown sources. The risk of sideloaded apps are low on iOS if the device has not been jailbroken.  

The Main Vulnerabilities of Android

Here are some of the commonly found vulnerabilities of the Android Operating System:

Application Repackaging

The hacker accesses the source code of the application by decompiling it if the source code is  not well-obfuscated. The application is then repackaged with malicious code embedded in it and distributed through legitimate distribution channels.

Fake Installer

The hacker distributes a setup file that looks legitimate but a trojan is installed instead. It also abuses the permissions that it requests from the user. The fake setup uses an exotic language that hides the app’s true “intentions.” Having been asked politely, the user will usually grant the permissions to the installer.

Cold Boot and Other Similar Attacks

Several classes of attacks force the device to enter recovery mode. This is where a modified OS is downloaded. 

Dalvik / ART Vulnerabilities

Dalvik is a Virtual Machine process (now known as Android Runtime - ART). This runtime executes bytecode in the Android context. It has several vulnerabilities that allow an attacker to gain privileges or create a denial of service.

Man-in-the-Middle Attack

Man-in-the-Middle Attacks are the most difficult attacks to prevent. In Android, malware that pretends to be banking applications act as the man-in-the-middle between users and real banking applications. It then captures second factor authentication and uses it in the real application with different amounts and recipients.

Other Attacks

There are many other classes of Android attacks that involve kernel vulnerabilities, keyloggers, adb (android debug) access, etc.

Additional App Security Mechanisms Can Help Protect Banking Applications

Protect Cryptographic Keys

Banking applications use cryptographic keys to protect their sensitive data and communications to the servers. An application could potentially be reverse-engineered and converted into bytecode, pseudo-code, or even fully reversed in the language in which it was developed, such as in the case of C# (Xamarin for instance) or Java.

App defense mechanisms should be able to protect these keys in hardware or scatter them in the memory by using white box cryptography, which itself should be deeply obfuscated.

Beyond TLS

So-called “secure” TLS communications are vulnerable to a man-in-the-middle attack if a rogue certificate has been accepted by the user. Mobile defense mechanisms could prevent this by checking the server certificate fingerprint or even provide additional layers of encryption within HTTPS. 

Anti-Reverse-Engineering

A hacker will usually start working on reversing the banking app. He will download it and install it on an Android emulator so that the application’s communications and behavior can be reversed. App specific security mechanisms, such as application hardening with anti-debug, anti-tamper and emulator detection measures are just some of the security layers that must work together to prevent reverse-engineering.

Blocking Fake or Sideloaded Apps

Fake apps which are given a large number of privileges can be installed on a mobile phone or tablet to interact with the banking application. Android does not allow a mechanism where apps use PKI to guarantee that they have been verified. Apple does this; however, this is a complicated process that can discourage developers. 

Jailbreaking or rooting allows sideloading of unauthorised apps that might contain malware. The defense mechanisms against sideloaded apps will depend on which OS is being used. On Android, it is possible to check if the code certificate is issued by the app owner as well as checksumming. On iOS, the background layer can be checked to see if it is unencrypted. It is only unencrypted if it does not come from the app store. Various checksums are also available on iOS. 

In Summary

Since mobile OSs, and especially Android are vulnerable by default, multiple layers of defense mechanisms are needed within an app itself to efficiently protect banking apps from mobile malware that is aggressively spreading and targeting mobile banking users. 

Apps need their own additional security mechanisms that should protect them against malware and fake apps, such as Gustuff or Cerberus, by performing several protective tasks, including:

• Preventing debugging and tampering of the protected mobile application
• Hardening TLS security (i.e. server certificate pinning)
• Protecting cryptographic keys used by the application

The above points are not an exhaustive list of security mechanisms that can be used to protect against malware attacks. If malware is present on a device, it could be detected by an app (with malware detection), but what is equally, or more, important is how the app can subsequently respond and defend itself from the threats that are posed by the malware. Regardless of which app defense mechanisms are implemented, they need to be mutually reinforcing, so that they provide a 360° protection framework against malware and other threats.

References and Further Reading

• Read more articles about application security for mobile banking applications (2018 - today), by Martin Rupp, Stefan Hansen and more
• [1] Internet Security Threat Report, Volume 24 (February 2019), by Symantec Corporation