3 Step IDOR in HackerResume

Before moving forward with this blog if you don’t have any context over what IDOR is you can refer the same over here

So to begin with, the story started when I was asked to test HackerResume since new features were being added on to see if there’s any security issues which can hamper the user data. So after going through the whole application it seemed most of the data we consider PII is already being public via the shared public resume.

Following the application workflow and analyzing all the request it came to my notice that there is a feature to enable and disable share the resume over a public URL and that was something which made me dig deeper and explore further. So when a user creates a resume he gets and option to share it via a public link or download the same. Thus if the users public link is by chance leaked to some attacker it can lead to a compromise of the users account since the URL shared has a unique hexadecimal path which acts as a ladder for the exploitation of the Vulnerability.

So moving forward to the vulnerable request, while going through the HTTP history tab in Burp I tried the trail and error method to repeat the request with other users id and after a quite trails I got multiple endpoints which exposed other users data so now the point was how to arrange all the modified request in a step by step exploit scenario.

So initially I found that the uid parameter value is the key to exploit all the requests which was something tricky to leak. But as mentioned above the shareable resume link was the ladder that helped in further exploitation, thus using the victims hexadecimal value from the shared url in the vulnerable PUT request which updates the users resume, dumped the uid in the response.

Next step was to access the ATS Board which had all the details of the candidate where the user have arranged all the jobs applied and their current status, but there was one more barrier it had Authorization Header in the request but we also have a solution for that as I have already analyzed all the request through all the features there was an Auth Token generation request which generated the value for Authorization Header

Thus using the output from the above request it was possible to replay the request and get the job boards of the victim user, so to guess the users board we only need to brute-force the request to get the valid board number.

Here in the below Screenshot we are able to see the victims ATS Board data along with the signup email used in creating HackerResume Account.

To resolve this issue I addressed the same to the Developer who instantly understood the root cause and applied the fix, I was totally amazed with this quick fix that took only an hour to move the fix to production and taking a glance into the PR it seemed to be a 2 lines of code change. So here it can be seen that the developer had applied a check for user_id with the resume_id to validate the request is from intended user only.

After exploiting this I hopped on to the ATS Board which had CRUD operation like creating and deleting a Stage, adding a Job into a particular Stage. So the thought process to exploit this was how can I perform the same actions in victim users board remotely. As usual I tried the same trail and error method by tampering the parameters in all the PUT/POST/DELETE request and within few attempts I got the exact vulnerable parameters that where vulnerable to exploit the same.

IDOR in ATS Board to move Jobs: An attacker was able to move his own Job(task) from his ATS board to victims ATS Board. Vulnerable Parameter: stage_id

IDOR to add new Stages: An attacker was able to replay the below request by changing the board_id value to victims id and publish a new stage with the name hacked in victims ATS Board wherein user_id and user_email parameters were not validated while processing the request in back-end

IDOR to delete a Stage: An attacker was able to delete other users Stage by using the valid stage id, since the stage id was numeric it was easy for us to brute-force and delete all the existing stages

Wrapping up for now, I hope this whole list of IDOR will give a better insight for you when you are testing any application. So that’s it for now and Thanks for Reading and I hope you liked this content, will meet you in next upcoming blog post with a new Learning and Experience!!!

Here’s an Instance how a Developer at HackerRank prioritize their work!!!

If you would like to connect with me refer this website

Thanks to Harishankaran for proof reading this blog post!!!!!