Android Pentesting: Writeup of DIVA Input Validation Issues for Parrot OS

With another day gone, it is time for another Android Pen-test write-up. Today we are going to cover the fourth section of the DIVA APK, Input Validation Issues. When we have an application that does not validate input properly, it makes it easier for an attacker to go ahead and creating input that is not expected by the rest of the application. This has dire consequences, ranging from altered data, arbitrary code execution, or unauthorized data access. Not good!

If you have not seen any of the previous write-ups, feel free to head over to my GitHub and pull anything you want. When you're ready, put on your favorite hoodie and grab your nearest drink, and let's get HACKING! 👾

Input Validation Issues - Part One

When we open the Input Validation Issues - Part 1 section on our device we are met with the following objective: try to access all user data without knowing any username. There are three users by default and your task is to output data of all three users with a single malicious search.

Let's take note of the key to this objective: malicious search. We also see a little hint, which tells us that there are three users in the database, where one is an admin.

Since we are working with a database, we are most likely going to have to create a SQL Injection, but before we get to that, let's see what happens if we enter any username (without knowing the true values).

When we enter an random/guessed value, we can see that no user gets returned. Yet, when we enter admin, we can see that it returns the details of the admin user! 👀

Now that we know that admin is most definitely a user, we can use this to construct our SQL Injection command. But, before we do this, I want to cheat a little bit and go snoop around in our database files to see if we can see the three users that we need to return with our command.

If you want to do this, open up your terminal via CTRL + ALT + T and enter the following commands:

adb shell
su
cd data/data/jakhar.aseem.diva/databases

> qlite3 (To enter this option start typing sql, press TAB + Enter)
> .open sqli
> .tables
> .table sqliuser
> .dump sqliuser

We can see that we need to construct a command to return the users admin, diva, and john. Head back into your application, because we are about to write the most genius, original, most hackery SQL Injection command ever!

''admin' OR 1=1;--

• ' indicates the start of our query
• 'admin' we know this is already a user in the database.
• OR 1=1; since 1=1 is always true, the query will return all items.
• -- comments out the rest of our query.

DUHN DUHN DUUUUUHN, we've successfully dumped their database table! Wasn't that fun? 😀

Input Validation Issues - Part Two

When we open the Input Validation Issues - Part 2 section on our device we are met with the following objective: try accessing any sensitive information apart from a web URL.

Let's take note of the important part in this objective, which is to NOT access information from a web URL - so don't go trying to hack Google or your favorite site! We need to access local data. 😂

Now, before we continue, I need to confess something. I made an oops and had to clean install all of my tools. This means that all those tmp files and shared_prefs we created in the pervious writeups are all gone. Not to worry, because I'm going to work around it. 🤠

Let's go into our APK and see what sensitive data we can exploit. If you aren't me, and you still have your tmp file, you can easily use that file. I will instead create a "secret" file that will contain some user data. We will then use this file to see if we can access it in the application. Open up your terminal and do the following:

adb shell
su
cd data/data/jakhar.aseem.diva/
echo "password:123; username:alex" > private.txt
cat private.txt

with our file created, and our sensitive data stored locally on our device, we can now go back to our application and try to access our private.txt file via input. Let's navigate to that file via:

file:///data/data/jakhar.aseem.diva/private.txt

When we hit view, we can see that our data is revealed! 🙃

And so we are done with part two. Let's keep going.

Input Validation Issues - Part Three

When we open the Input Validation Issues - Part 1 section on our device we are met with the following objective: ...DOS the damn thing! Do not find the code, just crash the app (and then find the root cause of the crash).

Firsts things first, let's go over what a DOS attack is. A Denial-of-Service (DOS) attack is an attack that has the intention of shutting down a system, which in turn makes it inaccessible or slow. We perform DOS attacks by flooding the target with traffic or large volumes of information that causes the system to crash.

Now, we can go about this in various ways, but for this writeup let's do it the most basic way: by entering a large amount of data into the input and pushing the red button!

To make the app crash, I simply just spammed my keyboard with 0 until the input no longer accepted my string length, and voila, it worked!

Okay, so we successfully completed the first part of the objective, which was to crash the app via a DOS attack. Let's head into Android Studio, or alternatively you can use the adb logcat command in your terminal (but I like the pretty AS colors 😆), to see what our log returned.

Now, there's a lot going on here, and it's easy to get overwhelmed, but let's focus on our error code SIGSEGV. I highlighted the SIGSEGV code because it is is important since it indicates a segmentation fault in Linux containers. Simply put, we get this code since our application tries to read/write outside of the memory allocated for it or when writing memory which can only be read.

Let's open up our JDX-GUI (jadx-gui) and see what our source code says. When we open up our InputValidation3Activity, we recognize a class (Divajni) that we had to use way back when in our hardcoding issues writ-eups. We can see that it uses this value to initiate our launch sequence.

Let's open up Divajni. We get greeted again by soName, which we know has something to do with our libdivajni.so file.

Okay, now from here on we can open up our terminal and see if we can find something in our libdivajni.so file that is odd - or related to our error code. We won't have to scroll to far before we identify the culprit: strcpy.

Though we cannot access it to see how it is used, strcpy is a common culprit when it comes to segmentation faults. This is because the strcpy() code is suitable handling for small inputs, but not for large ones such as the input we used for our DOS attack.

Congratulations, you have successfully completed all three parts of the DIVA Input Validation Issues! 🥳

I hope this was easy enough to follow/understand. I'll see you next time for our last section (section 4): Access Control Issues. If you have recommendations on any cool tools, techniques, or tutorials that I too can follow feel free to leave them below and I'll check it out! 😊

(Pull this on my GitHub for future reference)