This challenge is the second part of Hardcoding issues, where the objective is to find sensitive information which is the vendor code left by developer inside the application source code.
Let’s have a look inside source code
After analyzing the code above, we can understand that the activity is creating another class with the name of DivaJni, let’s have a look at that.
After analyzing the code above we could understand that there is a native library with the same name divajni, if you unzip the APK you will see the lib folder, which contains all the libraries inside it, let’s have a look
Let’s open any of the library and analyze it
After trying couple of strings, I finally found the correct string which can give us access [olsdfgad;lh]
Finally we found the correct key, see you in the last challenge.
More …
Now let’s come to our next vulnerability which is Hardcoding Issues
The one common mistake which many developers do while either making the web application or mobile application, they unintentionally forget to remove the hardcoded password or keys, which help an attacker to access sensitive information.
To solve this challenge we need to follow the same steps which we did in the last challenge
We need to use jad again to see the clear text of the file
KEY= “vendorsecretkey”
As you can see inside the code we can see the key, let’s try it inside application
Mükemmel As you can see the key worked perfectly and the access has been granted to us.
More …
Now we have reached to the last challenge of our Access Control Issues
The application is meant to save notes, but before accessing the notes we need to create a 4 digit pin, once we do that we can access the notes, but the objective of this challenge is to view the notes without entering the pin, let’s have a look in the application and then we will analyze AndroidManifest.xml
Put your 4 digit pin and click on create/change pin
Once you create a pin, you will able to see a new option to go to private notes
It will again ask you to enter your pin
Once you enter the correct pin, you will be able to see the private notes
Now let’s have a look at AndroidManifest.xml to find the vulnerable piece of code.
If you focus on the above highlighted line, it shows the content provider is set to [android:enabled:”true”]
Generally the content provider is represented like [content://] let’s have a look inside smali code and find the correct URI
If we try to find the content:// from all the file, we found the following inside the NotesProvider.smali, let’s open and have a look inside
As you can see in the above URI it provide us the exact URI path
[content://jakhar.aseem.diva.provider.notesprovider/notes]
If you remember few steps above we found that the content provider can we queried without any permission, let’s try to open it from adb shell
[adb shell content query –uri content://jakhar.aseem.diva.provider.notesprovider/notes]
As you can see we can view all the private notes from the application without providing any pin.
More …
Now we will move to our next challenge which is the second part of the Access Control Issues, in which there are two option either we can register and get a pin to see the Tveeter API credential, or if we already have the pin we can see the API credentials, So the objective of this challenge is to access the API credentials without registering for it.
Before we proceed let’s have a quick view of source code ()
If you solved the previous challenge, I explained in that the intent filter should not be considered as protection method, if you are using it in an activity, eventually it will be accessible to export publicly.
So let’s open our adb shell and exploit this
{ adb shell am start jakhar.aseem.diva/.APICreds2Activity}
But in the application it’s still asking for pin, now we need to find a way to bypass it
Let’s have a look at APICreds2Activity.class to understand the application in more detail
After analyzing both the source code, we could understand that to view the credential we need a pin, but if we disable the pin check it will ask for no further verification and land us directly to the API credentials, let’s try this
{adb shell am start jakhar.aseem.diva/.APICredsActivity check_pin false}
{ adb shell am start jakhar.aseem.diva/.APICredsActivity -ez check_pin false}
You can try both the commands, whichever works for you.
And it works like a charm, this time it didn’t ask for any PIN and landed us directly to the view credentials.
More …
This challange is about bypassing access controls, let’s find out how to solve this.
By clicking the View API Credentials we can see the credentials.
But the objective of this challenge is to access the API credentials without clicking the view button, there are couple of ways to do this, let’s try and find the most prominent way.
To understand the cause of this vulnerability let’s read the (AndroidManifest.xml)
If you remember we just unzipped the apk, that’s the reason the file is still in Android binary xml format, in able to read this file we need to decode the Apk properly using apktool
To understand the issue you need to focus on this piece of code
The intent-filter is generally used for protection mechanism, but if you use it with activity then it can be even used to export publicly. Which will allow any application from outside to use this activity and view the API credentials.
Now close your application in the emulator or you physical device, wherever you are testing
Now open ADB shell and write the following command anyone of the below, If you are outside the adb shell just type
{adb shell am start jakhar.aseem.diva/.APICredsActivity}
{ adb shell am start -n jakhar.aseem.diva/.APICredsActivity -a jakhar.aseem.diva.action.VIEW_CREDS }
If you are inside adb shell you can just type this
{ am start jakhar.aseem.diva/.APICredsActivity }
The moment the command get executed you will see the API credential popup on the screen
More …