Room Link : https://tryhackme.com/room/zthweb2
IDOR
IDOR, or Insecure Direct Object Reference, is the act of exploiting a misconfiguration in the way user input is handled, to access resources you wouldn’t ordinarily be able to access.
For example, let’s say we’re logging into our bank account, and after correctly authenticating ourselves, we get taken to a URL like this https://example.com/bank?account_number=1234. On that page we can see all our important bank details, and a user would do whatever they needed to do and move along their way thinking nothing is wrong.
There is however a potentially huge problem here, a hacker may be able to change the account_number parameter to something else like 1235, and if the site is incorrectly configured, then he would have access to someone else’s bank information.
Q1. IDOR
After logging in with the credentials provided
noot:test1234
By checking the URL we can see the IP/note.php?note=1
And in the previous task (task 3) you had read that
However, as you may have picked up on, there seems to be an interesting part of the URL. It seems that the note that we can view is controlled by a URL parameter, let’s check if we can access other notes, by increasing the number to 2.
IDOR can also have negative values as well like -1 etc.
The note parameter is set to 1, lets try changing it to 0.
(When dealing with numerical id’s, my preference is to start fuzzing from 0 ( As admin accounts are first to be created, so they usually have low index numbers such as 0 or 1) and increment to an arbitrary value (User accounts are made after the admin accounts so they have greater index value)., depending on how many users the application is likely to contain (such as 5,100,1242 etc..).
After changing the value to 0, we get a flag!
Forced Browsing
Forced browsing is the art of using logic to find resources on the website that you would not normally be able to access. For example let’s say we have a note taking site, that is structured like this. http://example.com/user1/note.txt . It stands to reason that if we did http://example.com/user2/note.txt. We may be able to access user2’s note.
Taking this a step further, if we ran wfuzz on that URL, we could enumerate users we don’t know about, as well as get their notes. This is quite devastating, because we can then run further attacks on the users we find, for example brute forcing each user we find, to see if they have weak passwords.
Automatic Exploitation
Q1:What flag hides characters
Answer : --hh
Q2. What flag shows specific word amounts instead of hides them
Answer : --sw
Challenge
Browse to port 81
We can use any password combination. I used → hi:bye
Let’s brute force the noot field using wfuzz
wfuzz -c -z file,common.txt http://IP:81/FUZZ/note.txt
The wordlist common.txt can be found in
/usr/share/wordlists/dirb/common.txt
As we can see, we are getting a lot of 404 responses which have 57 words. We can block it using the --hw 57 or --hc 404 .
wfuzz -c -hw 57 -z file,common.txt http://IP:81/FUZZ/note.txt
wfuzz -c -z file,common.txt -hc 404 http://IP:81/FUZZ/note.txt
Let’s browse to http://ip:81/REDACTED/note.txt to get the flag.
API bypassing
This is a bit of a unique one, as it can basically be anything. APIs are by definition incredibly versatile, and finding out how to exploit them, will require a lot of research and effort by the hacker. The following situation is only one possible scenario out of a near infinite number.
TASK 10 — READ AND MARK THE NO ANSWER REQUIRED
Task 11
Browse to port 82
Login with random username and password.
The hint says : The parameter you need to use may not be the same. If you’re looking for a wordlist, you can use big.txt.
big.txt can be found in /usr/share/wordlists/dirb/big.txt.
I tried bruteforcing it didnt get expected results. I thought to check out the usual file names where flags are stored like /flag.php, /flag, and /flag.txt.
Luckily /flag.txt was the location where the flag was stored.
Hope you enjoyed the walkthrough.
