IDOR on USA Department of Defense Website leads to Account takeover without user interaction
Hello folks, and thank you for reaching out to my blog to read about one of the most simple yet efficent and nice vulnerabilities that i have found while hacking on the DoD program on H1 https://hackerone.com/deptofdefense
I haven’t uploaded a writeup in a while so i hope you will enjoy this one, and learn something new to your toolset.
This writeup is based on my disclosed report which can be found here: https://hackerone.com/reports/969223 And it will be redacted as long as it needs to not disclose any detail about the specific DoD domain.
So, it was another day of me interacting with the DoD program, and as i have studied most of the fundamentals of Bug Bounty and Web Application Security, i have decided to get myself going with the DoD program, due to it’s huge scope and technologies.
I was Google Dorking for login and signup pages within the DoD program, which have many functionalities stored within them, and they posses a good place to start.
I encountered a signup page which didn’t look like the normal one of the DoD (Which requires a CaC card), so i decided to dig in and mess with it a little abit.
Upon creating my account, i have tried to navigate to the account settings page, i was being presented to the following url:
from a first glance, we cant see any id or IDOR parameters on the url, so it doesn’t look good for us to find any errors on that page within GET requests, not talking about IDORS.
Upon clicking the “Update” button, and capturing the request with Burp, i was presented with the following POST request:
Okay, this is where i’m starting to realize that we might have a jackpot here.
I was asking myself why would the website would like me to send my id as part of the post request? as it should fetch it from my session cookie or supplying other security measures.
So, i quickly registered for myself a second account on the website, and i noticed that my id parameter has been assigned the number of 624 (the original one was 623).
I logged out from my victim account, and triggered the POST request i had captured with my original one, supplying the id of my victim, and sent the request.
My tampered request would be supplying the victim user ID, and changing his email to one which i have possesion of, so it should have looked like this:
And i got the following response:
Success at last, i managed to takeover my victim account, with a single post request.
Lets hover on the flow:
- Capturing the “Update” request on burp
- Supplying victim id number
- Changing the email to one with my possesion
- Sending the request, and the victim’s email has changed
- Issuing a password reset request to my email
- Successfully taking over the account.
I have issued a report to the DoD program, which got traiged within a few hours:
The easy to implement remidiation steps should at least consist the following:
- Implementing email request change based on OLD password input
- Returning 403/401 when user account attempts to change another user ID settings.
So, after presenting to you the severe yet simple IDOR i have found on the DoD, those are the key takeaways i want you to take from my blogpost.
Think outside of the box
When you encounter a program with alot of assets, don’t just stick to the normal content discovery and subdomain recon tools, try to think and reflect at first where i might have the bigger chance to find vulnerable endpoints and misconfigurations. Google Dorking is a great asset to express your creativity while supplying various of search queries to find specific and accurate data about your target
Avoid rabbit holes
We need to be mature enough to understand if a specific endpoint is hardend, or we might find vulnerabilities in it.
The vast majority of DoD login pages are using the same login functioniallity, asking you to supply a CaC card and is hardend with many security measures.
Although someone might find a misconfiguration in this process, we should identify that it’s less likely to find one and invest more on our recon to find the web pages which are stick out differently to the common coding and work ethics of the company.
Investing our time on domain specific and unique designs insted of the wide and common functioniality which is being used on most of DoD websites will make our researching time more efficent and fruitful, and will help us avoid being burnt-out.
I really recommend that you set yourself monthly/weekly goals, some days or weeks you won’t find anything, and one day you will find a Critical bug without any preperation and expectation.
As you might notice, by the time this report was triaged on the 27th of August, i had 192 reputation points, and i haven’t gotten my first reward from bug bounties.
Today, as of the day i have written this report on November 7th 2020:
- I have reported bugs which rewarded me 4 digits in total
- I have passed yesterday the 1K reputation mark on H1, 704 of those points on the DoD program
- I have reported vulnerabilities to major companies including H1, BugCrowd, Samsung and more..
During that span of time I have done many things to boost my Web Application Security level, such as:
- Completing most of Portswigger labs https://portswigger.net/web-security
- Building my own Automation tool on my VPS using the great open source tools of https://twitter.com/pdiscoveryio
- Reading alot of tweets, writeups, videos from fellow bug bounty hunters in the community.
The point here is not to brag about myself, is to inspire you to put those hours and dedication to the things which drives you and makes you wake up at night.
Thanks for sticking out!
Hope you enjoyed reading my writeup, and i hope you can implement one of the tips i have supplied below to boost up your Bug Bounty Hunting Game!
If you did so, Please share my blog to spread it upon the Bug Bounty Community :-)
You can find me on:
- Twitter: https://twitter.com/naglinagli
- H1: https://hackerone.com/nagli
- BugCrowd: https://bugcrowd.com/Nagli
- Linkedin: https://www.linkedin.com/in/galnagli