How I Uncovered an IDOR Vulnerability That Leads to Disclosure of PII, modify any user Information…

Hello hackers, Today, I want to talk about one of my findings in a private program at HackerOne it’s an IDOR Vulnerability That Leads to the Disclosure of PII, modify any user Information, and 0 click Account Takeover

IDOR stands for Insecure Direct Object Reference and is a type of access control vulnerability.

This type of vulnerability can occur when a web server receives user-supplied input to retrieve objects (files, data, documents), too much trust has been placed on the input data, and it is not validated on the server side to confirm the requested object belongs to the user requesting it

Let’s go to the main story….

Firstly, I created an account on the site, let’s call it test.com, I was browsing the application as a normal user, and after a period of time, I noticed that when I tried to edit my profile information, the URL was like this: https://test.com/user/index.html ?id=18018. I decided to intercept the request with Burp and observe if I could see other users’ information by changing the value of the “id” parameter or Not.

The request will look like this:

after that, I created another account on the website to represent the victim. Referring back to the previous request, I modified the value of the “ID” parameter with the victim’s account ID.

You will notice that here you can see all the victim’s information, including their name, email, address, telephone number, and mobile number.

Now I Have two account

the first one represents “Hacker”

and the second represents the “victim”

from the “Hacker” account I try to edit profile information

before clicking on Update I intercept the request with the burp

Now, I attempted to change the email and username of the victim by replacing the ID of the hacker account with the ID of the victim account.

As you will notice, the data was successfully changed.

and To ensure that the data has been successfully changed without the need to log in to the account, I retested the request of the first bug using the victim’s ID.

To further evaluate the impact of the vulnerability, I attempted to change user passwords. Surprisingly, the application did not require the current password for password changes I was only required to enter the new password directly.

And as usual, before clicking on Update I intercept the request with the burp

From the request, I noticed that the password was changed based on the user ID.

Following my usual approach, I attempted to replace the ID of the hacker account with the ID of the victim account.

as you will Notice the Password is changed successfully

Now try to log in with the New email and password

I was able to log in successfully

now the Hacker can change the email and password of any user and the user can’t even recover his email