Story of a very lethal IDOR.

infosecwriteups.com · kh4sh3i/bug-bounty-writeups · 17 hours ago · bug-bounty
quality 6/10 · good
0 net
AI Summary

A researcher discovered a critical IDOR vulnerability in an e-commerce platform's address book functionality that allowed account takeover by manipulating user ID parameters in API requests, which was discovered after exploiting a stored XSS in the same feature.

Tags
idor account-takeover stored-xss authorization-bypass bug-bounty web-application parameter-manipulation authentication
Entities
Vedant Tekale Vegeta
IDOR that allowed me to takeover any users account. | by Vedant Tekale | in InfoSec Write-ups - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original IDOR that allowed me to takeover any users account. Hello all! My name is Vedant, also known as Vegeta(on twitter). I'm a cybersecurity enthusiast, computer engineering student and a bug… Vedant Tekale Follow InfoSec Write-ups · ~4 min read · February 17, 2021 (Updated: December 31, 2021) · Free: Yes Story of a very lethal IDOR. Hello all! My name is Vedant, also known as Vegeta(on twitter ). I'm a cybersecurity enthusiast, computer engineering student and a bug bounty hunter. Today I'm going to share one of my best findings with you. So little bit info about the target, it was a RDP let's call it target.com for now. It was basically an online shopping website with lots of functionalities. So without any further ado, let's get started :) Phase 1:- So as target.com had lot's of functionalities for me to play with, I decided to create an account on it and start finding some basic vulnerabilities without doing any recon. So I turned on my burp and started to capture the requests. I didn't find anything interesting in registration or login functionality, but the password reset and some other functionalities were vulnerable for rate limiting attacks. While creating an account on any website I enter my name as

tester

to check for HTML injection and XSS, so while creating an account on target.com I did the same and logged in and visited my dashboard but unfortunately the h1 tag didn't execute. I continued to look for stored XSS in my profile section but any of those fields weren't vulnerable. Then I went to address book section and there also I entered the same payload in all the fields and this time it worked on first name and last name fields :) Then I quickly changed the payload to a simple XSS payload( ),clicked on save changes and yeah, the stored XSS triggered successfully! But then a question came to me, how can I exploit this? Then I remembered I encountered this kind of situation once before(If you read my previous blog then you know what I was thinking) I tried to exploit it by changing my first name and last name fields to a blind XSS payload and I waited for 2 days hoping that an admin would visit my profile but no, seemed like admin didn't care about it that much. Then I tried to exploit the stored XSS with CSRF attack but it didn't work either. Phase 2:- After trying all possible things there I almost gave up on that stored XSS and started to look for other vulnerabilities. I tested almost every vulnerability that I usually look for in any target but nothing worked :( at this point I was really frustrated. Then I visited that address book section again and that self stored XSS triggered again so I clicked on edit address to remove that XSS payload(it was triggering again and again and it was really annoying for me😂😂) and then I observed the URL it was like following, https://www.target.com/my/addressbook/3091 6 After looking at it you probably have an idea what to do here, I changed that number from 30916 to 30915 hoping to see other people's address book but no, a message appeared saying, " you are not allowed to perform this action". Then I got to edit address section again and removed that XSS payload and this time I intercepted this request and then I observed the following parameter in the request, This time I changed the Id parameter from 30916 to 30915 and forwarded the request and message appeared saying Address changed successfully, but that stored XSS triggered again😂 but this time I knew exactly what happened, I changed someone else's address book :) To confirm this I created another account and got it's address Id and with my first account I went to edit address section and just clicked on save changes (keeping that XSS payload as it is), intercepted the request, changed the Id from my first account Id to second account Id, forwarded the request and this time it worked like a charm! As the Id was easily guessable and there was no rate limiting on any endpoint I could easily takeover any user's account :) So I went from self stored XSS →IDOR →Account takeover . As this was a RDP, sadly I didn't get any bounty for this but I learned a valuable lesson from this finding. We have to get out of our comfort zone to achieve great things. If I didn't even try to find that IDOR vulnerability I couldn't have achieved this account takeover. If you enjoyed reading this please do clap on it :) If you have any doubts regarding this write-up you can DM me here . Until next time, good bye and happy hacking! #bug-bounty #bug-bounty-tips #cybersecurity #infosec #hacking Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).
← Back to stories