In the previous article, we have seen the solutions for the first two challenges. In this article we will discuss the insecure data storage vulnerabilities in DIVA.

Challenge 3: "3. INSECURE DATA STORAGE – PART 1"

Steps to solve:

Click on "3. INSECURE DATA STORAGE – PART 1" in your application. The goal is to find out where the user-entered data is being stored and also the code making this vulnerable.

Enter some data into the edit text fields of the application as shown above. I entered SECRET:SECRET. We will keep our username and password the same for all the challenges. Click "SAVE" button to save the data in the mobile app.

Now, let's see where this data is being stored.

To better understand where the app is storing the data, open up "InsecureDataStorage1Activity.class" file using JD-GUI. A close look at the following source code reveals that the app is using SharedPreferences to store the user entered sensitive data.

Let's proceed with "adb shell" to explore the file system. By looking at the AndroidManifest.xml file we can see the package name as "jakhar.aseem.diva".

We can also find it by exploring the "/data/data/" directory on the emulator as shown below.

$ adb shell

root@generic:/ # cd /data/data/

root@generic:/data/data # ls -l | grep 'diva'

drwxr-x--x u0_a75 2016-01-05 23:12 jakhar.aseem.diva

root@generic:/data/data #

Now, let's navigate to the apps directory and check the files and folders inside it.

root@generic:/data/data # cd jakhar.aseem.diva

root@generic:/data/data/jakhar.aseem.diva # ls

cache

databases

lib

shared_prefs

root@generic:/data/data/jakhar.aseem.diva #

As expected, we have "shared_prefs" directory inside it since the app is storing these details using shared preferences. Let's navigate to "shared_prefs" directory and check the contents

root@generic:/data/data/jakhar.aseem.diva # cd shared_prefs/

root@generic:/data/data/jakhar.aseem.diva/shared_prefs # ls

jakhar.aseem.diva_preferences.xml

root@generic:/data/data/jakhar.aseem.diva/shared_prefs #

As you can see in the above excerpt, we have an XML file inside the shared_prefs directory.

Looking at the contents of this file reveals the data we entered.

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>

<map>

<string name="user">SECRET</string>

<string name="password">SECRET</string>

</map>

root@generic:/data/data/jakhar.aseem.diva/shared_prefs #

Challenge 4: "4. INSECURE DATA STORAGE – PART 2"

Steps to solve:

Click on "4. INSECURE DATA STORAGE – PART 2" in your application. The goal is to find out where the user-entered data is being stored and also the code making this vulnerable.

Enter some data into the edit text fields of the application as shown above. Just like the previous challenge I entered SECRET:SECRET.

Now, let's see where this data is being stored.

Once again, to better understand where the app is storing the data, open up "InsecureDataStorage2Activity.class" file using JD-GUI. A close look at the following source code reveals that the app is using SQLite databases to store the user entered sensitive data.

The following line shows that the application is using raw SQL queries to insert data into the SQLite database.

this.mDB.execSQL("INSERT INTO myuser VALUES ('" + localEditText1.getText().toString() + "', '" + localEditText2.getText().toString() + "');");

Let's move on to the emulator's file system. Get a shell using adb and navigate to the app's directory.

root@generic:/ # cd /data/data/jakhar.aseem.diva

root@generic:/data/data/jakhar.aseem.diva # ls

cache

databases

lib

shared_prefs

root@generic:/data/data/jakhar.aseem.diva #

As you can see, "databases" folder is available inside the apps directory. Les navigate to the databases directory and see the listing using "ls".

root@generic:/data/data/jakhar.aseem.diva/databases # ls

divanotes.db

divanotes.db-journal

ids2

ids2-journal

root@generic:/data/data/jakhar.aseem.diva/databases #

There are two different files here.

• divanotes.sb
• ids2

divanotes.db is a file for a different challenge that we will discuss later. So, "ids2" looks like the only option for us now. But, this file doesn't have any extension. SQLite files can be created even without extension. However, lets cross check to see the file type before we proceed.

Pull the file on to the local machine using "adb pull" as shown below.

$ adb pull /data/data/jakhar.aseem.diva/databases/ids2

242 KB/s (16384 bytes in 0.065s)

In Unix based machines, we can use the "file" command to determine the type of the file as shown below.

$ file ids2

ids2: SQLite 3.x database

$

As we can see in the above figure, it is confirmed that it is an SQLite a file. So, lets dump the database using SQLite3 command line client.

$ sqlite3 ids2

SQLite version 3.8.5 2014-08-15 22:37:57

Enter ". help" for usage hints.

sqlite> .tables

android_metadata myuser

sqlite> select * from myuser;

SECRET|SECRET

sqlite>

Challenge 5: "5. INSECURE DATA STORAGE – PART 3"

Steps to solve:

Click on "5. INSECURE DATA STORAGE – PART 3" in your application. Again, the goal is to find out where the user-entered data is being stored and also the code making this vulnerable.

Enter some data into the edit text fields of the application as shown above. Just like the previous challenge I entered SECRET:SECRET.

Now, let's see where this data is being stored.

Again, to better understand where the app is storing the data, open up "InsecureDataStorage3Activity.class" file using JD-GUI. By observing the following source code, we can see that the app is using a temporary file to store the user entered sensitive data.

Let's move on to the emulator's file system. Get a shell using adb and navigate to the app's directory.

root@generic:/data/data/jakhar.aseem.diva # ls

cache

databases

lib

shared_prefs

uinfo1606252497tmp

root@generic:/data/data/jakhar.aseem.diva #

As we can see, there is a temporary file, whose name starts with "uinfo" has been created by the application.

Let's see the contents of this file.

root@generic:/data/data/jakhar.aseem.diva # cat uinfo1606252497tmp

SECRET:SECRET

root@generic:/data/data/jakhar.aseem.diva #

Challenge cracked!

Challenge 6: "6. INSECURE DATA STORAGE – PART 4"

Steps to solve:

Click on "6. INSECURE DATA STORAGE – PART 4" in your application. Again, the goal is to find out where the user-entered data is being stored and also the code making this vulnerable.

As we did earlier with previous insecure data storage challenges, enter some data into the edit text fields of the application. Just like the previous challenge I entered SECRET:SECRET.

Now, let's see where this data is being stored.

Once again, I am beginning by opening up "InsecureDataStorage4Activity.class" file using JD-GUI. By observing the following source code, we can see that the app is storing the data in a file on the sdcard. File name being created is ".uinfo.txt"

Since, we got the hint from the source code, let's get a shell and check the sdcard.

root@generic:/ # cd /mnt/sdcard

root@generic:/mnt/sdcard # ls

Alarms

Android

DCIM

Download

LOST.DIR

Movies

Music

Notifications

Pictures

Podcasts

Ringtones

portswigger

root@generic:/mnt/sdcard #

No luck! There is no file with the name ". uinfo.txt". But wait, the trick is in the file name. In Unix like machines, files starting with a dot are ignored by default by the command "ls". Since the file name is beginning with a dot, "ls" command is ignoring it. So let's search for the file as shown below.

root@generic:/mnt/sdcard # ls -l .uinfo.txt

rwxrwx--- root sdcard_r 14 2016-01-05 23:57 .uinfo.txt

root@generic:/mnt/sdcard #

We got the file on the sdcard. Let's check its contents.

root@generic:/mnt/sdcard # cat .uinfo.txt

SECRET:SECRET

root@generic:/mnt/sdcard #

Game over! We have finished all the insecure data storage challenges.

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

In the next article, we will discuss the challenges related to input validation issues.