How to crack the challenges of DIVA

DIVA is a vulnerable Android app that is a good start to teach students how to check for vulnerabilities or design flaws in Android apps. According to the developers, “DIVA (Damn insecure and vulnerable App) is an App intentionally designed to be insecure. The aim of the App is to teach developers/QA/security professionals, flaws that are generally present in the Apps due poor or insecure coding practices.”

Within this Blogpost, I want to help you cracking the 13 challenges of DIVA.

0. Install the App

First of all we need to install the app to our test-device or emulator. This can be done by executing the following command:

As we will need for some of the following challenges also a good static analysis tool, we will now import the app into Codeinspect (but you can also use any other Android static analysis tool – e.g., JadX).


1. Insecure Logging

Lets get started with the first challenge. In this case we need to find out what the app is logging, where the log is located and also which lines of code are responsible for this kind of data leakage.

As we know from Android in general, logcat is used for logging of the system itself as well as for nearly all apps installed on a device. So lets try to have a look at the output of logcat.

To start logcat, just enter the following command into your local shell:

If we now enter any value into the textbox and hit “check out” we will receive an error message by the app.

But at the same time we will see a line like the following one within our logcat output:

This line shows exactly the value that we entered within the app. Thus, we have found the data leak ๐Ÿ˜‰

When we now look into the decompiled app within Codeinspect, we can find a class called LogActivity which contains the code snippet responsible for the output:

If you are using log messages for debugging, please be sure that you do not log sensitive user data or secret values of your app!


2. Hardcoding Issues

The 2nd challenge is again not really hard, but you now have to jump to the decompiled source code directly. The aim of this challenge is to find hardcoded secrets that are used to gain you access within restricted areas of the app.

Taking a look into the class HardcodeActivity we see the following code and also the hardcoded secret “vendorsecretkey” that brings us to the “other side” ๐Ÿ˜‰


3. Insecure Data Storage

Within the next 4 challenges we have to find the location where the app is storing the credentials a user is entering.

These 4 challenges describe the different ways developer can store data entered by a user or stored by the app itself:

  • shared preferences,
  • local database,
  • tmp file and
  • local file on the SD-card.

In any of those 4 cases, the app should never store confidential data – like credentials – in plain text and should use cryptographic hashes or encryption instead.

But now let’s get back to the challenges:

For this example, will we add “secret_user” as the 3rd party service username and “secret” as the 3rd party service password.

When looking at the source code, we see that the app is storing the data within the shared preferences folder:

To see if this is really true, we connect via adb shell to the test device and navigate into the shared_prefs folder of the DIVA app:

There we find a file called jakhar.aseem.diva_preferences.xml which contains the following data:

And here we find the entered credentials in plain text ๐Ÿ˜‰


4. Insecure Data Storage

The next challenge looks identically from the UI, but when looking at the code, we see the difference:

As we can see in this code snippet, the inserted credentials are stored within a sqlite database called “ids” in the table “myuser”. When dumping the database from the device by entering the following command and then opening the database with the DB Browser for SQLite we see our entered credentials:


5. Insecure Data Storage

The next challenge looks identically from the UI, but when looking at the code, we see the difference:

As we can see in this code snippet, the inserted credentials are stored within tmp file called “uinfo-838734269tmp”:


6. Insecure Data Storage

The next challenge again looks identically from the UI, but when looking at the code, we see the difference – this time the credentials are stored to the SD-card:

As we can see in this code snippet, the inserted credentials are stored within a file called “.uinfo.txt” located on the virtual SD-card of the device (as the file name starts with a “.” it is not shown to you if you try to list the content of the SD-card with “ls“, therefore use always “ls -la“):


7. Input Validation Issues

As the app tells us already, there are 3 users stored in the database that you have to guess. But instead of brute-forcing, we are only allowed to use one command. Thus, we need to find a vulnerability in the provided search field. A good start is always to test for SQLinjections. A first try is to just enter a single quote and look what logcat is telling you:

This is a good start, we see that it is executing the SQL query with our input without escaping it. So now we test if we can manipulate the predefined query in a way that returns always true:

And here we see all the stored accounts in plain text ๐Ÿ˜‰


8. Input Validation Issues

The challenge tells us, that we should use the search field to access any sensitive information of the app by just entering an URL in the search field. Remembering one of the challenges above, we could try to access the data stored on the SD-card. Therefore, we have to enter the following URL:

And as we can see below, it is working ๐Ÿ˜‰


9. Access Control Issues

Within this challenge we need to gain access to a specific activity of the DIVA app without navigating through the UI.

A good way to know if we can directly access activities is by using Drozer with its automated vulnerability detection and support in exploiting those weaknesses.

Thus, we will start Drozer and search for exported activities in the DIVA app:

As we can see above, there are 3 of those activities. Now, let’s see which activities we can access:

For us, the most important one is “jakhar.aseem.diva.APICredsActivity“.

The same answer we can also get by looking at the Android Manifest of the app:

The last step that we need to perform now, is sending an intent that is opening the activity:


10. Access Control Issues

This challenge looks pretty similar tho the one before, so let’s try the same approach with the “jakhar.aseem.diva.APICreds2Activity” activity:

We can see, that is now opening an activity, but it seems that we need additional input passed with the intent to gain access. Thus, look into the source code if we can get the needed information there:

If we look at line 9, we can see that the app is checking if the string provided together with the Intent is identical to the string with the id 2131099686 from the apps “strings.xml” file. When looking at this file, we can see the needed string:

With this information, we now can modify our Intent:

And………yes, it is working again and we got access to the credentials ๐Ÿ˜‰


11. Access Control Issues

This challenge deals with accessing a PIN protected notes storage without knowing the PIN.

A good way to know if we can bypass PIN-based authorization screens is by using Drozer with its automated vulnerability detection and support in exploiting those weaknesses.

Thus, we will start Drozer and search for vulnerabilities in the DIVA app:

This results shows us already, that the app has 3 exported activities (activities that we could access directly from outside the app) and one exported content provider.

For this challenge, the exported content provider seems to be very interesting as it allows access to a database – now let’s hope that it is the right one. To find out which database the app is exporting through this content provider, we use again Drozer:

As we can see here, the exported content provider is the right one, it allows access to the secret notes. To gain access to it, we will query it through the URI and Drozer:

And here we see all the secret notes in plain text ๐Ÿ˜‰


12. Hardcoding Issues

This challenge again seems to be connected to hardcoded secrets. So, let’s have a look at the source code to find some hints:

As we can see here, it is calling an Object from the DivaJni class. So let’s have a look at this class:

The only interesting line is the one above. Here we see, that it is loading a native library. As we are searching for a hardcoded credential, there is a good chance that we find it within the native library. A first try in such cases is always to execute strings command against the library and search for strings that could be used as passwords. By doing this, we find the following string that looks suspicious “olsdfgad;lh“.

And……Bingo ๐Ÿ˜‰


13. Input Validation Issues

This time we do not need to find out what is the correct value to launch the missile – this time we need to crash the app by sending an input that cannot be handled by the app.

A good first try is always to send a very large string to the app – just because we have seen in several challenges before that the author is not validating the user input. So we try it with 30 times “A”:

And……Bingo, the app crashed and no missiles will be launched ๐Ÿ˜‰

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.