Part – 2
Authenication & Authorizaion Attacks
Quintius Walker, Grey Hat Developer, Cybersecurity Consultant
23 October 2023
Photo by Markus Spiske on Unsplash
Everything, and I mean absolutely everything on this blog that surrounds the term “hacking” is meant for training and educational purposes only. WE DO NOT ENGAGE IN NOR PROMOTE ANY ILLEGAL ACTIVITY!
In a world of Reels, Vids, Tutorials, and Write-Ups, as much as it seems we’re dining at a buffet that’s spread and stretches longer than Interstate 10, there really isn’t a lot of variety among our choices. The taste of an entree is only exquisite in presentation, design, and delivery.
So I pondered on this and posed the question to myself, “how can I sat a unique flavor out on the buffet table with my contribution?”
The answer ushered an epiphany. From now until infinty, readers of this blog who appreciate lyrics, poetry, and prose are in for a treat. We’re about to call upon the genius within and set it off!
Authentication and Authorization Attacks: Part 2
In the following screenshot we have an account with a username, some details about the user and what appears to be the type of account that we’ve accessed, which in this case is “user”. If we turn our attention to the address bar of the web browser, we’ll notice the url has a parameter with a value being passed to it. (account=1009).
According to the account details, we’re currently logged in as the user Isabelle. As Isabelle, we’re sitting at our desk bored out of our mind. Idle time gets the best of us, and we think, “I wonder what would happen if I changed the number value in the url to something different?” In fact, we are so bored that we opt to change the number value into a word that perfectly fits the mood instead. Bored!
We’re amused that the web application doesn’t agree nor care that we are bored. And however much so bored we may be, we discover that bored doesn’t even have an account. So, intending to change the value back to what it was before our boredom got the best of us, we mistakenly enter 1001 instead of 1009 and are royally shocked to discover that we can access the user Alice’s account information.
Still bored as heck, we decide to be nosy, incrementing the number values consecutively and looking at the information inside the other user’s accounts. Somewhere along the line things went from boredom to interesting when we stumbled upon some account types that apparently were not regular users like Alice and ourselves, but “admin” types like Harry, Jack, Lucy, and Nancy.
At this point we’re far beyond bored. Now we are curious….
And that, ladies, and gentlemen, is an example of an IDOR vulnerability.
Fortunately for us bug hunters and web hackers, not only are we never bored out of our minds with our craft, but we also have super cool hacking tools at our disposal and thus, don’t have to spend a lot of time manipulating parameter values manually when searching for IDOR vulnerabilities in web applications.
Side note: We also don’t have accounts in these web applications as do the users in the above example. Therefore, we’d need to create a few accounts on the site to test the application for the bug.
But once those accounts are set up, the process for us would look something like the following:
First, we’ll capture our request with our proxy tool.
They hide behind a firewall
and hope that they can stop me,
It’s time to hack the web
so watch me,
fire up my proxy.
Next, we’ll fuzz our request.
They thought that I got sloppy
but I’m not
they made me madder,
So we can F-F-UF
or can Zap it,
it don’t matter.
Here, we’ve found the admin account of the user Harry.
Significantly
impacting applications that expose,
A resource in the database
or file that he controls.
Here, we’ve found the admin account of the user Jack.
Identify the weaknesses
before they reach production,
Cause IDOR vulnerabilities
Don’t need no introduction.
Here, we’ve found the admin account of the user Lucy.
If a user somehow
can access the pages that’s restricted,
This may lead to the elevation
of that user’s privilege.
Finally, an admin account of the user Nancy.
What’s the takeaway from this,
what makes it such a vuln?
This means that your entire application can be owned.
Again….
The takeaway from this,
that makes it such a vuln?
It means that your entire organization can be Pwned.
We hope you’ve enjoyed learning about IDOR vulnerabilities. If so, check back in a few days when we’ll be continuing our coverage of Authentication and Authorization Attacks: API’s. If you’ve been enlightened in any way, please share this with your network. Also, subscribe and connect with us on your favorite platform.
As always, Hack on, Ladz & Gentz!
