What is DIVA?
DIVA is similar to DVWA (Damn vulnerable web app) only it focuses on covering mobile security instead of web security. It’s an app intentionally designed to be insecure so security professionals can experiment and test with it. Labs present common insecure coding practices such as: insecure logging, hardcoding issues, improper data storage, and access control issues.
Splash Screen
Insecure logging
Refering to the OWASP foundation’s resources on insecure data storage: insecure data storage vulnerabilities occur when development teams assume that users or malware will not have access to a mobile devices filesystem. Organizations should expect a malicious actor to inspect sensitive data stores. If data is not protected properly, specialized tools are all that is needed to view application data.
Opening the Android debug bridge (adb) we can interface with how logs are written on the client. Typing the command “logcat” will show logs in real time.
Now when we enter a credit card number in:
We can go back to adb and see the credit card number in plaintext:
Hardcoding issues
The use of hard coded credentials increases the likelihood of password guessing tremendously. If hard-coded passwords are used, it is almost certain that malicious users will gain access through the account in question.
In this activtity the vendor key is hardcoded within the apk. With a little reverse engineering we can get the key by converting the apk into a rar file then analyzing the contained DEX file.
We can use the Dex2Jar tool to get a .jar file which we can then decompile.
d2j-dex2jar classes.dex
After getting the vendor key we can enter it into the activity.
Insecure Data Storage
Navigating with adb we can get to the /data/data directory where packages of all installed applications are stored. The package of the DIVA application is shown below:
We can enter a username/password combination into the activity then search for them in this directory.
Through adb we can see these saved creds hidden within shared preferences. Running cat on the XML document:
cat jakhar.aseem.diva_preferences.xml
Insecure Data Storage – part 2
This is similar to the previous activity but the creds are stored differently.
We enter the username/password the same way as before:
We can see the database ids2 is created. Running sqlite3 ids2 then .tables will list all the tables within the database. Here we can find the username and password.
Insecure Data Storage – part 3
Once again, entering creds into the activity:
This time the creds are stored in a “tmp” file within /data/data/.
Insecure Data Storage – part 4
Entering our creds again:
In the decompilation of this activity we see the creds are stored in external storage:
We can change our directory to storage/sdcard0/ then search for the written file .uinfo.txt
Input Validation Issues
This next activity is a classic SQL Injection example. This of course consists of an insertion of a SQL query via the input data from the client to the application. A successful exploit can read sensitive data from the database, modify data, execute operations on the db and sometimes issue commands to the OS.
We can enter ‘ OR ‘1’ == ‘1 to get the output we’re looking for.
Input Validation Issues – part 2
The activity asks us to enter a URL. When we enter https://www.google.com we get an expected result:
Modifying the URL to /etc/hosts nets us a different result:
file:////etc/hosts
We can also enter the xml doc we accessed in an earlier activity:
Conclusion
There are more security vulnerabilities than the challenges presented in DIVA, but this gives us a good look at some of the security possibilities within the mobile/android space. We can also see there’s quite a bit of overlap between OWASP web and OWASP mobile top 10.
