Is your mobile banking app exposed by someone else’s software?

This post was written in collaboration with Neal Michie, Director, Product Management, Verimatrix.

Banks are facing massive disruption and change from many directions. The rise of app-only banks has made the need for traditional banks to have compelling app services an imperative. Banks have of course been building mobile apps for several years. If not already, they will soon be the most important channel for engaging with and serving customers. However, mobile banking apps will also become the primary focus of hackers, intent on getting access to other people’s information and money.

How have mobile banking apps evolved?

From lightweight apps supporting basic banking functions they have now evolved into full service branches including all manner of sophisticated features such as biometric identification, payments, loyalty and personal finance management driven by data science and machine learning.

Some of the things you might expect to find feature rich mobile apps include:

• Numerous APIs supporting the large number of features – creating a large attack surface through API Abuse.
• A mixture of native code, managed and web-code – providing different levels of control over how sensitive data is handled.
• Dozens of dependencies on third party SDKs and libraries – each outside of the direct control of the bank.
• Hundreds of thousands of lines of code – making isolating and auditing critical security functionality very difficult.
• Use of WebViews to render web-code – providing great flexibility but making the app more reliant on external services for its security.

Third-party components are a particular issue

The use of third-party components may expose banks to new security risks. If these risks are not carefully managed and the customer data is compromised, then banks risk regulatory fines and reputation damage, not to mention the inconvenience and worry caused to customers.

To give you an idea of the size of the issue – third-party components can provide all manner of functions such as remote user monitoring, instrumentation, error and crash reporting, profiling, binding the user to the device, analytics, cryptography, UI enhancing, financial charts and many more. Components may be proprietary or open source code. They are integrated into the app where they may gather or process data and connect to third-party backend servers that may or may not be under the control of the bank.

The risk isn’t just theoretical. The well-publicised attack on British Airways breached the airline through known vulnerabilities in third party code. The business risk: a fine equivalent to 1.9% of revenue and long-term reputation harm – we are still talking about it 2 years later.

While not exhaustive, some of main security issues to watch out for include:

• Auditing: Banks may not have access to the source code of proprietary third-party SDKs and libraries. This makes the task of ensuring that the software is safe much more difficult. Penetration testing techniques can be used to monitor the behaviour of the component, but this is no substitute for a source code review.
• Deployment model: Often third-party components need to connect to the third-party backend services. Sometimes those backend services have to be operated by the third party. Other times it may be possible to bring those backend services in-house. Obviously bringing them in-house gives more control to the bank to ensure any sensitive data stays within their infrastructure. Where this is not possible, then the bank may unwittingly introduce a “data processor” in GDPR terms into their service without the necessary oversight.
• Known vulnerabilities: Third party components may in turn utilise various other proprietary or open source libraries. Some of these dependencies may have known vulnerabilities which leave the bank app exposed.
• Potential information disclosure in transit: Third party SDKs may not have adequate transport security enabled. For instance, no or weak TLS certificate pinning may be implemented, making any communication between mobile apps and the backend susceptible to man-in-the-middle attacks. This can potentially leak sensitive information in transit.
• Potential information disclosure at rest: Third party SDKs may gather and handle sensitive customer or bank information, and this may be cached in the persistent storage without encryption or without being cleared from memory after use. A backup of the device/app can potentially expose sensitive information if not adequately protected.
• Potential information disclosure due to misconfiguration: Backend service endpoints necessarily allow connections from the mobile apps. If these are misconfigured, then they may potentially leak sensitive information. A recent example was the exposure of personal data by Google Firebase. Data exposed included email addresses, usernames, passwords, phone numbers, full names, GPS information, IP addresses and street addresses.

How can we mitigate the identified security risks?

• Risk Assessment: A risk assessment of third-party components will help to determine whether using “black box” components is acceptable. Consult Hyperion’s Structured Risk Assessment (SRA) methodology is designed for just this, ensuring that technical decisions have the right business context.
• Code review and penetration testing: Source code review and penetration testing should be a standard process in any bank, employed for every release. Banks should go beyond the use of automated scanning and analysis tools. These may help in catching common issues but will not cover everything. For third party components, the options available could include reverse engineering (which is costly) or dynamic testing, where the behaviour of the component and its external communications are monitored real-time as it is used.
• Tamper detection and integrity protection: Banks should also utilise tamper and integrity protection to protect code and builds – often known as App Shielding or In-App Protection. This should cover the integration of any third-party components where possible – either separately or as a whole. By anchoring third party libraries and obfuscating their boundaries, vulnerabilities become much hard to find and exploit. This additional layer of security can safeguard mobile banking apps and provide security assurance against reverse engineering and runtime hacks.

Conclusion

Protecting the personal and financial information of customers is a fundamental responsibility of banks. Doing so in mobile banking apps is more important than ever. The use of third-party components makes this more challenging. The contract a bank has with a third party may only provide very limited protection when things go wrong and it will certainly not cover the detrimental risk of losing customer trust and business. Great care is needed therefore, when choosing, integrating and deploying third party components.  On the other hand, third party components allow banks to provide their customers with better services quicker, so it is imperative that they employ best practice to ensure they serve their customers well, maintaining their trust.

About the Co-Author

Neal Michie

Neal Michie serves as Director of Product Management for Verimatrix‘s award-winning code protection solutions. Helping countless organisations instil trust in their IoT and mobile applications, Neal oversees Verimatrix’s foundational security products that are relied upon by some of the world’s largest organisations. He champions the need to position security as a top-notch concern for IoT companies, seeking to elevate code protection to new heights by serving as a sales enabler and brand protector. Neal brings more than 18 years of software development experience and spent the last decade building highly secure software solutions, including the first to be fully certified by both Mastercard and Visa. A graduate of Heriot-Watt University with an advanced degree in electrical and electronics engineering, Neal is an active and enthusiastic participant in Mobey’s expert groups.