Damn Insecure and Vulnerable Application – Part V

In this post I would continue to solve the challenges that is in the vulnerable application “diva”. In the end of the post you may find a document on how to install Burp’s CA Certificate in an Android Device.

Till now we have discussed about the following things:

• Android Platform
• Android Architecture
• Android Application Architecture
• Android device virtualisation
• 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
• Insecure data storage in SQLite database file
• Insecure data storage in randomly generated temporary file
• Insecure data storage in hidden text file
• Input Validation Issues which leads to SQL injections
• Input Validation Issues which leads to Local File Inclusion

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
5. Damn Insecure and Vulnerable Application – Part III
6. Damn Insecure and Vulnerable Application – Part IV

As we have completed the first eight challenges, so now, let’s move on to the 9^th challenge which is “Access Control Issues Part 1”.

Challenge 9

Objective: You are able to access the API credentials when you click the button. Now, try to access the API credentials from outside the app.

Hint: Components of an app can be accessed from other apps or users if they are not properly protected. Components such as activities, services, content providers are prone to this.

In the above screen, if we click the “View API Credentials” button then, we would be presented with the following screen / activity

According to this challenge, we need to call this activity without accessing the application interface. To do that, let’s first check the code and get the idea of about our next step.

Well no luck in the code. Now we would need to check AndroidManifest.xml, to further investigate on the working process of the application. Basically here, we are finding out how this particular activity is being called.

So in the above code, we can see that, Activity “APICredsActivity” is called by Activity Manager as “jakhar.aseem.diva.APICredsActivity”. This Activity is also hiding behind intent filter. We will see that its defence is worthless.

Well we can pass an explicit intent in the Android device and call any activity using Activity Manager (if it not protected well enough), using our old friend i.e. adb (Android Debugger).

We can use the following command in the terminal to send an explicit intent in the Android device:

adb shell am start jakhar.aseem.diva/.APICredsActivity

Now if we have a look in the Android device, we would find that the requested activity has been opened and we have bypassed the previous activity.

Hurrrieeeee!!!!! Challenge completed.

So, moving on to next challenge, in which we would be solving “Access Control Issues – Part 2”.

Challenge 9

Objective: You are able to access the Third Party app TVEETER API credentials after you have registered with Tveeter. The App requests you to register online and the vendor gives you a pin, which you can use to register with the app. Now, try to access the API credentials from outside the app without knowing the PIN. This is a business logic problem, so you may need to see the code.

Hint: Components of an app can be accessed from other apps or users if they are not properly protected and some may also accept external inputs. Components such as activities, services, content providers are prone to this.

n this challenge we need to access the API credentials from outside the app without knowing the PIN. So, as mentioned in the challenge, we need to have a look in the code. Let’s try to understand what’s in the code :

In the code we can see that ( in the red rectangle ), a Boolean condition can be passed using intent to the activity named “APICreds2Activity”. In turn, the activity checks if the request is coming as an intent or not. If it is a valid intent, it displays the API key; else, it gives an input text field to enter the PIN.

Now let’s have a look on the manifest file.

From the manifest file we are observing that, activity named “APICreds2Activity” has an action named “VIEW_CREDS”. Let’s try to call the action using explicit intent using the following command:

adb shell am start -n jakhar.aseem.diva/.APICredsActivity -a jakhar.aseem.diva.VIEW_CREDS

And if we take a look on the android device screen then, we may find this screen popped up –

From the code we got to know that, the condition checks from the intent. Let’s try to by pass the check using the following command:

adb shell am start -a jakhar.aseem.diva.action.VIEW_CREDS2 -n jakhar.aseem.diva/.APICreds2Activity --ez check_pin false

And when we look on the device screen, we would find that we have bypassed the pin check screen and the credentials are displayed :

Yupieeeeee!!!!!! Challenged cracked.

Stay tuned 😊 for the remaining challenges.

Check out the steps to Install Burp’s CA Certificate in an Android Device.