Mauritania has recently experienced incredible growth in digital payment solutions (ewallets). At TIDUM, we consider evaluating these applications from a security perspective as a public service for the consumers and developers behind these applications. Our main motivation is to increase consumer confidence in these solutions and to help developers improve the quality of their solutions. From a selfish point of view, these kinds of assessments are an intellectual exercise that we enjoy as security researchers.

In this blog post, we present a high-level summary of the security assessment we conducted. We will not disclose any vulnerabilities that may exist in these applications to prevent a bad actor from exploiting them.

The study covers the four oldest e-wallets available on the market. These applications offer similar (or even identical) business functionalities but differ in the technologies used and the maturity of the developers behind them. The technologies used for the development of these applications are mainly:

• Client Side
  • Flutter
  • React Native
  • Native (IOS and Android)
• On the backend side
  • Python
  • Java

Methodology

We are basing our assessment on the reference security standards and best practices published by world renown organizations such OWASP, SENSE, PCI SSC and ETA. All of this organization concord that good mobile applications security should cover the three following area:

1. Software Security
2. Security policies
3. Infrastructure security and monitoring

Software Security

Prevention is better than cure.

The main objective here is to have prevention mechanisms implemented at the software level. This will help the application reduce its attack surface. The main techniques used to achieve this are:

• Data encryption: the application must use HTTPS to ensure that all exchanges with the server are encrypted.
• Extra Data Encryption: The application should encrypt the data it exchanges with the server using strong encryption, primarily asymmetric encryption. This is especially necessary to protect user data in the event of a successful MITM attack.
• Certificate validation: the application must verify the identity of the certificates it receives from the server. The best technique is to have the application implement a certificate pinning technique. This will raise the bar for attackers using MITM.
• Multi-factor authentication: the application must use more than one factor to authenticate the user. At least a password and a one-time password.
• Reverse engineering protection: the application must use obfuscation techniques to make the work of reverse engineers more difficult. In addition, the application should not store any sensitive data or configuration in the clear.
• Anti-Tampering: The application must implement a defense against bot attacks (eg virtual keyboard, smart recaptcha, etc.).
• Device Fingerprint: The app must generate a unique fingerprint of the device it is installed on. This fingerprint needs to be verified by the backend to verify if the transaction is from a legitimate customer.
• Insecure design: The application must implement a logical business workflow that does not compromise its security measures. In particular, the PIN/password recovery policy and the multi-device management policy should not override the application’s global security policies.

Security policies

Humans are the weakest link in cybersecurity.

In addition to building security measures into the application code, security policies are needed to reduce the risk that can be created by having publicly accessible applications. The e-wallet application is used by a wide variety of people (not necessarily people aware of security risks) and the needs for usability and simplicity can sometimes take precedence over security requirements. For these types of applications, it is important to implement security policies and review them continuously. The most important policies are:

• PIN/Password Policy:
  • What are the requirements for PIN/password length and complexity (numeric or alphanumeric)? This policy will impact how a PIN/password can be automatically guessed.
  • How many attempts are allowed with the wrong PIN/password? This policy determines how easily a PIN/password can be guessed.
  • What is the account lockout policy when a wrong PIN/password is attempted multiple times?
• OTP Policy:
  • How long does an OTP remain valid? The shorter the better.
  • What is the length of a OTP? The length determines the number of possible attempts and combined with the validity policy, it can have an impact on the probability of success of the automated guessing of the OTP.
  • How many wrong attempts are allowed for an OTP before an account is locked
• Password Reset Policy:
  • Does the PIN/password reset process include the use of an OTP?
  • Does the PIN/password reset process include an additional layer of authentication such as a security question(or questions)?

Infrastructure Security and Monitoring

Cybersecurity is like an Onion, there’s layers …

In the age of web applications, it is recommended that any security implementation follow a layered approach. One of these layers should cover the following tools and measures:

• WAF: must be in place to detect automated actions such as brute force or suspicious payload or DOS attacks.
• Monitoring: the application must warn the user in the event of suspicious access to his account.
• Infrastructure hardening: keeping the system and application up-to-date and exposing only necessary ports/services.

Findings

For the purposes of this assessment, we have studied, in the light of the above methodology, the vulnerability of four e-wallets to the most common attacks. The assessment was conducted on versions of these applications that were publicly available before the end of October 2022. This produced the following compliance table. In this table, we use a 0-5 ⭐ rating scale to rate each of the security policies and measures:

• . : means that the security is not implemented at all
• ⭐: means that the implementation is Very weak
• ⭐ ⭐: means that the implementation is Weak
• ⭐ ⭐ ⭐: means that the implementation is Correct.
• ⭐ ⭐ ⭐ ⭐: means that the implementation is Good.
• ⭐ ⭐ ⭐ ⭐ ⭐: means that the implementation is Excellent.

	EWX1	EWX2	EWX3	EWX4
Application Security
Data encryption	⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐
Extra Data Encryption	.	⭐ ⭐ ⭐ ⭐	.	.
Certificate validation	⭐ ⭐	⭐ ⭐ ⭐	⭐ ⭐ ⭐	⭐ ⭐
Multi-factor authentication	.	.	⭐ ⭐ ⭐ ⭐	.
Reverse engineering protection	.	⭐ ⭐ ⭐	.	.
Anti-Tampering	.	.	⭐ ⭐	.
Device Fingerprint	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	.	.
Insecure design	⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐
Security policies
PIN/Password Policy
Complexity	⭐ ⭐	⭐ ⭐	⭐ ⭐	⭐ ⭐
Attempts	⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐
Lockout	⭐	⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐
OTP Policy
Expiration	.	⭐ ⭐ ⭐	⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐
Complexity	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐
Attempts	.	⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐
Password Reset Policy
OTP	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐	.	⭐ ⭐ ⭐ ⭐ ⭐
Security question	.	⭐ ⭐ ⭐	.	⭐ ⭐
Infrastructure Security and Monitoring
WAF	⭐ ⭐	⭐ ⭐ ⭐ ⭐	.	.
Monitoring	.	.	.	.
Infra hardening	⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐

Based on this assessment, we have found that all applications are vulnerable to a denial of service attack. Providers must ensure that they are able to detect and respond to these attacks quickly to prevent the disruption of their customers’ financial activity. This is essential because conducting these attacks requires few resources and the resulting disruptions could lead to loss of money. Another major finding, in the case of at least two apps, is that OTP authentication can be bypassed and PIN passwords can be guessed using brute force. We recommend here that prevention and monitoring solutions be put in place to mitigate the risk associated with these findings. The following table lists the summary of the major findings by applications.

	EWX1	EWX2	EWX3	EWX4
Deny Of Service	❌	❌	❌	❌
OTP Bypass	❌			❌
PIN brute Force	❌	❌
Unauthorized PIN reset	❌			❌
Hardcoded sensistive data				❌

Conclusion

Security is a continuous process. The assessment we conducted here is a black box assessment. It aimed to test the basic security of the e-wallet application. We are glad that we did not find any critical vulnerabilities, but this cannot guarantee the absence of such vulnerabilities. With the emergence of APT groups and their growing interest in developing countries, the presence of any vulnerability, no matter how critical, can lead to the complete compromise of a system.

We recommend that product owners of these e-wallets not only conduct a comprehensive assessment of their application, but also of their internal corporate networks. A compromise of these networks can be the first step in an attack leading to the compromise of the e-wallet application. There is also a need to implement a continuous security monitoring solution. This will give them visibility and help them detect attacks in advance and respond to security incidents in a timely manner.