IDOR + Account Takeover leads to PII leakage

Hi Fellow Hackers & Security Enthusiasts, Today I am going to write how due to IDOR and I was able to do Password Reset of any user and can gain access to his full account where Credit Card, Address, SSN number, Email , ID was stored. and also If he changes his password in future I was still able to access is personal details. It was a critical vulnerability.

Before starting with the attack scenario, let’s see some basics about IDOR

Insecure direct object references (IDOR) are a type of access control vulnerability that arises when an application uses user-supplied input to access objects directly. IDOR vulnerabilities are most commonly associated with horizontal privilege escalation, but they can also arise in relation to vertical privilege escalation.

So, let’s call the target as target.com. and It was a private program. I started with the Recon on the main domain. Used Shodan, GitHub to get any sensitive info. but was unlucky. Now after Recon I Started to understand the application how it work. Because this is the second stage after recon. Just Open the Burp. and start to analyze the application how it work, how it process the request, see which methods are allowed. analyze the Source Code for any secret-api key , or any token, or endpoints.

After getting a Idea how It works, I started testing the application. After roaming across with the application, I came to the User Profile section. and I noticed that to change the password we don't need the current password. then i was like can we do CSRF on this ? first thing came up on my mind is CSRF. I fired the burp and analyzed the request. So I noticed that there was no CSRF-token. I was like cool. But CSRF was not working since they were using different type of encoding.

But wait-wait, what I noticed that it was using User Id to change the password. I was like wow wow. without any delay I just created one more account and exchange the User Id and changed the Victim Passwords. after clicked on Go. Man It was 200 response with True in body response. I Just checked victim password was reset successfully without any interaction.

I thought to quickly report but wait wait. See this request first.

GET myaccount/api/user/<user_id> HTTP/1.1
Host: target.com
Cookies: session=xxxxxxxx

I always think If i was a triager what would I ask the researcher on this report. I would ask him how to get the User-Id of the victim. Since Its very difficult to bruteforce this User-Id.

I just ran ffuf on the domain to see if any sensitive directories where User_Id can be stored or any file where I can see how this User-ID is generated. But no luck.

I also analyzed the JS file but no luck how the user Id is generating. I was thinking what’s the hell. I only need a ID to reset the password and can takeover the full account. I was like frustrated.

Then what I just closed my laptop thought to take some rest. I again picked up in the evening. I started to see my HTTP history. and I noticed a weird endpoint. where it was taking email Id in json request body.

I quickly sent it to repeater tab. and clicked on Go. Oh Man I was amazed by this endpoint. See the Request and Response from this endpoint.

GET checkout/api/user/ HTTP/1.1
Host: target.com
Cookies: session=xxxxxxxx, In request body It was tacking two parameter like this : {“email”:”test@gmail.com”,”tracking_id”:xxxxxxxx}

I just changed the email id to victim and boom it was second IDOR I Found with the ID which will help in account takeover. this endpoint was leaking ID of the user. and some sensitive details.

my reaction was like :

Now I have 2 IDOR and through which I can do account takeover. and but wait I want to dig more in the application.

Now I started to play with the cookies. I notice there was some cres_ID in cookie parameter. then what i have done I exchanged it with the Victim.

Guess what ?????

I got the PII leakage there. Credit Card, Billing Transactions, address, ID, postalcode, city, subscriptions etc.

I was like wow wow……. Now I Know You will be thinking how to get cres ID. from the victim. since there was no XSS. otherwise we can fetch the cookies from it.

So I noticed that the Cres_ID token was a static token, After 5 days I tested again and it was same. So I conclude that after account takeover attacker can save the Cres_id by intercepting the request. let’s say victim changed his password. if we have his cres_id. we can access all his details. If Victim changes his payment method, I will get to know ;). that’s how Can IDOR become Critical.

Takeaways:

• Mapping the application always plays a big role in crawling endpoints.
• Always try to increase the impact of the vulnerability.
• Always read the writeups and be consistent.
• Always see the every endpoint carefully.

Timeline:
Bug Reported: 8 October 2021
Response : Out of Scope

I was literally frustrated after looking this. they think I have reported authentication Issues.

But you guys now that IDOR falls in BAC(Broken Access Control.)

there was totally a PII leakage. Done full account takeover without any interaction. Could Comment on behalf of user. Can Change his email id. and can delete his account, can see his credit card no and personal info. what do you want more in the impact.

So now you will be thinking. I just said bhagwan dekhega is triager ko (lol). I was really angry with this kind of response from the bugcrowd triager. No Response from them till now. this would have come in P1. and I would have awarded 6000$. Since It was a big Company. But totally Unsatisfied.

Pro Tip : Just move in the life don’t stop. and take it as positive way that you know the skills and move on.

Thanks For Reading this. In future I will be posting many writeups. Next Writeup Is On “XSS on Atlassian” and “Email Verification Issue lead the disruption of data of users.”

If you enjoy reading It please give it a clap. and do follow me on twitter to get update about my next writeups.

Twitter : https://twitter.com/shivam24rai

LinkedIn : https://www.linkedin.com/in/shivam-rai-59611a157

Have a Good Day !.