Although cyberattacks are more frequent in web apps, mobile apps also face serious risks. Therefore, it is essential to ensure security in application development.
With the goal of analyzing the types of attacks and risks present in the mobile world, that is, discovering different vulnerability scenarios and learning to take measures to mitigate these risks, we have turned to @arthusu, a Pentester, and Bug Bounty Hunter.
Arthusu is one of the most experienced ethical hackers in finding vulnerabilities in mobile applications. He has discovered vulnerabilities on sites such as Asus, Zoho, government entities, and banks. Additionally, he is a PHP programmer and creates automation tools.
In this article, Arthusu describes the types of attacks he has encountered in real mobile applications according to OWASP Top 10, a document that compiles the ten most important security risks in web applications according to the OWASP (Open Web Application Security Project) Foundation.
Next, we will analyze four risks according to OWASP Top 10:
It is worth noting that M1 is the most targeted category, and M10 is the least affected. M1, Insecure Authentication/Authorization, focuses on weaknesses in authentication and authorization mechanisms in a mobile application or API (Application Programming Interface).
These mechanisms are essential to ensure that only authorized users have access to certain resources and functionalities. On one hand, authentication identifies an individual, meaning it recognizes you as a user, and on the other hand, authorization verifies if the identified individual has the necessary permissions for a particular action. In other words, it determines what permissions you will have within the app.
We've identified an instance of this vulnerability where a malicious actor could impersonate a legitimate user. Many applications leverage biometric authentication, such as fingerprint recognition, for quick and convenient access. In this case, a weakness in validation was discovered, involving the use of a public script through the Frida tool.
An attacker with physical access to the device could input any fingerprint, triggering the onAuthenticationSucceeded method, falsely indicating successful authentication. This implementation flaw would grant the attacker unauthorized access to the victim's information.
To better comprehend this vulnerability, understanding key concepts related to biometric authentication in Android is crucial:
BiometricPrompt.CryptoObject: Used to encrypt and decrypt sensitive data using keys stored in the device's secure hardware.
BiometricPrompt.authenticate: Displays a dialog to the user for authentication through biometric methods like fingerprint, facial recognition, or iris scanning.
onAuthenticationSucceeded: Activated when a user successfully authenticates using a biometric method.
The attacker employs Frida to hook into the function and modify it in real-time. By inputting any fingerprint, the onAuthenticationSucceeded method is called, falsely signaling successful authentication. This grants unauthorized access to the application and its data.
Developers can secure biometric authentication by following recommended steps:
In addition to vulnerabilities in authentication, authorization also plays a crucial role in the security of mobile applications. Authorization ensures that users only access functionalities and resources for which they have the appropriate permissions. Without a robust implementation of authorization, there is a risk that users may access data or perform actions for which they lack legitimate rights.
A concerning scenario could involve a malicious actor limiting transfers for another user in the system, resulting in the denial of transfer services for the legitimate user.
Establishing Effective Authorization:
To mitigate this risk, it is essential to implement a robust access control system. This system should restrict entry to resources and functions based on user roles and privileges. Adopting a perspective based on the "principle of least privilege" ensures that users only have the necessary permissions to perform their tasks.
Validation of Identifiers:
Rigorous validation of identifiers used in requests is crucial. This ensures that users only access assigned resources. The use of random UUID identifiers makes their acquisition and improper manipulation more challenging.
M5: Improper Credential Usage Another significant threat we must address is "Improper Credential Usage," categorized as M5 in the OWASP Mobile Top 10 list.
Encoded Credentials:
If a mobile application stores encoded credentials within the source code or configuration files, it presents a clear indicator of vulnerability. Developers should avoid this practice and seek more secure methods for managing application credentials.
Insecure Credential Transmission:
Transmitting credentials without encryption or through insecure channels is another potential vulnerability. To mitigate this risk, secure data transmission should be implemented using security protocols such as HTTPS.
Insecure Credential Storage:
If the mobile application insecurely stores user credentials on the device, it exposes a significant vulnerability. Using secure storage methods, such as Android Keystore, helps protect credentials against unauthorized access.
Weak User Authentication:
Weak user authentication, based on vulnerable protocols or easily bypassed, is a clear sign of vulnerability. Developers should implement robust authentication methods, such as the use of multi-factor authentication, to strengthen the security of mobile applications.
Sometimes, developers include sensitive information such as simulated data, access credentials, and APIs in the source code, neglecting to remove them in production versions of applications.
This oversight can have serious consequences for the organization in terms of security and privacy.
Exposure of Personal Information
Automation of Delivery and Deployment:
Automating the removal of sensitive data in deployment phases helps minimize the possibility of human oversights. This ensures that production versions of applications do not inadvertently expose sensitive information.
M7: Security Misconfiguration
Security misconfigurations, categorized as M7 in the OWASP Mobile Top 10, represent another significant threat that needs attention.
Secure Default Configurations:
Ensuring that default configurations and settings are adequately protected is crucial. They should not expose confidential information or grant unnecessary permissions.
Insecure Permissions:
Avoid storing application files with overly permissive permissions, such as readable and/or writable globally. Limit the attack surface of applications by exporting only the necessary activities, content providers, and services.
We will explore another critical scenario that could lead to an account takeover through deep links in mobile applications.
Configuration of the android:order Attribute
The android:order attribute must be set to a higher number to ensure that the application always appears as the first option when handling deep links. This is crucial to prevent potential attacks that could arise from other applications taking precedence in managing these links, compromising the security of the user's account.
Recommendation Regarding App Links
Additionally, it is highly recommended to use app links instead of deep links through the web browser. This practice helps ensure that link handling occurs within the controlled environment of the application, thereby reducing the attack surface and mitigating potential security risks.
Useful References
For detailed information on how to implement and verify app links in Android, you can refer to the following resources:
In this scenario, we'll address the potential risk associated with exporting files containing sensitive information, particularly when it involves databases and passwords.
Sharing Sensitive Data Without Root Access:
Previously, databases and sensitive information could be shared with technical personnel without requiring privileged user access (root). This was facilitated through the "Share Backup" option.
However, it's important to note that the database and the JavaScript binary with Hermes were encrypted, enhancing the security of the information.
For those interested in further understanding the encryption process, the following resource can be explored:
To decompile the Hermes binary, the following command can be used:
bash Copy code hbc-decompiler assets/index.android.bundle /tmp/my_output_file.jsCopy code hbc-decompiler assets/index.android.bundle /tmp/my_output_file.js
Code Analysis
Upon analysis of the code, it was discovered that a password was required for the ZIP file.
ZIP File Password:
Considering the sensitivity of data, it is highly recommended to implement encryption measures, such as using SQLCipher. SQLCipher can be employed to encrypt locally stored data or to avoid storing sensitive information locally.
References:
For those interested in implementing secure data storage practices, the usage of SQLCipher is highly recommended. More information about SQLCipher can be found at:
In conclusion, mobile applications stand as indispensable tools in our daily lives, integrating with the growing number of technological devices that far surpass the human population.
While it's practically inevitable for these applications to face security challenges during their production phase, the key lies in mitigating their impact. It becomes clear that cybersecurity is not a destination but an ongoing process.
Enjoyed this article? Explore in-depth insights with Arthusu in our webinar 'Secrets of a Hacker' as he breaks down every detail.