Product security for one of the biggest African banks

Initial risk assessment and rapid threat modelling

We held a risk assessment and threat modelling workshop together with the bank's security and product teams. It enabled us to identify the most important risk factors, understand the risk appetite, align the vision with the bank's security team, and determine which parts of the dataflow required "basic" security protections and defence-in-depth.

Risk assessment offers a structured framework for the application security assessment, ensuring that the app remains resilient and all crucial features are covered.

We concentrated our efforts on high-risk events:

• Direct financial risks, financial fraud
• Indirect regulatory risks
• Data privacy regulatory risks, user PII leakage
• Account hijacking risks

The results of dataflow analysis and data classification can be used to recommend appropriate security controls to protect sensitive assets.

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.

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).