Start both boxes; Or if you have the OpenVPN Connect connected in your machine then start the Target box only and then, in your machine, go to the challenge URL and login info mentioned in Task 2.
IDOR, Insecure Direct Object Reference, is an authorization issue. A system with IDOR vulnerability will give me resources that I'm not supposed to have access to. All I have to do is change the http request parameters. Being able to access other peoples' accounts is called Horizontal privilege escalation and being able to execute operations I am not supposed to, such as running an admin privileged program, is called Vertical privilege escalation; IDOR is a form of horizontal privilege escalation.
Follow all the THM literature to learn about IDOR. Note that at one point, they tell us to "navigate to the Storage tab and expand the Local Storage dropdown". But it's actually here:
Relevant questions:
Exploiting the IDOR found in the view_accounts parameter, what is the user_id of the parent that has 10 children?
=>
Logging in with the default user, we see 5 childs...
We can change user_id parameter, to change into a different user (highlighted yellow above)
Go to Inspect > Storage > Local storage > Expand Dropdown > Click on the address _http:/10.48...
_The auth_user parameter has a user_id attribute, change its values and test with 11 12 13 14 15 16 ๐ฅฑ I am not telling you which one it is! Upon changing, hit refresh in the webpage, Notice that a new user profile loads every time with different number of childs...
Remaining two bonus questions, requiring Burp Intruder tool for automation, can be solved with the Attackbox, start that now... (If you dont have any remaining time left, you can still do it in your own machine with mouse-clicks aka ClickOps)
Move the Attackbox to another tab with expand icon(below), Go to Burp Suite and start a new project with the defaults.
From Target tab, click open browser. You may see this error. Settings icon is at top-right.
After clicking 'open browser' again, wait a few seconds to see a Firefox tab. paste the Targetbox URL and Login as usual. You will see that the website keeps 'loading'. Thats because the intercept is on. Go to Proxy tab of Burp Suite and click the colorful "Intercept on". We will turn this on again when we have to modify our request.
Lets catch our breath. This is what it looks like now:
On each interaction, the browser communicates with server using HTTP requests and response, we are going to modify that HTTP request using Burp. First we need to find which request is responsible for what.
After opening Inspect tool in the browser, refresh the webpage.
Revisiting the question: Use either the base64 or md5 child endpoint and try to find the id_number of the child born on 2019-04-17?
In the webpage, click the eye icon on a child card to see the 'ID Number'. But the birth date is not visible. Try the edit icon too.
The plan is to send a formatted request via Burp, change its id hash values and then in the responses find our desired information ie. the birth date.
Lets do it with Burp Suite.
- Start from the dashboard webpage.
- Go to Burp > Proxy tab > turn on intercept
- In the webpage, click on the child edit icon.
- You will see that it is not showing. Burp has paused the request response cycle and its waiting for you to manually forward that request.
- Using Burp, we can send a formatted request with a different user ID or any other value we want. We can then receive responses for every child and find the birth date part that the question is looking for. My Attackbox just expired, because I took a break :) Now using Burp Community edition in my laptop.
Here I took a detour. the yellow highlighted string is an md5 hash, but of what? You cannot decode a hash, you can encode(hashify) some known string such as child name, child id, birth date etc to check if its a match.
Though we cannot see the birth date in the browser but in the THM task literature, clicking the 'view' button on a child returns the birthdate too. It is found in the response body in browser Inspect tool, not in the webpage. So lesson learned here, our investigation should be focused more on the request response cycle.
Lets follow the Burp Suite Steps again:
- Start from the dashboard webpage.
- Go to Burp > Proxy tab > turn on intercept
- In the webpage, click on the child view icon.
- You will see that child item details is not showing. Burp has paused the request.
- Highlight just this part, and right click > send to intruder.
- Go to 'intruder' tab. First make a list in the notepad and then paste the numbers here from 1 to 20.
- In the Payload Processing section, Add a task, select Base64 encoding.
- Start attack button, graciously!
I can now use keyboard arrow key to just browse all the result to look for 2019-04-17. Looks like child_id:1x has this birth date :)
Bonus Question 2
"Using the /parents/vouchers/claim endpoint, find the voucher that is valid on 20 November 2025". None of the vouchers had November date. Frankly I had to look another blog for a hint. Lesson learned is look at the Literature again, which topic is not used so far? UUID!
While this look completely random, we can see that the UUID version 1 was used. The issue with UUID 1 is that if we know the exact date when the code was generated, we can recover the UUID. For example, suppose we knew the elves always generated vouchers between 20:00 - 21:00. In that case, we can create UUIDs for that entire time period (3600 UUIDs since we have 60 minutes, and 60 seconds in a minute), which we could use in a brute force attack to aim to recover a valid voucher and get more gifts.
Go to this decoder and paste any of the vouchers you see from the webpage... But we have to generate the UUID with our desired date value. I cannot find an online tool except chatgpt...
So in https://claude.ai/chat, tell it to generate js code to build UUID v1 codes from uuid npm package, for every minute between 20:00 - 24:00 UTC on Nov 20 2025
We will paste all the uuid into Burp a bit later!
In the webpage, when we use the "claim voucher" feature we will see the '/parent/vouchers/claim' endpoint that they are talking about
Turn on Intercept right before clicking the green 'claim voucher'. Type something 'asdf' and enter.
Go to Burp, highlight that 'asdf', right click and send to Intruder tab
Paste all those UUIDs and Start attack...
Watch the magic and filter by 200 status code
Go Touch Grassโขยฎ and come back a minute later. You are supposed to find a 200 request that returns a positive response, as opposed to "Voucher not found".
Click the lightbulb icon to get the answer for this special task. If you dont get it right, work backwards. copy the answer and paste into UUID Decoder and see why your list of UUIDs did not work.
Did I get it correct? nope. the THM answer was: 22643e00-c655-11f0-ac99-026ccdf7d769 and mine was 22643e00-c655-11f0-9acd-a6c6a92e79aa.
Both start with the same prefixes and give the same time in UUID Decoder. My guess is they would not be called UUID if they were not this much random! Feel free to comment and add your observations.
Top comments (0)