Financial Mobile App Vulnerability FAQs
Last year research by Aite Group examined mobile application security vulnerabilities across eight financial services sectors. It took an average of only 8.5 minutes to compromise each of the 30 apps analyzed—every single financial services vertical was found to be vulnerable. Using commonly available software tools, nearly all of the apps were easily reverse engineered, revealing a systemic lack of application-level protection and coding best practices.
This widespread mobile app vulnerability epidemic can result in significant financial losses and damage to brand, customer loyalty, and shareholder confidence—as well as large government penalties. Are your current security measures enough? What can and should you do to improve your mobile app security?
Let’s examine just a few of banking mobile app vulnerability most frequently asked questions.
How are banks responding when notified of their potential mobile app vulnerabilities?
As mentioned above, Aite Group’s research uncovered widespread security deficiencies among mobile consumer financial apps leading to the exposure of source code, personally identifiable information, account credentials and access to backend systems. When we communicated those deficiencies to the financial institutions in question, there were mixed reactions depending on the role at the corporation. Executive leadership often expressed disbelief — “how did this happen?!”, “fix it immediately!” etc. The app developers, however, were defensive and often asked questions such as “where am I supposed to put user authentication details and encryption keys?.”
The most important point to remember is the days of having a secure perimeter and network edge are long gone. We’re living in a Software Defined Perimeter world now where in many cases, the application itself has become the new endpoint. Apps are downloaded to untrusted mobile devices every day and used for anything from mobile banking to social media, shopping, gaming or chatting with friends. A majority of these applications are not protected before they are published, many contain bugs which could become exploitable vulnerabilities, and/or may contain coding errors which accidentally leak or share data with other applications or the device itself. Plus, once apps are published they have no way of reporting back to the organization if they are being analyzed, reverse-engineered, attacked or tampered with. Application code today contains critical information that adversaries could exploit to further attack the organization's back-end infrastructure.
From a bank’s point of view, what types of training should they invest in to make them less vulnerable?
The main question we get asked from executives is “how do we prevent these breaches from happening in the first place?” Most organizations invest heavily in user security training. The issue with this approach is it’s forgetting the most critical group in an organization — code developers. Training for developers is expensive and focusing on user awareness training when it comes to consumers is like trying to boil the ocean. Making the development process even more complex Aite researchers found that many larger banks actually outsource their application development, and most banks consider the mobile app a function of the marketing team, like their website. In some cases, app security isn’t even tested before it goes into the app store! So secure coding best practices training is critical and budget constraints shouldn’t be used as an excuse to not take it seriously.
Our financial institution scans the software before it’s published in production and looks for code issues. Does this method work?
The short answer is no when it comes to the vulnerabilities discovered by the Aite researchers. Typical controls for app security focus on ensuring app code passes quality and security procedures and that accounts can only be accessed by authorized users using device level authentication. Traditional approaches are focused on the creation of a secure ecosystem – including network security technology like web application firewalls – that ensure app code security and a certain level of network security. Neither of which is capable of protecting the business from app reverse engineering or directed API attacks.
These approaches provide needed levels of traditional security and are essential in developing a secure defense in depth strategy. But what is missing from these approaches is actual code protection or protection against the use of stolen API credentials. Additionally, for protection solutions to be effective they require the ability to notify the organization of active threats — especially as cyber criminals evolve their tactics developing more advanced means of attacking financial apps.
Today’s data is all over the place — on mobile phones, AWS cloud, S3 buckets, at-home work station, tablets — and enterprises can’t fully control it. IT executives need to control what they can and build security layers -- encrypt the code, get an API security gatework to secure the traffic, hire a penetration tester, deploy dynamic code analysis. Organizations can’t fall into the trap that because they applied a certain security product, they don’t have to worry about it further. This couldn’t be further from the truth.
I have a blank check from my CISO. How should I spend it to fully protect my application?
Remember, whatever can be built by humans can be broken by humans. There is no such thing as a completely securely coded app. Solutions like firewalls, app security, penetration testers can help, but if a bad actor is determined enough to get inside an app, they will. So you need to think about it differently: It’s not about if an app can be reverse engineered but instead how quickly the attack can be detected.
Just like with any good defensive strategy it must be employed in depth. Protecting app code is no different and current best practice approaches should include the following:
- Securing mobile app code with various obfuscation techniques making it extremely difficult to reverse engineer
- Encrypting and hiding keys, API locations and tokens protecting them from discovery and fraudulent follow-on attacks where traffic appears legitimate
- Defending against reverse engineering attacks enabling apps to disable functionality when code level attacks are detected
- Alerting the business and providing real-time threat data from apps as to device status and of in-progress code level attacks
One of the key capabilities listed above is app-level threat detection that identifies and notifies on exactly how and when apps are attacked at the code level—beginning with alerts if an app is downloaded onto a device that has been rooted or jailbroken—continuing to identify suspicious behavior. With real-time threat data businesses can initiate immediate responses, such as shutting down an application if tampering is detected, sandboxing a user, revising business logic and repairing code.
Mobile banking app security provides a critical, cost effective business service and is often used to process sensitive customer data, including personal information, bank credentials and credit card numbers, provide access to back-end systems and may contain intellectual property.. All this data and system access is at risk of being exposed if an app is compromised, and can result in brand damage, financial loss, intellectual property theft and even government penalties.
What are the different ways bad actors can take advantage of applications they reverse engineer?
Application-level attacks all have a common threat vector. Exploiting this weakness enables a common attack path, the reverse engineering and understanding of the attacked app. Once the apps operation, data and keys are understood, two common follow-on attack types are likely to occur.
App repackage/redistribution attacks
- Mobile apps are repackaged with malware designed to steal credentials
- Compromised apps are published to a fraudulent app store followed by a mass email campaign designed to lure customers to download the app
- Once downloaded customers input their credentials which are immediately sent to the cybercriminals enabling them to commit follow-on fraud, typically via an account takeover
- App contents are thoroughly examined with a focus on finding API tokens/keys, locations (production and QA) along with passwords and user IDs as prime targets for extraction
- API access information is then repurposed to use in focused attacks designed to gain direct access to back office systems and data
- Traditional network security is typically circumvented because traffic appears legitimate