Security impact:What is Impact if application is only signed with V1. The v1 signature is considered less secure compared to the v2 and v3 signature schemes. It lacks some of the modern security features incorporated in the later versions, making the app potentially more susceptible to certain types of attacks.
After extracting the APK Open that APK with JADX-GUI look in APK Signature Valid APK Signature Scheme v1, v2 ,v3 Android app signing
If the Android exported attribute of a component in the AndroidManifest.xml file is set to true when it should be false it can have significant real-life security implications.
ARActivity
SplashActivity
Bug:Activity Export Enabled
Description: Certain activities in the AndroidManifest.xml file are marked as exported, allowing other applications to interact with them. If these activities lack proper access control, they may expose sensitive functionality.
Security impact:
1. Unauthorized Access: Setting exported to true makes the component accessible from other applications or entities, potentially allowing unauthorized access to sensitive functionality.
2. Data Leakage: Components with improper export settings may expose sensitive data, leading to data leakage. This could include exposing content providers, services, or activities that should be restricted.
3. Security Breaches: Malicious apps or attackers could exploit the exposed component to perform actions that should be restricted, leading to security breaches, unauthorized control, or even remote code execution.
Security impact: Enabling allowBackup by setting it to true in AndroidManifest.xml allows data backups for the app. While convenient for users, it poses security risks, exposing sensitive data and creating potential vulnerabilities. Attackers may target stored backups, compromising data integrity and violating privacy regulations. It's advisable to assess the necessity of backups, encrypt stored data, and ensure secure storage practices to mitigate these risks effectively.
Security impact: Setting debuggable to true in the AndroidManifest.xml file allows the app to run in debug mode. While useful for development, it poses security risks in a production environment. Debuggable apps may expose sensitive information, making them vulnerable to reverse engineering and unauthorized access. To enhance security, set debuggable to false for production builds, reducing the risk of potential exploits and data exposure
Open manifest file. Check for Cleartext traffic is set to true: like
android:usesCleartextTraffic:"true"
Bug: Cleartext Traffic Enabled
Security impact: Setting android:usesCleartextTraffic to true in the AndroidManifest.xml file allows the app to send unencrypted (clear text) network traffic. This poses a security risk as sensitive information may be exposed during transmission. To enhance security, it is recommended to set usesCleartextTraffic to false and use secure communication protocols such as HTTPS to encrypt data in transit, preventing potential interception and unauthorized access.
Search in code OR Open resources/values/strings.xml file. Check for setJavascriptEnabled =true
Settings.setJavaScriptEnabled is enabled which can be used for javascript-based attacks.
Bug: JavaScript Enabled in WebView
Description: The WebView component has JavaScript enabled, which can execute untrusted code within the application context. This makes it vulnerable to JavaScript-based attacks if not properly secured.
Security impact: An attacker could exploit this misconfiguration to execute malicious JavaScript code, steal sensitive information, or exploit additional vulnerabilities in the application. This could lead to data breaches or unauthorized actions in the app.
Reference:Exploit XSS with WebView https://medium.com/mobis3c/exploiting-android-webview-vulnerabilities-e2bcff780892
Search in codehttp://because Application using http:// instead of https:// which is secureSearch Specialy in this Path: assets/www/components/alerts/alerts-action/alerts-action.js
Bug: Insecure Communication
Description: The application communicates with remote servers using unencrypted or insufficiently protected channels, such as HTTP instead of HTTPS. This allows data to be transmitted in plain text across the network.
Security impact: Insecure communication can be intercepted by an attacker positioned on the network (e.g., via a Man-in-the-Middle attack). This can lead to exposure of sensitive user data, session hijacking, or credential theft. If attackers gain access to this unencrypted data, they may use it to impersonate users, escalate privileges, or carry out further attacks.
Search in code java.util.Randomclass to generate random numbers beacuse Application is using Random function instead of SecureRandom which is secure.
Bug: Use of Insecure Random Values
Description: The application relies on the java.util.Random class to generate random numbers. This method is not designed for cryptographic purposes and produces predictable sequences, making it vulnerable to brute-force and replay attacks.
Security impact: Predictable random values can lead to unauthorized access, token manipulation, or replay attacks.
Search in code SHA-1 and MD5Application using SHA-1 weak hashing algorithm and Application using MD5 a vulnerable hashing algorithm
Bug: Weak Hashing Algorithms
Description: The application uses cryptographic hashing algorithms considered weak, such as MD5 and SHA-1, to secure data. These algorithms are vulnerable to collision attacks, where two different inputs produce the same hash value, and are no longer deemed secure for cryptographic purposes.
Security impact: The use of weak hashing algorithms compromises the security of sensitive data, such as passwords, tokens, or user information. Attackers could exploit these weaknesses to generate hash collisions, recover plaintext data, or impersonate users, leading to potential unauthorized access and potential data breaches. This could undermine user trust, harm the organization's reputation, and result in non-compliance with data protection regulations.
Search in code BUILD_TYPE = "release"Release build Applicaiton code isn't obfuscated, can be decompiled to retrieve the clear code from the application
Bug: No Code Obfuscation
Description: The Android application lacks strong code obfuscation, making it relatively easy to reverse engineer using tools like JADX or APKTool. This allows an attacker to decompile the APK and gain access to readable source code, class names, method names, and even sensitive logic or hardcoded values.
Security impact: The absence of obfuscation exposes the inner workings of the app, increasing the risk of intellectual property theft, discovery of vulnerabilities, and the extraction of secrets such as API keys or cryptographic material.
Search in code WRITE_EXTERNAL_STORAGE Application is allowed to store data on external storage.
Search in code getExternalStorageDirectory Application data can be stored on the external directories.
Bug: Insecure External Storage Access
Description: This permissions allow the application to access and modify files on the device's external storage. If not implemented securely, this can expose sensitive user data to potential misuse or unauthorized access by malicious actors or other applications.
ISO/IEC 27001:2022 – Control A.8.11 (Data Masking)
Remediation: To mitigate this issue, follow the principle of least privilege by requesting only the necessary permissions. Use Android’s Scoped Storage model (introduced in Android 10) to limit access to app-specific directories and media files. Encrypt sensitive data before storing it on external storage.
