, or why being too quick can lead to a false positive

I have a theory that this probably affects more those who have some experience in bug hunting, and presumably the higher the level of experience more likely to make this oversight. I could be wrong. Either way, I figure this will be useful for any level of experience, sooner or later :)

When it’s easy to skip that crucial step one
This one has been written a ton about — recon. But, depending on the website target, your level of experience, and similar, it can be easy to “skip to the end” even though you started with a perfectly reasonable recon. While it’s possible to multitask during the recon process, like digging into interesting subdomains while you’re waiting for ffuf or dirsearch to finish going through whatever giant wordlist you have or running nmap/masscan, this is where skipping the basics can throw you into submitting a very silly “bug”.

Why skip the obvious bug?
In one word — it may not be a bug. If you have just opened some interesting subdomain, or even a single/narrow scope target website, following requests and responses in order to learn about how the website works has to be done all the way through. It’s not just about understanding the requests and responses that are being made, but also why they are being made and how it all relates to the rest of the website’s functions/features. Just because there is a JSON response with seemingly interesting information, you have to understand how it got fetched. While the paired request may be the obvious cause, it’s not always. Sometimes there’s a chain of requests and responses that result in a specific response down the line. Meaning, just because JSON response shows userid and api token, if you didn’t log in, it’s very likely that it is a guest userid with a guest api token (or api token that has no critical impact to anyone).

When experience can cause some harm
As someone who has been doing IT security testing for over a decade by this point, sometimes it’s hard not to spot the interesting request and/or the content of the responses to certain requests, etc. And at times it’s easier to just go for it. When something looks like a bug that’s easy to quickly verify then of course the order of things: the recon, the smart approach to website testing especially (ie. Learning how it works, what it does, etc. in order to know better how and what to target) suddenly gets replaced by the desire to exploit this bug, and to hopefully avoid a duplicate.

Lack of patience = false positive, in three Acts
Act 1 — The unnecessary urgency
In this particular case, I got excited about the idea of urgently buying a real beast of a gaming PC because I wanted to continue playing a specific video game at the highest RTX graphics :) and therefore I allowed for the lack of proper patience.
I picked a bug bounty program and went for it. And as I was analyzing burp history while browsing the website for the very first time (meaning, I had very little knowledge about it) and eagerly looking for any sign of a potential bug, I couldn’t help but notice an area to attack immediately — elevating user role from low-level user to admin.
So… without exploring what a low-level user was allowed to do compared to the admin user, I logged in as a low-level user, and using Match and Replace in burp, I added the rule where the response body would replace “user_role”:”user” to “user_role”:”admin”.

And upon refreshing the page, I saw my dashboard showed admin instead of a low-level user under the user role. But, nothing else changed. No additional pages, buttons, nothing.

Act 2 — An interesting discovery
And here is where I made a mistake, without “resetting” (ie. Disabling the Match and Replace rule from earlier) I proceeded to use another feature of the website thinking maybe I’ll see some interesting stuff when that page loads (while not having any idea how it is supposed to look like when visited as a low-level user). But, there was nothing interesting there. So, I got back to the dashboard, but to my surprise, I suddenly did have some new buttons. I immediately proceeded to verify that it wasn’t just a UI change. And, it wasn’t just a UI change. I was actually admin, I was able to add other users, change user roles, etc.

Act 3 — Patience that lead to the uncomfortable discovery
Great, report submitted. But, I couldn’t shake that uneasy feeling, like how easy it was, and my initial worry was that it would turn out to be a duplicate. Of course, that wasn’t the only worry. And after calming down about the silly urgency that got me to find this bug, I had to look into this website further. I did also hope that I would find something else, just in case if the initial report turned out to be a duplicate. This time I did it the right way. I learned more about how the website works, its features, and so on.

Which lead to the discovery that, for whatever reason (I guess it’s coded that way) if a low-level user would use a specific website feature, their role would get converted to the admin role. It is like that by design, not a bug, nor even the old joke “it’s a feature.” I know that for certain because a few days later I was told the same by the very reasonable triage person.