How I could take over any Account on a USA Department of Defense Website due to a simple IDOR
- 4 minsIDOR on USA Department of Defense Website leads to Account takeover without user interaction
Greetings
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.
Digging in
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:
https://DOD.mil/signIn/account
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:
id=624&fName=hacked&lName=hacked&email=hacker@wearehackerone.com&phone=12345
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.
Thanks for sticking out!
Hope you enjoyed reading my writeup!
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
Gal Nagli
A Man who enjoys the art of study, breaking stuff when I can.