We Analyzed 31 Neobanking Apps and Found a Range of Security Issues
Neobanking has recently become a buzzword in the fintech world. On a global scale, Neobanks are taking over the fintech industry. A Neobank is a type of digital bank that does not have physical locations. Neobanking does not require you to be physically present at a specific location to carry out transactions. According to statista, the number of users is expected to amount to 344.73 million users by 2025 and the transaction value in the Neobanking segment is projected to reach the US $3,991,848 million in 2022.
CloudSEK’s BeVigil, a security search engine, scanned widely used Neobanking apps and found a wide array of security vulnerabilities leading to exposure of secrets/sensitive data, dangerous permissions compromising user’s security, and found trackers in apps resulting in severe privacy compromises. Thousands of banking-related apps have been submitted so far for scans on the BeVigil platform to date, hundreds of them being Neobanking apps in use worldwide. This study focuses on 31 such apps operating in South Asia, especially India. Most of the security issues found were repetitive in most of the applications. This report serves as evidence of how these vulnerabilities can end up severely affecting millions of users. Therefore, it is imperative that app developers address these security concerns to prevent compromising their users’ sensitive information.
Neobanks, Digital Banks, Traditional Banks, and E-Wallets
Neobanks are fundamentally different from traditional banks in every way, from business methods to client service. Here are some comparisons between Neobank and regular banks. Traditional banks, as previously said, have a physical banking service platform and branches, whereas Neobanks are entirely digital mobile apps (with no branches). Traditional banks have additional overhead costs (rents, energy, etc.) that they collect from consumers in the form of bank statements, bank notifications, and other services. Neo banks, on the other hand, have low costs and are transparent. Traditional banks must have a full banking license, whereas Neobanks can have none, partial, or full banking licenses.
A more detailed comparison can be seen in the table below.
|E–wallet||Neobank||Digital bank||Standard bank|
|Max deposit||Small||Medium||Large||Very Large|
|Target market||Unbanked, Youngsters, Digerati||Underbanked, SME/SMB, Young Adults||Medium-Sized Businesses, Niche Markets||Institutions, Large Businesses, General Public|
Those who are familiar with the term “digital banks” may be asking what the difference is between them and NeoBanks. Digital banks are a sort of fintech, which is a mix of two words: ‘financial’ and ‘technology,’ just like the term ‘NeoBank.’ Users can deposit, withdraw, transfer, borrow, and do a variety of other banking-related functions with their money using digital banks, which are quite similar to NeoBanks. They also tend to focus on certain niches, such as small enterprises.
What’s the difference between NeoBanks and digital banks, exactly?
Digital banks tend to exist as a branch or root of a bigger (conventional) bank, whereas NeoBanks are stated to be independent and not affiliated with a traditional bank.
Neobanking App Services
The following are some examples of NeoBank services:
- Opening a bank account, either a checking or a savings account
- Loans and other financial services
- Transfers to people or businesses
- Investing and purchasing insurance
These apps collect user data to verify their identity, usually through a process called KYC (Know Your Customer). For example, the app PayTM asks for your Aadhar card detail as a part of this process. Certain apps also ask for additional information like PAN card and driving license details.
Social engineering, malware, and phishing/pharming are the three main cybersecurity dangers that NeoBank and other forms of digital banks face. These are threats aimed at gaining access to a user’s personal information, bank account cash, or other potentially destructive acts.
Phishing is one of the most deceptive security dangers, which involves creating a false or “spoof” website with the same or almost the same name as the genuine website in order to collect login credentials. A user may be offered a link to a phony NeoBank website (that appears just like the real one), after which they will be asked to provide their login information. The user can then enter information like their banking usernames, passwords, and PINs, among other things.
The most terrifying part is that there isn’t much NeoBanks can do, as the key remedy is to educate their client base about these hazards. The increased use of technology leads to an increase in technical risks, which are plentiful. Though the chances of your banking information being stolen are extremely remote, it is nevertheless feasible and more likely to occur than if you used a traditional bank.
Analyzed Neobanking Apps
|Application Name||Application ID||No. of Downloads||BeVigil Score|
|Razorpay Payment for Business||com.razorpay.payments.app||100K+||8.2|
|Bharat by Niyo||com.niyoblue.customer||1M+||6.8|
|Niyo Global by DCB||com.niyo.global||100K+||8.0|
|Niyo Global – Card and Digital Savings Account||com.niyo.sbm||10K+||7.6|
|Salt Delivery Partner App||com.salt.delivery||10K+||8.5|
|Salt- Shop from your favorite local store’s||com.salt.customer||10K+||7.5|
|Open: Business payments made super fast & easy||co.bankopen.open||100K+||8.3|
Distribution of Vulnerabilities
|Issue||Severity||No. of Apps|
|Non-Parameterized SQL Query||Medium||70%|
|Sensitive Information in Logs||Medium||35%|
Function: WebView allows us to display content from the web directly inside applications.
Mitigation measure: 93.5% of apps were performing more than 1 of the below resiliency check, which includes:
- “Checking of rooted devices”
- ”SSL pinning by app”
- ”Frida Server Detection”
- ”Use of SafetyNet API for device integrity check by app”
- Few apps were using an obfuscator to prevent reverse engineering. Code obfuscation helps modify the source code of an application, such that it is no longer readable while sustaining the functionality of the code.
Function: Hardcoded strings are secrets or credentials that are directly included in an application’s source code.
- Risk: Hackers can decompile/read the source of the application and obtain these secrets easily, leading to data leaks.
- 13% of apps were storing API credentials in base64 format which is equivalent to storing it as clear text.
- Few other apps were leaking several API Tokens and Secret Tokens that could be used to interact with the backend of the applications and extract information. According to a recent article by us: “0.5% of mobile applications contain AWS API keys which have resulted in the exposure of 100M+ users”. Because this estimate solely considers AWS API keys, that amount is undoubtedly more than 0.5 %. There are a lot more sensitive keys that shouldn’t be hardcoded directly.
- Mitigation measure: Common ways to detect/prevent hardcoded secrets are:
- Using automated analysis/auditing tools to detect secrets in code
- Ensuring secrets are only included in the backend, and not client-side
- Using tools like dotenv to store details in the environment.
Exposure of Sensitive Assets
Function: Applications use these 3rd party services such as Firebase, Google Cloud Storage, AWS S3 Buckets, and Azure Buckets to store their sensitive assets
- Risk: Sometimes due to developers’ negligence, some of the storage platforms are left open to the public, resulting in the exposure of sensitive data.
- Some apps were using an AWS S3 bucket which was open to the public to store data. A bucket is normally termed “public” if any user may list its contents, and “private“ if only specified S3 users can list or write the bucket’s contents. Any user who inquires about a public bucket will be given a list of all of its files and directories. Moreover, some apps were found using a publicly accessible Firebase Instance to store data.
- Mitigation measure:
- Create proper ACL (access control) rules for storage buckets to limit/deny public access.
- Conduct security reviews of al infra resources to evaluate their ACL rules.
Function: Permissions are required by mobile applications to access user data / extended functionality of a users device
- Risk: As one can expect, Android permissions are dangerous because, even though their purpose is to protect users, they can compromise the device, its resources, and the data stored on it, if they are granted to a malicious application.
- 16% of apps request the“System Alert Window” permission, which is dangerous severity permission that allows an app to show content on your Android device’s screen in response to a trigger event. A leading security content platform explains: “this functionality can be abused to display fraudulent ads and overlay windows — a common technique used by banking Trojans that create windows identical to a banking app’s login page, as well as ransomware that places a persistent on-top screen.“
- Some apps request the“Read Calendar Permission” which is usually not required by payment apps and can enable monitoring user activity.
- Some apps request permissions such as “Call Phone” and “Bluetooth Admin,” which ordinarily are not required by payment apps and create privacy issues.
- Mitigation measure:
- Apps should be used with discretion since malware, botnets, and other malicious programs can be deployed on devices via the apps installed on them. Use trusted and approved app stores to download apps and avoid downloading apps which are available only on unknown or third-party app stores.
- Before you download and install anything, make sure you check the app permissions via services such as BeVigil. Always read app descriptions and Permissions details to be aware of what an app requires access to.
Privacy Compromise – Trackers And TPLs
Function: Companies use trackers to identify an individual, monitor their activities, and then monetize that app through targeted advertising and by selling it to third parties. The majority of the third-party libraries used by the applications are for advertising, social media, and analytics.
- Risk: Trackers are a major privacy concern as they allow apps to collect private user data (in most cases unknowingly). This data is often sold to third parties who can then gain access to sensitive information.
- Mitigation measure:
- Adjust your browser’s privacy settings: modern browsers like Chrome, Firefox, Brave have dedicated features to block trackers.
- Disallow cookies on your browser as most trackers come from these.
- Be extra aware about visiting less trusted websites.
APKs Backend Analysis – Log4 Shell Vulnerability
Function: Log4j is a popular logging framework used by many java applications.
- Risk: Log4 Shell vulnerability (CVE-2021-44228) can allow remote code execution on the affected systems, poorly secured backend APIs, and hosts powering the apps.
- CloudSEK scans have identified that 22% of Neobank companies have backend APIs affected by CVE-2021-44228 (Log4 Shell). Log4 Shell vulnerability can allow remote code execution on the affected systems, poorly secured backend APIs, and hosts powering the apps.
- The log4j security vulnerability allows attackers to execute malicious code remotely on a target computer. Meaning, bad actors (hackers) can easily steal data, install malware, or simply take control of a system via the Internet. 71% of these companies which are affected by log4 shell vulnerability are Indian companies.
- Mitigation measure:
- Update to version 2.17.1 or above of the log4j library.
- Perform proper input validation on user strings input.
- Note: This research follows the guidelines of CloudSEK’s Responsible Disclosure Policy (Please check Appendix for complete details)
The Way Forward
Given that Neobanks are entirely digital, they provide customers with a wide range of benefits like speed, convenience, cost savings, etc. However, in this digital era, the sensitive information of users is highly risked. Most developers tend to overlook these security issues which can result in the next Neobank heist. These vulnerabilities can be mitigated by adding continuous and comprehensive security review frameworks within the development lifecycle.
CloudSEK’s Responsible Disclosure Policy
- We ensure that we do not cause any damage while the detected vulnerability is being investigated. Our investigation must not, in any event, lead to an interruption of services or lead to any details being made public of either the asset manager or its clients.
- We do not place a backdoor in an information system in order to then demonstrate the vulnerability, as this can lead to further damage and involves unnecessary security risks.
- We do not edit or delete any data from the system and do not introduce any system changes.
- We do not try to repeatedly access the system and do not share the access obtained with others.
- We do not perform physical testing on any vulnerable devices that we identify.
- All the vulnerabilities found during this research were reported to the respective countries’ CERTs (Cyber Emergency Response Team) via proper channels. We also provided significant time for them to respond to these findings before publishing this paper.