A Simple IDOR to Account Takeover
Getting Started with IDOR, What is IDOR?
IDOR refers to Insecure Direct Object Reference which means you get access to something which is not intended to be accessible to you, or you don’t have the right privileges to execute that action on the web application. Technically it’s an access control issue that occurs when an application uses user-supplied input to access objects directly without any validation check to see if the request is made from its intended user or not. IDOR can be further related to Horizontal[exploiting application user pool] and Vertical[exploiting admin user] Privilege Escalation.
So assuming the program name to be example.com since it was a private program. Initially I wasn’t able to find any issue on the main domain and later gave up after getting 3 duplicates since it was a 3 years old Private program and I got the invite around October 2019.
Later in 2020 new year with a new vibe I blindly started searching for Vulnerabilities on the same program with a proper approach and Methodology, I took a glance over the program scope and saw that there where few subdomains which got my attention since it was having no known Vulnerabilities so I thought it is a good chance for me to break it down.
Within two Hours I got 4 Vulnerabilities in which Account Takeover was one of them. Lets see how was the approach in discovering it, So first I tested the login page , Registration page and the Forgot password page. While testing for the forgot password I saw that when the user changes the password to a new password the Email parameter was present in the Request body along with the new password and confirm new password parameter, So I thought why not change the email to someone else’s email id and finally when I did the same it gave me a full account access to the altered emails account.
Original Request:-
POST /login/internalResetPasswordSubmit?Toketoken=random_char&m=1234&nid=random_char HTTP/1.1
Host: subdomain.example.com
Cookie: all_required_cookies
{"email":"attacker_account@test.com","password":"new_passwd","confirmPassword":"new_passwd"}Edited Request:-
POST /login/internalResetPasswordSubmit?Toketoken=random_char&m=1234&nid=random_char HTTP/1.1
Host: subdomain.example.com
Cookie: all_required_cookies
{"email":"victim_account@test.com","password":"new_passwd","confirmPassword":"new_passwd"}So after forwarding the Edited Request in Burp the password will get changed for the victims account and it will directly log you into the Victims Account in the Browser.
The Impact can be increased by changing the admins Account Password thus getting full access to admin account.
I Reported this at 12:30 am IST on 28th January
Got response from the team in the morning saying not able to replicate and asked me to takeover the test account created by them. So I wanted to reply them as soon as possible but when I received the comments on my report I was in college so I decided to reproduce the issue in our college lab, For that I somehow managed to setup the tools and pre-requisites in our college computer and when everything was ready I finally reproduced the same and changed the password of the test account created by the Bugcrowd Team and edited the profile with my username for proof of concept and sent the report.
Within 5 mins the report got Triaged and the priority was set to P1
And the next day the company allotted the Bounty for my submission which can be seen in the above Screenshot.
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!!!
If you would like to know more about me refer this website
