Android Security Challenge: InjuredAndroid Part II (Challenge 6 - 10) (day 94) (~˘▾˘)~

 

 (URL: https://media.makeameme.org/created/a-challenge-lets.jpg)

This is the second part of the android security challenge, previously in the first post, we solve the 1st - 5th challenge of injured android we see how to locate a secret string to get the flag in the decompiled source code of the application, how to bypass login by exploiting exported activities and code our own exploit to probe the broadcast receiver.

In this post, we will try to solve the 6th-10th challenge. Without further ado, let's get into it

Challenge 6:

Just like the previous challenge from the first part our inputted string is compared with the flag but this time it is encrypted. Tracing the function call we land in class that contain encryption and decryption function with long and weird names on it



From a quick analysis on the source code we can see that the author choose DES algorithm as the chosen algorithm. The key itself is hardcoded but it is stored in a different class(Hide.class)



we have the key and the algorithm implementation we can certainly retrieve the key by reusing the code into another program to break the program encryption this technique is called CODE LIFTING.





so I create a new function that contains reuse code from the original application that will decrypt the encrypted string for me. Run the new update application and we get the sixth flag



6th flag => {This_Isn't_Where_I_Parked_My_Car}

Challenge 7:

This challenge involves sqlite internal database to store the flag.



Let's take a look at the DatabaseSchema.class where the program put the overall description of the database

from this information, we know that the SQLite database is "Thisisatest.db" and decoded value of the database column. We can go to this DB by going to the application internal directory since I installed the application in a rooted android emulator.



inside the database, there is two content but all of them are hashed and encrypted with some weird algorithm.

 

first entry hashed can be cracked easily by going to https://crackstation.net/ and the result is: hunter2

according to the 3rd hint it mentioned the word "rotated" I guess that the second entry is encrypted with caesar cipher since the first entry is md5 hashed.

I try to crack the Caesar cipher by creating a simple python program and it turns out the key is 47 however every word that contains special character need to reduce by 47 whereas normal character that contains alphabet and number is added by 47

By running the program above we got a link that leads to the second flag:

you need to enter both of the credentials to pass this level

7th flag =>S3V3N_11

Challenge 8:

This challenge involves some little bit understanding about AWS CLI and I pretty struggle since I never have done this



The FlagEightLoginActivity.java class basically just connecting the application to the AWS bucket, retrieve the content to be compared with our input

I try to do some string analysis and found some credential for the AWS authentication:



hmm, interesting! so how do I use this credential to log in to the AWS service? I try to read some online documentation and I found out I can use AWS-CLI utility to log in(https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html)

so Installed aws-cli using brew in my mac and create a profile file that will contain the two credential

So the above command actually told us to connect to the storage bucket of the app with the credential that we just made earlier that have profile name injuredandroid. Once we connect with the service, we send "ls" command to list all of the files

The result shows us the 8th flag

8th flag =>C10ud_S3cur1ty_lol

Challenge 9:

This challenge requires us to have knowledge of the firebase database. If you take a look at the FlagNineFirebaseActivity.class, the class contains several instances that used to prepare the connection to the firebase.



there is a variable called "decodedDirectory" that the app will use as references to access the firebase resources, let's try to decode the string since it is base64

~#echo ZmxhZ3Mv| base64 -d
flags/

next, we need to find out the firebase database URL in the app, luckily spotting this string is pretty easy by simply use grep.



by concatenating these two string together we got the complete URL of the firebase resources used by the application. According to https://blog.securitybreached.org/2020/02/04/exploiting-insecure-firebase-database-bugbounty/, there are several ways to test firebase database one of them is by putting at the end of the URL "/.json". This simply tests if the admin has configured the read and write permission of the resource correctly or not if it's not returning "permission denied" then we got a hit, like this:


yay! we got the ninth flag, to complete the level we need to convert this into base64 before we put it to the input text.

9th flag =>[nine!_flag]

Challenge 10:

If we take a look at the hint at challenge 10, it says that we need to find an email address and I try to search it through the app but sadly :(  I couldn't find anything that has a connection with an email address then I move to the second hint that said: "Unicode collision" which is pretty interesting. Thus, I try to research the topic and it leads me to this resource https://www.bugcrowd.com/blog/hacking-unicode-like-a-boss/

Long story short there is a study case about a Unicode collision that is found by john Gracey when poking around the password reset from Github. John found out that you can redirect the password reset token a different email

HOW?

through Unicode collision

example:
Let's say the email provider allows using Unicode in their account:

so if you have an email named mike@example.org and attacker can simply redirect the password reset token by inputting mıke@example.org(yes! that's Turkish dotless i: ı) and because the system lowercased the provided email address, it will treat as ordinary "i" thus rather than sending the token to you it will send it to the attacker

Surprise...Surprise the email that john used is John@Github.com I try to submit the email address to the app to check if this email is what the author meant and yes since the app is showing the message "No Cheating" instead "Try again! :D"

We can assume we are on the right track. Let's try looking at the code that doing the comparison of our input.



At first, you probably know that it compares our input with John@Github.com if its the same it will show warning "No cheating :]" and if we are able to bypass the check, the program will take us to the second comparison where our input that has been converted to uppercase is compared with again John@Github.com but it was converted to uppercase so it will become JOHN@GITHUB.COM

how can we solve this?

pretty simple all you need to is to submit John@Gıthub.com using Turkish dotless I or John@GIthub.com using uppercase I both of the answer will surely bypass two checks in the program

10th flag => John@Gıthub.com

Okay that's all folks I hope you enjoy this blog and see you at the next part of this series