Steps to solve:

Click on “9.ACCESS CONTROL ISSUES – PART 1” in your application. Here is the functionality of this challenge. When the challenge is launched following activity is shown to the users.

We can access the API Credentials by clicking “VIEW API CREDENTIALS” button shown in the above activity.

API Credentials are accessible to the user. Now, our goal is to access this information, without clicking this button. Let’s see how to do it. A look at the AndroidManifest.XML file reveals the following entry associated with Vendor API Credentials activity that is shown above. If you notice the above piece of code, the activity is “protected” with an intent filter. The intent filter should not be treated as a protection mechanism. When an intent-filter is used with an application component such as activity, the component is publicly exported. For the same reason, this activity is vulnerable and hence it can be invoked by any application from outside. This can be achieved by typing the following command in the terminal. $ adb shell am start jakhar.aseem.diva/.APICredsActivity adb shell: To get shell access on the AVD Am: Activity Manager tool Start: To Launch an activity Finally, “jakhar.aseem.diva/.APICredsActivity” represents that “APICredsActivity” is the activity that has to be invoked from “jakhar.aseem.diva” package. Typing the above command will launch the private activity as shown below.

Though the above command works, a more formal way of launching this intent is as shown below. $ adb shell am start -n jakhar.aseem.diva/.APICredsActivity -a jakhar.aseem.diva.action.VIEW_CREDS The above command also specifies the intent action using “–a”.

Steps to solve:

Click on “10.ACCESS CONTROL ISSUES – PART 2” in your application. The following activity appears when you launch this challenge.

If you are a registered user, you will have access to the tweeter API Credentials. The goal of this challenge is to access the tweeter API Credentials without registering. Once again, a close look at the AndroidManifest.XML file shows the following code. If you notice the above piece of code, just like the previous challenge the target activity is “protected” with an intent filter. As mentioned in the previous challenge Intent filter should not be treated as a protection mechanism. When an intent-filter is used with an application component such as activity, the component is publicly exported. This activity is vulnerable and hence it can be invoked by any application from outside. So, let’s try out the following command and see if it works. $ adb shell am start -n jakhar.aseem.diva/.APICreds2Activity -a jakhar.aseem.diva.action.VIEW_CREDS2 When we run the above command, we will be landed on the following screen.

This shows that there is some additional check used in the application. Let’s explore the source code associated with this application functionality. The source code of DIVA application is available at the following GitHub link. https://github.com/payatu/diva-android Let’s have a look at the following piece of code from APICreds2Activity.java

APICreds2Activity.java Looking at the above piece of code, it can be seen that there is an extra boolean type argument required along with the ADB command we used to launch the intent. First the string “chk_pin” is resolved using the following line. boolean bcheck = i.getBooleanExtra(getString(R.string.chk_pin),true); Let’s check the chk_pin entry from strings.xml to see it’s actual value. Strings.xml file is available at the following path of the GitHub link provided above. /app/src/main/res/values/strings.xml “chk_pin” is “check_pin”. This can be seen below.

The next line is making a check to see if “check_pin” value is false or not. This condition is to verify if the user is already registered or not. This can be seen from the following code in AccessControl2Activity.java

AccessControl2Activity.java If the user is already registered “check_pin” is set to false, if not it is set to true. When the “check_pin” button’s value is set to “false”, there are no other checks made by the application at receiving side. So, let’s try to pass this additional argument to the intent and see if it works. $ adb shell am start -a jakhar.aseem.diva.action.VIEW_CREDS2 -n jakhar.aseem.diva/.APICreds2Activity –ez check_pin false –ez is to pass a key value pair of type boolean. Running the above command shows the following screen.

Challenge cracked! As mentioned in the previous challenge, the following command also works. $ adb shell am start –n jakhar.aseem.diva/.APICreds2Activity –ez check_pin false

Steps to solve:

Click on “11.ACCESS CONTROL ISSUES – PART 3” in your application. The following activity appears when you launch this challenge.

Let’s enter a new PIN. Once you do it, a new button will be appeared as shown below.

Click “GO TO PRIVATE NOTES”, it will launch a new activity as shown below.

We can access the private notes, by entering the pin we set earlier. In my case, it is 1234.

As we can see in the above figure, we can access the private notes. The goal is to access these private notes, without entering the PIN. A look at the AndroidManifest.XML file reveals that there is a content provider registered, and it is explicitly exported using android_exported=”true”. Content Providers are represented using the URI that starts with content://. So, we need to find the URI to access the data. First navigate to the directory where the smali code is extracted using APKTOOL. $ ls smali $ We can find the strings using grep command. The following command recursively searches all the files for the strings that contain “content://”. $ grep -lr “content://” * smali/jakhar/aseem/diva/NotesProvider.smali $ As we can see in the excerpt above, the string is found in NotesProvider.smali file. Let’s open up the file and check for the content provider URI.

As we can see in the above figure, the following content provider URI is available in this file. content://jakhar.aseem.diva.provider.notesprovider/notes As we saw in the AndroidManifest.XML file, this content provider is exported and hence we can query it without any explicit permission. Let’s do it using ADB. Run the following command in a terminal. $ adb shell content query –uri content://jakhar.aseem.diva.provider.notesprovider/notes This should query all the data from the application’s notes database.

Challenge cracked! We can query the data from the application without knowing the PIN.