It’s important to investigate the mindset of a cybercriminal and explore the attack tools they typically use before discussing the ways of solving the problem. The typical attack methods exploited by hackers to compromise mobile applications, and the common weaknesses associated with them, are not always as obvious as they may seem.
Reverse engineering is often the cornerstone of any attack on a mobile application. Hackers are familiar with common structures in compiled code. For example, they might look for a string corresponding to an error message related to their objective (e.g. “invalid PIN”) and trace where that string is used. They often turn to static analysis and debuggers, which help them understand the overall structure of the code, where the functions are located, how they are called from other functions. Bad actors can also look at assembly language code and immediately recognize that it is, for example, performing cryptographic operations.
A cybercriminal might also take a legitimate payment application and modify it so that instead of the application performing the tasks originally designed for it; the application performs tasks for the cybercriminal, such as stealing information from the mobile device. Such modified applications can be easily distributed to a large user base by taking advantage of people who use rooted or jailbroken devices.
Mobile applications, especially those dealing with finance and payments, often store sensitive data. This might include usernames, password hashes, account numbers, PIN codes, cryptographic keys, personally identifiable information, proprietary algorithms or intellectual property. With reverse engineering stolen information can be used to pretend to be a legitimate banking customer, mimic the way the application communicates with other parties, create unfair competition or even eavesdrop on encrypted networks.
Malicious software, if present on a device, can directly intercept and modify API calls and hence manipulate data in transit, such as credentials, and payment information. Moreover, recent studies have shown that most software has 7.5 defects per thousand lines of code. Moreover, hacks often go undetected until they are too big and too late to manage.
Almost all successful attacks on a mobile application result from poorly designed or implemented software. Sadly, financial and banking apps are no exception. With decades of experience in software security, our researchers have been following the advent of mobile technologies from the very beginning, and the most common problems with mobile applications that often lay the groundwork for subsequent attacks are as follows: lack of protection against debugging and reverse engineering of code; unobfuscated code that is easy to analyze and exposes vulnerabilities; no jailbreak/root detection; using cryptographic keys and passwords in plaintext; sensitive information exposed in log files and crash reports; unencrypted local databases used to store sensitive information; unprotected resources and metadata, such as images, which can be used to create phishing applications; ineffective risk management program or lack thereof.
It is imperative for financial institutions to take the necessary steps to protect their applications by making them harder to hack. Some of the main techniques for protecting mobile financial applications against reverse engineering and other attacks are well known, if not completely understood by most IT professionals.
Hardware-based security involves a dedicated piece of hardware that runs separately from the main device processor and cannot be directly manipulated by it. It is commonly used to provide strong protection for cryptographic keys. Examples of such hardware are hardware security modules (HSM), trusted platform modules (TPM) and trusted execution environments (TEE). The security of these systems relies on the fact that it is very difficult and expensive for attackers to reverse engineer a hardware module and manipulate its internal data.
Hardware security systems can be considered “black box models” because their internal workings are essentially hidden to the observer. Although the hardware-based approach does provide excellent security advantages, there are also significant downsides.
Banks, by way of example, have no control over the chipset or the device a customer chooses to use, nor can they persuade customers to upgrade their devices. So, while a TEE is secure it is not present and accessible in every device.
Hardware-based security adds cost to a system, and while major platform vendors do have some kind of hardware security, vulnerabilities are difficult and potentially expensive to mitigate. For example, recent attacks against hardware such as Meltdown and Spectre illustrate the challenges that hardware manufacturers and IT purchasers face to issue patches to fix vulnerabilities in existing deployments. These mitigations can cost large amounts of money and consume vast amounts of resources.
It is also important to note that different devices may contain different hardware with varying functionality, requiring complex logic in applications built to run on a wide range of devices. And no matter the approach, hardware is simply never completely immune to attacks. Clever attack modes such as differential power analysis can be used to extract keys from hardware by examining indirect patterns in signals emanating from the hardware itself.
There are also business models that preclude developers from using secure hardware on a device even when it exists. Such is the case with Apple iPhone, where although it has ARM processors with a TEE, third-party applications developed by banks are not allowed to leverage that functionality directly.
Considering today’s open architecture of mobile devices and the ease with which applications can be obtained and distributed, software vendors cannot rely on the assumption that their mobile applications will be used in a proper manner by the right users, within a safe and controlled environment.
Instead, the recommended approach is to assume the worst. Namely that the software will eventually end up in the hands of an attacker, and security mechanisms must therefore be embedded into the application itself. This technique is sometimes referred to as application shielding. Typically, this would involve code obfuscation, code integrity protection, rooting/jailbreak detection, white box cryptography, anti-debug protection, binary packing, and runtime application self-protection (RASP).
The use of host card emulation (HCE), electronic wallets and secure access to cloud-based services presents challenges for mobile apps that reside outside the firewall where hackers can get full access to the source code through disassembly. However, by using application shielding technologies during the development process, the mobile app can bring security with it no matter where it runs.
In the current threat environment, hackers can easily disassemble and attack mobile apps if proper app shielding is not used. Alongside ongoing concerns around security and fraud, the onus is on banks to protect their customers’ personal information and money, as well as their own brands.
Ultimately, banks need to react to the global shift to mobile. Ensuring that their digital property and mobile applications, which are so crucial to trusted digital life and commerce, are protected by the highest possible level of security, just as they did their brick-and-mortar branches in the past.
