Purposefully Insecure and Vulnerable Android Application (PIVAA): Part 1


This series of articles was inspired by my interest to learn more about Android mobile security. While looking for a vulnerable application to practice on, I found PIVAA. This application has a wide range of different vulnerabilities that can be examined and exploited. My focus for this series will be on the vulnerabilities found in PIVAA and I will assume that the reader will have some basic understanding about Android application structure and components.

PIVAA Background

The PIVAA application was developed as the successor to the now outdated “Damn Insecure and Vulnerable App” (DIVA). This application can be used to test mobile application security scanners and determine if the scanners can pickup the vulnerabilities present in the PIVAA application. The GitHub repository contains a list of all the vulnerabilities present in the PIVAA application (See References).

Testing Tools

I used a variety of tools to examine the PIVAA application for security vulnerabilities. I won’t be explaining how to setup these tools or every feature they offer, since there is plenty of documentation and tutorials available online. The main tools I used so far in this series to test the PIVAA application are listed below:

  • Android Debug Bridge (ADB)
  • Drozer
  • Genymotion (Free Personal Use) Emulator
  • Kali Linux Virtual Machine
  • Logcat
  • Mobile Security Framework (MobSF)


Now that I have explained what PIVAA is and mentioned the tools I will be using to analyse the application, it’s time to move on to the good stuff! For Part 1, I will be looking at the following vulnerabilities.

  • Cleartext SQLite database
  • User-supplied input in SQL queries
  • Exported Content Providers with Insufficient Protection
  • Enabled Application Backup
  • Information Disclosure through Logging
  • Storing Sensitive Data in External Storage

Cleartext SQLite database

The PIVAA application stores data in an unencrypted SQLite database.

  • Vulnerability: A malicious user or application with root privileges can access this file and view potentially sensitive contents.
SQLite Database Information for “pivaaDB”.
adb pull
pivaaDB contents
  • Use the SQLCipher library to password-encrypt the SQLite database.
  • Ensure the password used to encrypt the database is not hard coded or stored insecurely on the filesystem (e.g. shared preferences, etc.).
  • An example of how the password can be retrieved to decrypt the SQLite database file is by requiring the user to enter a password or pin when the application is opened.

User-supplied input in SQL queries

The PIVAA application allows user-supplied input in SQL queries.

  • Vulnerability: User-supplied input into SQL queries can potentially lead to a local SQL injection vulnerability in the mobile application.
SQL query to retrieve everything from the “data” table in the “pivaaDB” database.
“rawSQLQuery” method.
“rawQuery” method with no sanitization
  • Use SQL Prepared statements, which implement a pre-compiled SQL query and parameters that act as placeholders for user input which are required before the SQL query can be executed. This treats user input as data and not as commands, e.g.:
# SQL Prepared Statement Exampledb.rawQuery("select * from " + DATABASE_TABLE + " where " +  "username=? and password=?", new String [] {loginUsername, loginpass})
  • Try to sanitize input from users where possible and appropriate, e.g. if you are expecting an integer as input, then you can validate for integers only.

Exported Content Providers with Insufficient Protection

The PIVAA application has implemented an exported content provider with insufficient protections. Content providers are used to share app data with other applications, which is normally stored inside a database or file.

  • Vulnerability: Insufficient protections for exported content providers can lead to security issues such as information disclosure.
AndroidManifest.xml Exported Content Provider
Content URI
“query” method
“rawQuery” method
Application Attack Surface
Enumerate Content Provider
Content URI
Retrieve contents of “data” table from “pivaaDB” database.
  • Implement basic access control with the “android:permission” attribute in the AndroidManifest.xml file. N.B. this defines both read and write permissions to the content provider.
  • Implement principle of least privilege with separate “android:readPermission” and “android:writePermission” attributes in the AndroidManifest.xml file to specify what apps can read and write to the content provider.
  • Following the principle of least privilege, the “<path-permission>” element can be implemented in the AndroidManifest.xml file to control access to subsets of data.

Enabled Application Backup

The PIVAA application has the “android:allowBackup” attribute set to true in the AndroidManifest.xml file.

  • Vulnerability: Creating backups of an application may lead to sensitive information disclosure.
ADB Backup
Unpack backup.ab file with password
Untar file
Database recovered through backup
  • Set the “android:allowBackup” attribute to false to disable backups. N.B. If the “allowBackup” attribute in the manifest file is not set, then by default a backup of the apps data can be made.

Information Disclosure through Logging

By now, you might have noticed from looking at the snippets of source code in this article that the PIVAA application produces log messages when performing a lot of tasks.

  • Vulnerability: Logging sensitive data may expose the data to attackers or malicious applications, and it violates user confidentiality.
Logging username and password
ADB Logcat Command
Login Credentials found in System Message Logs
  • Use tools like ProGuard (included in Android Studio). ProGuard is a free Java class file shrinker, optimizer, obfuscator, and preverifier. It detects and removes unused classes, fields, methods, and attributes and can also be used to delete logging-related code.

Storing Sensitive Data in External Storage

The PIVAA application stores sensitive data on a external SD card.

  • Vulnerability: Files saved to external storage are world-readable and can be modified.
Save Login Credentials to External Storage
ADB Pull “credentials.dat” file.
Login Credentials
  • Do not store sensitive data in external storage.
  • Store sensitive data and files in internal storage. Files saved to internal storage are by default private to your application; neither the user nor other applications can access them. When users uninstall your application, these files are removed.

Closing Remarks

In part 1, I have covered just some of the different vulnerabilities that can be found in the PIVAA application. These vulnerabilities were mostly related to data storage and user privacy. I hope this has helped anyone reading to learn more about basic vulnerabilities that can be found in Android applications. Thanks for reading till the end 😄!



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


Interested in all things Cyber Security and Technology.