Next few challenges are all about insecure data storage, so let’s go
I put the credential as [Teck_k2:Teck_k2] and save
Before we proceed further, we will check the code which allow this insecure data storage vulnerability to happen.
Let’ back again to our kali
Extract the file content, and analyze
As you can see this piece of code inserting the credential into sql database inside the device, Now let’s come back to our adb shell and extract the database file
As you can see the databases folder is available, let’s go inside the folder and see all the available files
Generally we need to analyze all file one by one, but as this is a specific challenge based scenario, we won’t waste much time in analyzing all the files
For this challenge specifically we just need (ids2), we will extract this file in our local machine, for that we need to run adb as root first and then extract or it will show you permission error or file not found.
Move the file in your kali and open it with slqlite3
As you can see the clear text credentials are saved inside the sql database locally inside the device.
More …
Next challange in the list is Insecure Data Storge.
In this challenge we will try to understand how an application store a sensitive information inside the device in plain text or with weak encryption, which could later lead to data information leakage.
In the password section I put (111222) or any random password you wish to save and click on save.
Now for our next step we need to read some internal files and for that we would require root permission
Now connect to android device with adb shell
Check for connect devices
As we can see our device is connect we are good to go
We have the root shell now, we can read the internal file without restriction now
As you can see there is a (shared_prefs) folder which means the application is storing these details using shared preferences
If you analyze the source code you will get the clear understanding
Now get back to adb shell
As you cans see the credentials are being saved in plain text inside the device.
More …
We reached to our final challenge in this the objective is to do DOS the application and crash it
As the hint mention that this is a classic example of memory corruption or stack based buffer overflow
As you can see there is strcpy function available in the library of the application, so let’s try with something simple to understand where we are
Generate a string of A’s and feed it inside the application to see the response in Logcat
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Now push the red button
And you will notice the application crashed successfully, basically the challenge finished at this stage, but I decided to go ahead and take a reverse shell, which turn out to be the worst decision for me 😂, as expected Android binary exploitation should be similar what we expirience in a normal linux machine, untill unless you are using a ARM based architecture which is slightly different, but that was my mistake to think like that, becasue the application was coustom build and have lot of restriction which I had never experienced, and later as usual my mentor KNX came to rescue me from this hell 😂. I have shared my overall experience in the next Blog Binary from Hell 😈
More …
In this challenge we will solve and learn how we can view sensitive data inside the device, from the application which was meant to view only web URLs
As you can see the application open the webpage inside the application frame.
Let’s see if could read internal device files through application or not?
Let’s start with something basic, create a new file and try to read it from application itself
It’s working fine, let’s try to read some confidential file which we found in our earlier challenges
[ file:///data/data/jakhar.aseem.diva/shared_prefs/jakhar.aseem.diva_preferences.xml ]
As you can see we can view the XML file which store our credential from the challenge 3 which we solved earlier.
Now let’s have the source code of the application which is the reason for this vulnerability
This piece of code allow to read any URL even the system internal files, without validating or sanitizing it properly and as the application have permission to read any file in the system, because of which we were able to easily read any file even on SDcard.
More …
Our next challange is abourt Input Validation Issues
Input validation attack happens when the application could not sanitize the user input properly, and which could lead to data information leak, one of the simplest example of this is SQLi and XSS.
So in this challenge there are 3 default users, and if we could find any of them, we can see the secret data, so let’s start
First I tried with a single quote (‘) and looked at Logcat to see the error
We can see a sql error, which means we are on the right path as it’s using dynamic queries to retrieve data from the database, and as usual a single quote created an error in the query
Now let’s try with two and three quotes and see the response in the Logcat
Perfetto, now have verified that odd number of single quotes are causing sql errors, now let’s try to retrieve the username from the database
With a simple true statement we can extract the stored credentials from the database
Now, let’s have a look in the source code which is the reason behind this vulnerability.
This line of code allow the user to retrieve the data from sql query.
More …