As the use of mobile phones for mobile banking and payment applications increases, corresponding security threats are increasing as well. The majority of smart phones use only two operating systems (Android and iOS) and, therefore, they represent prey of choice for criminal groups and malevolent hackers.
In this article, we will explain some of the defense mechanisms and security techniques involved with protecting mobile banking applications.For the sake of simplicity, we will use the term “mobile banking” for mobile online banking applications as well as for any mobile payment application.
Some of the Techniques Used by Criminal Groups to Target Mobile Banking
Most attackers targeting mobile banking have the goal of performing fraudulent transactions for their benefit and/or stealing confidential banking data. Due to the high potential payoff, criminal hackers have a wide range of techniques at their disposal when targeting mobile banking. Such techniques include:
- Reversing the legitimate banking application by decompiling it and using debugging tools;
- Creating fake apps that “mimic” the legitimate apps and offering the apps for download on websites, eventually including “legitimate” distribution channels;
- Creating SSL proxy or, in general, spying communications between mobile phone and bank servers and/or 3rd party API servers, using protocol analyzers to capture data;
- Injecting trojans or other viruses into the mobile phone, either remotely or physically (“rogue repair shop” for instance);
- Other techniques, some that we may not even be aware of yet.
Effectively defending against these wide range of attacks requires numerous mutually reinforcing security layers and mechanisms within the app.
Security Layers and Techniques to Efficiently Protect Banking Applications
The communication between the app and the back-end server must be secure to protect the data being sent and to ensure the app only communicates with the intended system. Securing the communication can involve several mechanisms, including protection for access tokens and cookies, encrypted transport protection (HTTPS) and HTTPS tunneling and additional assurance mechanisms to authenticate both the mobile device and the back-end system.
Application hardening mechanisms should be employed to make the app difficult to attack or modify. This includes obfuscating the source code of the application and especially, the relevant data and constants that are used to connect to servers. Methods to detect tampering attempts of the app, especially by debuggers, simulators, and emulators should be considered. Malevolent physical access to the device & app should also be prevented. Finally, this security layer should be able to detect the rooting or jailbreaking of the device and respond accordingly.
Secure Storage and Key Protection
The app must be able to efficiently protect the various cryptographic keys by preventing their possible recovery by an attacker. Usage of secure storage, such as using a secure element or SIM card, should also be offered if possible. Otherwise, this can be achieved with dedicated obfuscation methods.
Sentinels for Runtime Application Self-Protection (RASP)
Runtime Application Self-Protection should use a sentinel framework, meaning having software “sensors” that stay awake to monitor all the parameters. The sentinel(s) should be able to detect and react to attempts to attack the app. Proactive defensive actions should be taken by the sentinels in case an attack is detected. Possible actions could be the blocking of individual requests, voluntary crashing of the mobile application, reporting the activity to the back-end server, etc.
The sentinels should not be detectable by an attacker and should be protected from being deactivated, incapacitated, or removed. Threats against the sentinels themselves should also be detected and acted upon.
The app should be able to compute the device hardware signature to uniquely and securely identify devices to remote servers. This can, of course, involve the International Mobile Equipment Identity (IMEI) or any physical unclonable function (PUF) present on the device.
The app could use public key infrastructure (PKI) to check the legitimacy of banking applications and eventually, other applications. This could work to address the lack of security of Google’s official distribution channel (Google Play) that allows the downloading of insecure and unverified software for Android. PKCS mechanisms could also be used to enforce mobile banking security.
Strong user authentication such as biometric authentication and identification must be supported.
The app security layers and mechanisms should be updated periodically. Newly discovered vulnerabilities should be efficiently addressed by the security developers, and patches should be created and released as soon as possible. Of course, the auto-update must be totally bulletproof to prevent attackers from using the mechanism to update modified versions.
Challenges in Terms of Development and Integration
The security mechanisms described above must be “lightweight” and smart.
They should in no way hinder the development of the mobile banking application. Instead, it should ease it.
The developers of the app security must stay reactive to the development of new mobile banking attacks.
They should have 24/7 support and even a 24/7 responsive “answer team” with the ability to develop rapid patches in the event of any zero-day exploits, for instance.
Therefore, the architecture of such security layers should be very modular. This will allow it to be adapted to new attack techniques, which are still unknown.
Because of the points above, many banking app providers look to security vendors to provide the necessary layers of protection instead of developing them in-house. Outsourcing the security sensitive aspects enables banking app developers to focus on delivering the most user-friendly business apps while leaving the critical security-related parts to the specialists. The security and defense mechanisms for mobile banking apps could come in various shapes, as a service, as an API, or as an SDK offered to the developers of mobile banking applications.
References and Further Reading
- Read more articles about Runtime Application Self-Protection (RASP) for mobile banking applications (2018 - today), by Martin Rupp, Stefan Hansen and more