This is according to Aaron Lint, Chief Scientist and VP of Research at Arxan Technologies, who discusses with Finance Monthly below, touching on the key elements of tech security and the use of financial applications across devices.
There’s a systemic problem across the financial services industry with financial institutions failing to secure their mobile apps. With mobile banking becoming the primary user experience and open banking standards looming, mobile security must become a more integral part of the institution’s overall security strategy, and fast.
When a company fails to consider a proper application security technology strategy for its front line apps, the app can be easily reverse-engineered. This sets the stage for potential account takeovers, data leaks, and fraud. As a result, the company may experience significant financial losses and damage to brand, customer loyalty, and shareholder confidence as well as significant government penalties.
Where’s the proof?
A recent in-depth analysis conducted by Aite Group of financial institutions’ mobile applications highlighted major vulnerabilities including easily reverse-engineered application code. Each app was very readily reversible, only requiring an average of 8.5 minutes per application analysed. Some of the serious vulnerabilities exposed included insecure in-app data storage, compromised data transmission due to weak cryptography, insufficient transport layer protection, and potential malware injection points due to insufficient integrity protection.
For example, of the apps tested, 97% lacked binary code protection, meaning the majority of apps can be trivially reverse engineered. Of equal concern was the finding that 90% of the apps shared services with other applications on the same device, leaving the data from the financial institution’s app accessible to any other application on the device.
This metadata is built by default into every single unprotected mobile application in the world. It provides not only an instruction manual for the APIs which are used to interact with the data center, but also the location of authorization keys and authentication tokens which control access to those APIs. Even if the applications are implemented without a single runtime code-based vulnerability, this statically available information can provide an attacker with the blueprints they are seeking when performing reconnaissance.
There is no shortage of anecdotal evidence which shows that hackers are actively seeking to take advantage of vulnerabilities like the ones identified in the research. For example, recently mobile malware was uncovered that leveraged Android’s accessibility features to copy the finger taps required to send money out of an individual’s PayPal account. The malware was posted on a third-party app store disguised as a battery optimisation app. This mobile banking trojan was designed to wire just under £800 out of an individual’s PayPal account within three seconds, despite PayPal’s additional layer of security using multifactor authentication.
So, what’s the solution?
To minimise the risk of all of the vulnerabilities being identified and ultimately exploited, it is essential that financial institutions adopt a comprehensive approach to application security that includes app shielding, encryption, threat detection and response; and ensure their developers receive adequate secure coding training.
App shielding is a process in which the source code of an application is augmented with additional security controls and obfuscation, deterring hackers from analysing and decompiling it. This significantly raises the level of effort necessary to exploit vulnerabilities in the mobile app or repackage it to redistribute it with malware inside. In addition, app-level threat detection should be implemented to identify and alert IT teams on exactly how and when apps are attacked at the endpoint. This opens a new avenue of response for an organisation’s SOC (Security Operations Center) Playbook, allowing immediate actions such as shutting down the application, or sandboxing a user – essentially isolating them from critical system resources and assets, revising business logic, and repairing code.
App shielding and the other types of application security solutions mentioned above should be incorporated directly into the DevOps and DevSecOps methodologies so that the security of the application is deployed and updated along with the normal SDLC (Software Development Life Cycle). App Shielding is available post-coding, so as not to disrupt rapid app development and deployment processes by requiring retraining of developers. This combination of best practices increases an organisation’s ability to deliver safe, reliable applications and services at high velocity.
It’s no secret that the finance industry is a lucrative target because the direct payoff is cold, hard cash. Research is showing that virtually none of the finance apps have holistic app security measures in place that could detect if an app is being reverse-engineered, let alone actively defend against any malicious activity originating from code level tampering.
We would reasonably expect our fundamental financial institutions to be leaders in security, but unfortunately, the lack of app protection is a disturbing industry trend in the face of a significant shift into reliance on mobility. Organisations need to take a fresh look at their mobile strategy and the related threat modeling, and realise how significant the attack surface really is.