This is My First Blog and I am really excited about it at the time of writing this. I have been trying to take out time to write this finding up for a while now but haven't been able to do so because of other important things, anyways finally here we are. Without wasting any more of your time, let's get into the bug :)
Let's call the target website as example.com and the domain on which this vulnerability was found as subdomain.example.com for the Privacy of the company. The Vulnerability exists in the Forgot-Password Page of subdomain.example.com. Basically, while requesting a password change for a user, a GET parameter was sent. I was able to manipulate this parameter and was able to view the Personal Email addresses of probably all of the registered users on the website. This was a pretty simple bug and a typical case of an IDOR .
One day, I was checking the results of my Recon which was done using my custom bash script and while going through the subdomains it had found, I noticed an interesting subdomain. Lets call the subdomain as
subdomain.example.com. I started crawling the subdomain to find all of its URLS using an awesome tool made by @TomNomNom called
waybackurls. I am not going to explain how this tool works or what it is, you can find the Link to it's public Github Repository at the end of this Blog post. Basically I found an Interesting URL with
waybackurls which is:
https://subdomain.example.com/accounts/Directory/XYZ/Form.aspx. This endpoint was actually a Forgot Password Page and it allowed users to request a password reset. Nothing fancy or alerting right now but let's see what happens later ;) The extension of this page was
.aspx which made me Directory Brute force for other
.aspx files. Unfortunately I did not find anything and eventually gave up on Directory brute forcing. Now I thought of using Google Dorks on this subdomain. I used the following Google Dork:
When I did this, I got an endpoint as a result of the search. This endpoint contained
ID as a
GET parameter in the URL with some other irrelevant parameters. The final URL looked like this:
The interesting part was that in the response, when I scrolled down, I could see a random user's personal email address. I got the following response:
Email Sent successfully to firstname.lastname@example.org
The HTTP Response looked like this:
HTTP/1.1 200 OK Date: <SOME-RANDOM-DATE> Content-Type: text/html; charset=utf-8 Content-Length: <CONTENT-LENGTH> Connection: close Cache-Control: private, s-maxage=0 Vary: Accept-Encoding X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff Content-Security-Policy: default-src 'self' 'unsafe-inline' Referrer-Policy: same-origin Email Sent successfully to email@example.com
I found this very interesting and as a result I got excited. I knew exactly what to do, I changed the value of the
ID parameter to another random numeric ID and yes, I got another private email address of a user! This time I had changed the ID from
2. I noticed that even 4 digit long numeric IDs were tied to a user's account. Now, it was time of a nice Proof Of Concept to increase the impact. I fired up an Intruder Window in BurpSuite, configured it to Brute-Force the value of the
id parameter that was found earlier in the URL, and started the Attack. I looked at the Intruder again after letting it run for a few minutes and was surprised by being presented to more than 50,000 private email addresses of the users!
This means that with the change of the ID parameter I can leak the private emails of users of this web application. Basically, this means that the ID's value 1 is linked with an email that is
firstname.lastname@example.org and the ID's value of 2 is linked with the email
Basically this Attack worked because the application assigned every user's account with a numeric ID from
ID of a user could have been guessed easily as this application kept the IDs sequential meaning that if two users sign up, User A and User B, User A signs up a minute before than User B, then User A will be assigned with an ID of
1 and User B would be assigned with an ID of
2. Intruder Brute-forced all the IDs till 50,000 and since these IDs were sequential, this meant there were 50K users signed up on the web application but more importantly, an attacker would be able to view the Private Email Addresses of More than 50K Users!
By exploiting this IDOR vulnerability an attacker is able to leak private email addresses of about 50,000 users which is a clear privacy violation for the users. The attacker can store these email addresses in a database and plan future attacks on them.
- To Leak the Private Email Address of a User, no user interaction was required at all.
- The ID parameter was vulnerable to IDOR attacks.
- The ID parameter had a numeric ID to which objects(emails) were referenced.
- The value of the ID parameter was predictable and an object is linked to a user's account in a sequential pattern. In this case, these IDs with values from 1,2,3,4,5,6,7 and so on were referred to as Private Email Addresses of the users.
Due to these points, the severity of this vulnerability was High.
Resources, Credits and Shoutouts
- @TomNomNom's Github Repository: https://github.com/tomnomnom
- Waybackurls' Public Github Repository: https://github.com/tomnomnom/waybackurls
- Thanks to @Bugcrowd for the Diagram that I used.
- Checkout @ProjectDiscovery's Github Repository for some cool Stuff that they publish: https://github.com/projectdiscovery
- Follow @Intigriti on Twitter and Sign up for Weekly BugBytes that they release every week, to stay up to date with the best resources!
- Intigriti has archived all of the BugBytes that they have released till date here .
- Join my Discord Server by clicking here.
- I recommend checking out all the content made by @Zseano. He has made BugBountyHunter.com which is more realistic than other CTFs and is overall better :)
- Lastly, @InsiderPhD's YouTube channel has helped me out in my journey a lot! I recommend checking it out.
Thanks for Reading this, hope you enjoyed my first blog :)
Many more to come xD
Until next time!
NOTE: The awesome artwork used in this article was created by Denis Abdullin.