Matomo

Product security for one of the biggest African banks | Cossack Labs
Case studies
Product security for one of the biggest African banks

Product security for one of the biggest African banks

APR - JUL 2023 Banking Mobile Security assurance
Product security for one of the biggest African banks

Overview

The name of the bank is REDACTED: The main purpose of this story is to share practical experience for engineers who work on secure app development to avoid fraud, enhance security controls and provide quality customer service.

Digital wallets are mostly used to store personal funds and conduct peer-to-peer transactions, whereas banking apps offer a broader variety of services (payments, credits, and deposits) on their own, and act as a "front-end" to banking services.

Banking applications security combines mobile platform security, reverse engineering protections, API security, infrastructure and backend services security, anti-fraud measures and user education. At the same time, banking applications should be user-friendly, reliable and fast.

Industry

  • Banking
  • Financial Service Authority

Technology stack

  • iOS Swift
  • Android Kotlin
  • Windows-based backend

Regulations

  • Typical fintech security requirements, PCI DSS
  • Data privacy regulations
  • Encryption export regulations

Challenges

[01]

KYC for enhanced authentication

KYC (Know Your Customer) is an effective method of validating the user's identity by requesting a selfie video from the user's phone. A user should upload their documents to create an account, and then the system matches the video to the documents to complete the app setup. Making this feature user-friendly is the primary challenge to avoid poor user experience.

[02]

Device binding

A particular smartphone is linked to a specific user account. When users log into the app from a different phone, they must repeat the KYC validation process. This requirement is hard to get right, but it is essential for mobile app's security posture.

[03]

Data privacy and fintech regulations

We analysed the requirements from data privacy regulations of African countries' (including NDPR and Lagos data privacy bill), financial and banking regulations (PCI DSS, rapid payment standards) to recommend appropriate security measures to ensure that users’ activities do not cause financial damage to the bank.

[04]

Balanced UX and security of authentication

The app implements multiple authentication factors but it skips particular authentication steps to improve UX if the device and the user are already known to the system. The challenge is to ensure that an unauthorised user cannot bypass the checks.

Technology requirements

Technology requirements

Support old phones

85% of bank clients use Android phones, many of which are old devices with significantly outdated operating systems, heightening security risk. The outdated OS does not have newest security patches which increases the attack surface and makes devices easier to exploit. The new banking app should work on older phones yet provide adequate security guarantees.

Consistent security for iOS and Android

New mobile applications are native, built in Swift and Kotlin, and have an independent code base. Security controls should be consistent across apps while being tailored to each operating system's weaknesses and strengths.

Device trust

Device binding works well only on trusted devices. Device trust controls include protection against reverse engineering, detection of rooted/jailbroken smartphones and specific OS exploits, and confirmation that the app is installed from the official AppStore / Google Play.

Anti-fraud and anti-abuse system

Great popularity among users attracts a massive amount of financial fraud. The fraud prevention team at the bank has shared details about previously seen fraud cases. We have suggested many recommendations to improve the anti-fraud system based on the user behaviour inside the app.

Our approach

Mobile-specific expertise

Our expertise in security engineering, coupled with understanding of the challenges of different mobile phones and mobile OSs, enabled us to find effective solutions, tailored to the specific risks and requirements.

Data lifecycle focus

We treat mobile apps as a gateway to a larger system. Our expertise extends to designing secure APIs, authentication mechanisms, reverse-engineer protections, mobile-specific controls to ensure the protection of all user assets throughout the data lifecycle.

Proactive security measures

While it is tempting to focus on reactive controls, a bank cannot afford to limit themselves with chasing thieves. Taking preventive measures, combining them with detective and reactive controls, proved to be effective in mitigating risks and vulnerabilities.

Engineer-to-engineer collaboration

Regular collaboration with security engineers is essential to get the optimal security impact. It is ineffective to just point out what is wrong. We usually make certain that whatever is necessary (explanations, workshops, code), gets done to reach a shared understanding of security posture and its problems.
Our approach

Solution

Banking apps are a gateway to the big bank system. That's why we started with analysing risks and threats, defining sensitive assets and their lifecycle, discussing current fraud cases with the bank's financial monitoring team. Only after that we performed deep and extensive security assessments of the iOS, Android apps and mobile API services.

Initial risk assessment and rapid threat modelling

The results of dataflow analysis and data classification can be used to recommend appropriate security controls to protect sensitive assets.
  • Direct financial risks, financial fraud
  • Indirect regulatory risks
  • Data privacy regulatory risks, user PII leakage
  • Account hijacking risks
A fragment of data classification for assets appeared on the mobile application.
A fragment of data classification for assets appeared on the mobile application.

Mobile security validation, CL MSS

To ensure that mobile applications address security edge cases and to measure the impact of security work during application development, we use Cossack Labs’ Mobile Security Score (CL MSS).
Mobile Security Score (CL MSS) is a custom-tailored to risk model set of requirements that includes relevant requirements from OWASP MASVS v1.5, ASVS v4.0.3, MITRE ATT&CK.
We have covered 100% of basic requirements, and 89% of advanced requirements.

Mobile application security and platform trust assessment

  • We began our mobile application security assessment by analysing data storage, authentication and platform interactions. A major concern was that the application stored too much user data in plaintext. This could lead to privacy issues and data leaks. We proposed reducing the amount of stored data, isolating data between users, and incorporating application-level encryption for the remaining data.
  • Mobile applications should include several security controls: Blurring the application screen to hide sensitive data when the user is switching between apps; restricting access for 3rd party keyboards; and cleaning up all stored data in case of suspicious user activity.
  • Old devices, gadgets with outdated OS, compromised Android and iOS phones pose risks to users and the bank. It is important to identify such devices and limit the features of the application, including blocking the app’s screen.
  • We suggested platform-dependent controls for pre-release hardening, like removing logs, shrinking resources, ensuring that test and staging data is not available in the production app.
crucial and high issues

API security

  • First, we focused on authentication and access control, to ensure that user A could not bypass authentication, or gain access to the user's B account and cards. We simulated various scenarios, such as “as a user, I have lost my phone, and someone has picked it up and is attempting to access my banking data”.
  • Next, we assessed financial transactions to see if it was possible to replay transactions, change the payment destination, change the amount, transmit more funds than the user had, or trigger an overflow of user funds.
  • Next phase was to attempt to harvest data by exploiting features “find users by phone”, “find nearby users”, and “invite contact to the bank”. These seemingly innocent features could be used by attackers to collect a database of active bank users.
  • Mobile developers have implemented the TLS certificate pinning. However, they have not considered what happens when the backend team reissues the TLS certificate or when it expires in 90 days. If the certificates mismatch, the app will stop working. We advised administrative and technical security controls to ensure reliability of the app in the long run.
  • We devoted special attention to the transport security configuration. For example, banking infrastructure supported TLS 1.0. We insisted that the bank limit TLS support to TLS 1.2 and 1.3 only.

Protecting the application itself

Malicious actors can build a copy-cat application, upload it to the app store, and deceive users into entering their credentials into the fake app.
While it is impossible to prevent such actions, we proposed reverse engineering protections to make debugging and decompilation more difficult. The next step is to educate users on how to identify a real application and provide them with a bank support line that can quickly block accounts.
We recommended the Force Update feature. This way, if the app has a critical security flaw, the development team can release a new version of the app that forces users to update. When a user opens the app, they will see a message about the critical update and a button that directs them to the app stores to install the fix.

Anti fraud system

  • The bank’s security team already has anti-fraud measures in place, but mobile applications considerably increase the attack surface - and introduce new ways to commit fraud.
  • We proposed capturing more events from the application, such as attestation checks (detecting debugger, emulator, and installations from unauthorised sources), user events (entering the wrong password), system events (changing biometrics in settings, using an outdated OS version) etc.
  • We also suggested enhancements to the device binding logic. The backend will now detect when a user switches between different phones or when several users use the same phone, and will require the user to restart the KYC validation process.
  • The backend team has been instructed on improving the anti-fraud measures.

Future product security work

Following the assessment, we created a list of advanced security improvements for the upcoming apps releases. These improvements, which address application security, operations security, and regulatory compliance, have been added to the product backlog.
  • Not all controls are sophisticated technical exercises. To invite willing security researchers to contribute, we suggested the bank add a Vulnerability disclosure policy, and use security.txt as a way to cooperate with security researchers. From now on security researchers can easily contact the bank directly from the app.
  • Given the fact that the app is uploaded to the App Store and Play Market, the bank became a subject of US Cryptography Export Regulations compliance. We have recommended a process for creating, sending and updating the self-assessment reports.
  • As security doesn’t end with a single assessment, we have outlined and strongly recommended development teams to follow the Secure Software Development Life Cycle (SSDLC).
The status of banking applications after security assessment and one month of issues fixing by the development team.
The status of banking applications after security assessment and one month of issues fixing by the development team.

Results and outcomes

Having successfully passed the Beta testing stage, the bank released their new app to the public. It is still too early to tell how effective the new fraud detection system is, but there has not been a significant increase in fraud so far.

Our security engineers walked the backend and mobile teams of the bank step by step, answering their questions and searching for optimal solutions. We recommended security controls that met the needs of both the product and security teams, while still being user-friendly.

The security posture of the bank application has improved significantly after months of hard work. After fixing the discovered issues, the security score increased by a factor of two, covering all basic security requirements and implementing some of the advanced ones. We worked with the bank team, aiming for “root cause” decisions on security weaknesses. After a vast portion of phone calls, design sessions, discussions with product, engineering and anti-fraud bank teams, we managed to find optimal solutions to the existing problems.

We are experts in proactive product security. We filled the backlog of both the mobile and backend teams with security improvements for months ahead. This will ensure that security remains a priority even after our cooperation ends.

Up next

Got a challenge that's still standing?

Let’s start a conversation.

Start a conversation

Get whitepaper

Apply for the position

Our team will review your resume and provide feedback
within 5 business days

Thank you!
We’ve received your request and will respond soon.
Your resume has been sent!
Our team will review your resume and provide feedback
within 5 business days