Damn Insecure and Vulnerable Application – Part III

In this post I would continue to solve the challenges that is in the vulnerable application “diva”.

Till now we have discussed about the following things:

• Android Platform
• Android Architecture
• Android Application Architecture
• Android device virtualization
• Connecting to the android device using android debug bridge
• Using shell commands on the device
• Installing android application using adb
• Knowing about the process which is executed when we click to launch the application
• Getting the logs of the android application
• Checking for sensitive data in the log
• Hardcoding issues of developer
• Insecure data storage in xml file

If you don’t know about the above points, then I would recommend you read the following posts:

1. Android Platform Architecture
2. Android Application and it’s Architecture (PPT)
3. Damn Insecure and Vulnerable Application – Part I
4. Damn Insecure and Vulnerable Application – Part II

As we have completed the first three challenges, so now, lets move on to the 4^th challenge which is “Insecure Data Storage Part 2”.

Challenge 4

This challenge presents us with the following screen :-

Objective: Find out where / how the credentials are being stored and the vulnerable code.

Hint: Insecure data storage is the result of storing confidential information insecurely on the system i.e., poor encryption, plain text, access control issues etc.

In this challenge, we need to find the credentials which would be entered by the user. This challenge is also quite like the previous challenge. So, let’s enter the credential and check it out.

As we can see that the 3^rd party credentials have been saved successfully. Now let’s try to think where we can find the credentials that was entered. What we know is that, all application has a package folder in which they store data. To pin point our knowledge we might try searching it in the diva package directory or we can view the code or check the logs. We would see this step by step.

First let’s go through the logs and filter out our output with the grep command.

We can see that the file name is “ids2” and the path is “/data/data/jakhar.aseem.diva/databases/”. Now let’s check out the java code.

n the java code we can see that the application is creating a SQLite3 database file named “ids2”, but we cannot find the path of the file “ids2”. If the path of the file is not mentioned then by default it stores in it’s package directory it’s jakhar.aseem.diva which is residing under /data/data directory.

Now that we know the location of the database file, lets find it out using the adb shell and traverse to the path “/data/data/jakhar.aseem.diva/databases/”.

We can see that the database file “ids2” is the directory. Let’s try to extract the file from the device to our local machine.

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

Note – adb pull is used to pull or extract any file from the android device to the local machine, you just need to know the exact path of the file in the android device.

Now let’s verify that this file is actually a SQLite database file. To do this, we would use the file command of linux.

For checking the contents of the SQLite file we would require SQLite to be installed in our system. Well we don’t need to worry as, in our kali machine it comes pre-installed.

Let’s swim ( because in-depth of SQLite is not needed, only basis of SQL is enough) with SQLite for a bit. To start SQLite with the respective db file, we enter the following command:

sqlite3 ids2

To check if it has taken the right file, then use the following command:

.databases

Now we need to get the tables in the database ids2. For that, we would enter the following command:

.tables

As we can see that the database ids2 contains a table named “myuser”. Let’s get the data contained by the table “myuser”. Now we can use the normal SQL syntax:

select * from myuser;

Well we can that, if we query with the SQL command, we have obtained the 3^rd party service username and password which I had entered in the text fields.

Congo we passed the 4^th challenge. Now let’s proceed to the 5^th one.

Challenge 5:

When we click on the challenge 5 we get the following screen:

Objective: Find out where / how the credentials are being stored and the vulnerable code.

Hint: Insecure data storage is the result of storing confidential information insecurely on the system i.e., poor encryption, plain text, access control issues etc.

Hmmm……another puzzle, same objective but different place to search. Okay let’s enter the 3^rd party service username and password.

So now that we have entered the credentials, let’s try to find out where the credentials are being stored.

If we try the logcat approach, then we see that there is no luck….

Hmm…let’s try the search method and then we would see the java code.

So first, we need to get into the device shell, then to the default path of the application package and list all the files in that directory.

Nice, we got an extra file in the directory named “uinfo-1252525089tmp”. Let’s see what’s inside that.

Now time for finding the culprit ( code ) in the java file.

Well ! Well !! Well !!! We found the culprit. This code is creating a tmp file and storing the data ( in clear text ) in that file.

So, another challenge cracked. Yoooooooooooooooooooooooooooooooo!!!!

Let’s see what’s in the next challenge.

Challenge 6:

When we click on the challenge 6 we get the following screen:

Objective: Find out where / how the credentials are being stored and the vulnerable code.

Hint: Insecure data storage is the result of storing confidential information insecurely on the system i.e., poor encryption, plain text, access control issues etc.

Let’s enter something in the provided text fields.

Now let’s try to find the file in the storage area. If we try in the default path of the application package, hmmmm…. No luck for me. Well if someone finds it then just drop me a mail….hahahahaha.

Okay so let’s try to find the vulnerable code. Might be we find something..

Ohoooo !!!! changed the path this time. Taken the absolute path approach and created a file named “.uinfo.txt” in the “/” root directory in the external storage. So, lets dive into the egg shell. Hahahahaha!!! Please come back from egg shell 😊 and ( and wash nicely 😛 then ) dive into the device shell.

Let’s check the external storage with the following command:

ls

Ohooo it’s playing hide and seek with us…..don’t mind me … just kidding !!!!

Let’s uss the following command:

ls -a

Note: -a is used to check the hidden

Now let’s see what is dumped in the hidden text file “.uinfo.txt” with using the following command:

cat .uinfo.txt

Challenge cracked!!!

Stay tuned for my next post 😊.