Purposefully Insecure and Vulnerable Android Application (PIVAA): Part 1
This article is the first part in a series that will cover some of the different vulnerabilities present in the “Purposefully Insecure and Vulnerable Android Application” (PIVAA).
Disclaimer
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)
Introduction
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.
Performing static analysis on the PIVAA Java source code recovered by MobSF, I found a file called “DatabaseHelper.java” and I can see that the application uses an SQLite database called “pivaaDB”.
On Android, all applications (root or system) store their settings, database, etc. in the “/data/data/<package_name>/” directory. I can easily retrieve this database file from my Android emulator testing device using the ADB “pull” command and the file path for the database file.
I can then view the unencrypted database contents using a tool such as SQLitebrowser.
I can see the table name and the column names match the names found while statically analyzing the “DatabaseHelper.java” file. The contents of the database are also readable.
Recommendations:
- 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.
I can interact with the “pivaaDB” database mentioned earlier by using the application and inputting SQL queries.
Looking at the Java source code, I can see that my query is being passed as an argument to a function called “rawSQLQuery”.
Taking a closer look at this function, I foudd that my query is being executed by the “rawSQL” method available in the SQLiteDatabase class.
As we can see, my entire query is being executed and no sanitization is being performed.
Recommendations:
- 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.
Looking at the AndroidManifest.xml file for the PIVAA application, I can see the content provider that has been exported.
Performing some static analysis on the activity called “ContentProviderActivity.java” file, I found a content URI (Content Provider URI’s begin with “content://”). This can be used to reconstruct a path that can retrieve data from the content provider.
You will notice that the “query()” method is used to process our input. Analyzing another file called “VulnerableContentProvider.java”, I can see that the “query()” method passes our input to another method called “rawSQLQueryCursor()” which is found in the “DatabaseHelper.java” file mentioned earlier in the article.
Looking at the “rawSQLQueryCursor()” method, I can see that my query is being executed using the “rawSQL()” method available in the SQLiteDatabase class, without any sanitization as encountered earlier.
To exploit this vulnerability, I can use Drozer to interact with the database. I can start by using Drozer to identify the application’s attack surface.
Drozer has identified one content provider that is exported. I can use Drozer to enumerate more information from the content provider.
As we can see, the read and write permissions are set to “null”, which means there’s nothing stopping me from querying data stores through the content provider. I can also use Drozer to identify the content URI discovered earlier.
I know from looking at the Java source code, that the content provider will execute any SQL queries I provide. My query will be concatenated with the content URI and then processed without any sanitzation. I can retrieve the contents of the “pivaaDB” database by executing the query below with Drozer.
Recommendations:
- 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.
I can use the ADB “backup” command to create a backup of the “com.htbridge.pivaa” package. Depending on the Android OS version you have, you may be prompted for a password that will be needed later to unpack the backup file.
This creates a “backup.ab” file that must be unpacked. I can accomplish this by using the “abe.jar” file to convert the backup file to a tar file. I also provided the password used when creating the backup file (i.e. password), as seen below.
I can then untar the “application-data.tar” file and view the contents of the backup file.
Looking through the files backed up, I can see the “pivaaDB” database which is unencrypted and can be read by anyone, even without root privilege, since making a backup does not require root privileges.
Recommendations:
- 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.
The PIVAA application allows users to login by providing a username and password. By statically analyzing the source code, I can see that the credentials are logged using the “log.i()” method.
These logs can therefore be dumped by “logcat”.
I can enter in credentials using the PIVAA login activity and the credentials will be visible as system log messages as seen below.
Recommendations:
- 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.
Examining the login functionality of PIVAA again, I can see that the “Authentication.java” file contains code that creates a file called “credentials.dat” in external storage and writes the login credentials to the file.
This file can be easily retrieved and the login credentials recovered using ADB.
Opening the file shows the login credentials used for the user admin earlier.
Recommendations:
- 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 😄!
