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 related to deploying / using of Jadx.
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
- Access control issues can lead to sensitive data exposure
- Access control issues can help in bypassing of some security / conditions in the code
If you don’t know about the above points, then I would recommend you read the following posts:
- Android Platform Architecture
- Android Application and it’s Architecture (PPT)
- Damn Insecure and Vulnerable Application – Part I
- Damn Insecure and Vulnerable Application – Part II
- Damn Insecure and Vulnerable Application – Part III
- Damn Insecure and Vulnerable Application – Part IV
- Damn Insecure and Vulnerable Application – Part V
As we have completed the first eight challenges, so now, let’s move on to the 11th challenge which is “Access Control Issues Part 3”.
Challenge 11
Objective: This is a private notes application. You can create a PIN once and access your notes after entering the correct pin. Now, try to access the private notes from outside the app without knowing the PIN.
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.
We can see that the above screen is presented when we click for Challenge 11 and it asks to create a 4 digit PIN. Let’s create the PIN.
When you have entered the PIN and clicked the button, you would notice a new button “GO TO PRIVATE NOTES” has popped up. So, let’s click on it.
After clicking the button, we would see the above screen, that would require a PIN. If we enter the Pin which we had created then,
We would find the below screen, which contains the private notes. Our goal is to call / find out the notes without requiring the PIN.
As mentioned in the hint, we need to check for improperly protected activities, services and content providers. So, let’s find out the way to access the content of the notes.
Since we have check activities, Let’s try out the exploitations regarding content provider.
Note:- Content provider has a URI scheme to get called by some other application. If the those are not protected then anybody can get the information (in the application), just by calling content provider.
By knowing the above fact, let’s try to find the content URI in the DIVA application. The below code would the desired output easily:-
strings diva-beta.apk | grep “content://”
Now to get the information related to the above content provider, we can use the following command:-
adb shell content query --uri content://jakhar.aseem.diva.provider.notesprovider/notes
Yupieeee!!!!!! Mission accomplished!!!!!
Moving on with the next challenge.
Challenge 12
Objective: Find out what is hardcoded and where.
Hint: Developers sometimes will hardcode sensitive information for ease.
In this challenge we need to find the vendor key from the code. So, let’s have a look on the code.
In the above screen, we may see that, an object is been created using the user created class “DivaJni”. Let’s see what is in that class.
In the above figure we can find that, a library is getting called. Now let’s find the library, we might get something from it.
If we start looking into the lib folder ( which was created by apktool kit), then we may find the file with name “libdivajni.so”. If we get all the strings from that file then, we might find something like the below figure.
Except the highlighted part, every other word is related to programming. So let’s try to enter the highlighted word in the text field provided by the diva application.
Yooooooo!!!! Access granted !!!!!
Challenge completed….
Let’s get going.
Challenge 13
Objective: This is a Missile Launch App. Spread love not War! DOS the Damm thing! Your objective here is NOT find the code then launch the missiles, rather it is to crash the app (and then find the root cause the crash).
Hint: Improper or no input validation issue arise when the input is not filtered or validated before using it. When developing components that take input from outside, always validate it. This is a classic memory corruption vulnerability.
In this challenge we need to crash the application. The one way to crash the application is buffer overflow attack. Let’s try that.
Before try that attack, lets simply start the adb logcat.
And then try to find the buffer length by entering in the text field provided.
At first I entered one “a”
Then I tried to enter 7 “a”s (No luck)
Then I tried with 30 “a”s. (No luck)
Now I entered, 40 “a’”s.
Yup it worked. Now let’s look into the logs, which might let us find the root cause.
The first highlighted part gives that Fatal error / signal was generated due to with the state of Activity was changed (which can be seen in the second highlighted part). This led to the crash / forced stop of the application.
Mission Accomplished !!!!!
This ends my 6 part post series. I hope you all liked it. 😊
Doc related to Deploying or using of Jadx
Fire Hunter's Blog 