Diva (Damn Insecure and Vulnerable Application), which is a deliberately insecure Android application designed for educational and testing purposes, Diva contains various security vulnerabilities and weaknesses, allowing developers, security professionals, and students to practice identifying and exploiting these issues to enhance their mobile application security skills. In this blog post, I’ll talk about how to exploit common Android vulnerabilities.
Link: https://github.com/payatu/diva-android
I connect my adb. I have another blog post as to how to install and configure adb and I have root access on my emulator.
After generating the apk, I self-signed the generated apk through jarsigner, and then I installed it on the emulator via adb.
Below is the main screen.
Diva works with a process ID of 4527 and its package name is jakhar.aseem.diva.
Insecure Logging
Insecure logging is a common security vulnerability in Android applications. It occurs when sensitive information, such as passwords, personal data, or other confidential details, is written to log files without appropriate protection or redaction. This information can then be easily accessible to anyone with access to the logs, potentially leading to the unauthorized disclosure of sensitive data.
I decompiled the APK with JADX-GUI.
In the LogActivity class, I see that credit card information is logged.
Hardcoding Issues
This vulnerability occurs when sensitive data, such as API keys, passwords, or cryptographic keys, is directly embedded into the application’s source code or resources in plaintext. When these secrets are hardcoded, they become easily accessible to anyone with access to the app’s code, resources, or reverse engineering methodologies.
In the figure below, you can see that there is a hard-coding credential, and if you type vendorsecret123, it will toast “Access granted”, otherwise “Access denied”.
Insecure Data Storage — Part 1
This vulnerability takes place when sensitive data is stored on the device in an insecure manner, making it accessible to unauthorized parties. Common examples of insecure data storage include saving sensitive information, such as user credentials or personal data, in plain text files, unencrypted databases, or insecure shared preferences.
Credentials: “canozkan” “secretpassword”
In the next step, I analyze the decompiled code in order to identify the vulnerability.
I realize that the entered credentials are stored in shared preferences.
Insecure Data Storage — Part 2
The credentials are stored in the Sqlite3 local database this time.
In order to see it in a more visually pleasing way, I pulled the database and opened it in SQLite Viewer.
Insecure Data Storage — Part 3
This time, the credentials are stored in a file that starts with uinfo and contains tmp. It creates a temporary file and stores the credentials in it.
Insecure Data Storage — Part 4
This time, the credentials are stored in external storage—the SD card of the mobile device—and the file name is uinfo.txt.
Input Validation Issues — Part 1
This type of vulnerability occurs when an app fails to adequately validate and sanitize user inputs before processing them. As a result, malicious users can provide malicious or unexpected inputs, leading to a range of security issues, including remote code execution, SQL injection, or denial-of-service attacks.
We deal with local SQL injection vulnerabilities.
We are able to dump all the content in the SQLite3 database, resulting in data leakage.
Input Validation Issues — Part 2
In this part of the Android vulnerability exploitation journey, the application opens and loads the given URL, but we would not provide the expected URL such as https://google.com, instead, we want it to load something internal on the device. As there is no input sanitization, I was able to load some txt files residing in the external storage area, resulting in sensitive data exposure.
Access Control Issues — Part 1
I use the Drozer framework to gather information about the target application. Normally, the below screenshots can be achieved manually—decompile the apk via apktool and analyze the AndroidManifest.xml. Drozer does it automatically for us. Furthermore, drozer has an agent (drozer-agent.apk) on the emulator, and it acts as a third-party application malware.
diva.apk has 3 exported activities, meaning that those 3 activities can be called anywhere on the device and do not necessarily have to be within the same application.
Let’s analyze what exported activities are.
Now, a third-party application, in this case, drozer-agent.apk, would call the APICredsActivity in order to learn the API credentials.
Access Control Issues — Part 2
The exploitation is the same as the above; however, there is one parameter in this activity. Therefore, I need to give a false value for the needed parameter.
Access Control Issues — Part 3
In Android, a Content Provider is a component of the Android framework that allows apps to securely share data with other apps. Content Providers are a fundamental part of the Android content-sharing mechanism and provide a structured and standardized way to access, retrieve, and manipulate data stored within an app’s private data storage or even external data sources, like databases or files.
In this application, the content provider is not adequately secured. Therefore, any application, whether it is malware or benign, can access the data available through the content provider.
Command: adb shell content query — uri content://jakhar.aseem.diva.provider.notesprovider/notes/
Hardcoding Issues — Part 2
In this phase, I realized that the application imports a library. As it is a low-level .so library, we cannot reverse engineer it via JADX-GUI or any other Android decompiler and disassembler. This is where IDA comes into play, and since I don't have an IDA PRO, I used IDA free.
In IDA, I see a method with the name of access; there is a comparison operation at the assembly level. The string is highlighted.
This work has been supported in part by the Energy Transition Fund of the FPS Economy of Belgium through the CYPRESS project, and in part by the VLAIO COOCK program through the IIoT-SBOM project.
Thanks for reading.
Can Özkan
