Application security

Cracking damn insecure and vulnerable app (DIVA) : Part 1

What is DIVA?

DIVA is a vulnerable Android application. According to their official website, "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."

Getting ready with the lab:

We are going to solve all these challenges on an emulator. So, below are the steps to follow.

• Download the application and extract the APK from the compressed tar file. You can download the application from here.

$ ls

diva-beta.apk    diva-beta.tar

$

• Launch an emulator and install the apk file using as shown below.

$ adb install diva-beta.apk

1863 KB/s (1502294 bytes in 0.787s)

    pkg: /data/local/tmp/diva-beta.apk

Success

$

• If you have done everything successfully, launch your application. You should see the following screen.

We are ready with the target application now. Let's also some important tools to crack these challenges.

We will use both manual and automated techniques to crack these challenges. So, set up the following tools preferably on a Unix based machine. I am using Mac OSX.

• Download and install (if required) the following tools.
  • Dex2jar & JD-GUI
  • APKTOOL
  • Drozer
  • Android utilities – adb, sqlite3, aapt etc.

With this, you are ready with the setup. Now, let's explore how to solve the challenges provided in this application.

Reversing the target application

One of the first steps to find vulnerabilities is static analysis by reversing the app. So, lets reverse engineer our target application to get ready to crack the challenges.

Note: This step is must, as some of the challenges require you to look at the source code.

Getting .java files Using Dex2Jar & JD-GUI

Getting the readable java files is always helpful during an assessment. So, let's get .java files using dex2jar and JD-GUI tools we set up earlier. As mentioned earlier, I have set up my lab on a machine running Mac OSX. So, run the following command to convert the dex file into a jar file.

$ sh dex2jar.sh diva-beta.apk

this cmd is deprecated, use the d2j-dex2jar if possible

dex2jar version: translator-0.0.9.15

dex2jar diva-beta.apk -> diva-beta_dex2jar.jar

Done.

Once done, you should see diva-beta_dex2jar.jar file in the same directory where you have dex2jar.

Open up this newly created diva-beta_dex2jar.jar file using JD-GUI as shown below.

Nice! As we can see above, we now have .java files.

Getting AndroidManifest.xml and smali code using apktool

Another important thing in static analysis of Android apps is having access to Androidmanifest.xml file. This gives us great deal of information about the app and its internal structure. Additionally, apktool provides us the smali code. So, let's use apktool to get the AndroidManifest.xml file and smali code as shown below.

$ java -jar apktool_2.0.3.jar d diva-beta.apk -o output

Figure 1 Contents of AndroidManifest.xml(truncated)

Figure 2: List of extracted smali files

If you want more details on how to setup the above mentioned tools, please refer to my article on Reverse Engineering here.

All set to crack the challenges. Let's crack some of the challenges now.

Challenge 1: "1. Insecure logging"

Steps to solve:

Click on "1. INSECURE LOGGING" in your application. The goal is to find out where the user-entered information is being logged and also the code making this vulnerable.

It is common that Android apps log sensitive information into logcat. So, let's see if this application is logging the data into logcat.

Run the following command in your terminal.

$adb logcat

Now, enter some data into the application's edit text field.

Check your logs after clicking "CHECK OUT".

Output in logcat:

D/MobileDataStateTracker( 469): default: setPolicyDataEnable(enabled=true)

D/LightsService( 469): Excessive delay setting light: 86ms

D/dalvikvm( 1695): GC_CONCURRENT freed 136K, 6% free 3845K/4060K, paused 7ms+4ms, total 93ms

E/diva-log( 1695): Error while processing transaction with credit card: 0000000000

E/SoundPool( 469): error loading /system/media/audio/ui/Effect_Tick.ogg

As you can see in the above logs, the data entered by the user is being logged.

Vulnerable code:

Open up LogActivity.class file using JD-GUI and check the following piece of code.

As you can see in the above figure, the following line is used log the data entered by the user into logcat.

Log.e("diva-log", "Error while processing transaction with credit card: " + localEditText.getText().toString());

Challenge 2: "2. Hardcoding issues - part 1"

Steps to solve:

Click on "2. HARDCODING ISSUES - PART 1" in your application. The goal is to find out the vendor key and enter it into the application to gain access.

It is common that developers hardcode sensitive information in the application's source code. So, open up "HardcodeActivity.class" file using JD-GUI once again and observe the following piece of code.

The secret key has been hardcoded to match it against the user input as shown in the line below.

if (((EditText)findViewById(2131492987)).getText().toString().equals("vendorsecretkey"))

Just enter this secret key found in the source code and you are done J

Access granted!

We will discuss "INSECURE DATA STORAGE" solutions in the next article.

More Links:

DIVA Official website: http://www.payatu.com/damn-insecure-and-vulnerable-app/