Wednesday, 2 March 2016

Cracking Damn Insecure and Vulnerable App (DIVA) – Part 1

0 comments Posted by srini0x00 on 19:50

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 and you should see the following screen.

                           

We are ready with the target application now. Lets also setup 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, lets see 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, lets 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 it’s internal structure. Additionally, apktool provides us the smali code. So, lets 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


Contents of AndroidManifest.xml file(truncated)

                           
List of smali files extracted

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

Cracking the challenges

All set to crack the challenges. Lets 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, lets 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 ☺

                         
Access granted!

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

More Links:


 

Recent posts

Recent Comments

Bookmark & Share