There is nothing worse than reporting a vulnerability and having it be invalidated - both for the researcher and the engineer evaluating the submission. I thought I’d run through a few scenarios of why that sometimes happens, and how researchers can help avoid it. I’m skipping the obvious “didn’t read the bounty brief and submitted an out of scope issue”, you can read about that on the Bugcrowd blog.
Scenario 1: The reproduction steps and attack scenario are incomplete and unclear.
Submitted:
An attacker creates a fake account and changes his e-mail. The e-mail confirmation link can now be used to login someone into the fake account and then then monitor actions performed by the victim or even interact with him.
Let’s break down why that is going to get rejected as invalid:
An attacker creates a fake account ← what kind of account? user? do they need to be an admin to do this?
and changes his e-mail. ← changes it to what? the victim’s email?
The e-mail confirmation link can now be used ← by whom?
to login someone ← the victim?
into the fake account ← why would the victim do this?
and then then monitor actions performed by the victim or even interact with him. ← so they can view the victim’s actions? can they access the victim’s account settings without victim interaction?
Also incomplete: only uploading a video POC with no written repro steps is inadequate and will result in validation delays and potentially submission rejection. Video POCs can be helpful, but they don’t replace your written report.
You have to fully explain the attack and it’s impact in your submission to effectively demonstrate the vulnerability to the customer and receive a reward.
Scenario 2: The submission requires another vulnerability to be exploited first
If a submission starts with “Suppose I am an attacker and (the user’s browser is compromised/I got access to the recovery email option of your $APPLICATION account)”, that means everything that comes next is not exploitable on its own and requires a second theoretical vulnerability in the application. While in some cases the report may recommend a legitimate security best practice (P5, 0 kudos points) to the customer, in other cases these submissions are simply invalid (-1 kudos points).
Scenario 3: the exploit impact is unclear.
Submitted:
An attacker is just required to send an email confirmation link to the victim & he’ll be automatically logged into his (attacker’s) account. I can then monitor his actions & interact
Ok, this means that the attacker has just compromised themselves by giving the “victim” access to the attacker’s account. The victim account is not in any way compromised, unless the attacker manages to elaborately social engineer the victim to give up their credentials to the attacker once logged into the attacker account. But if I can get you to click an email link, that isn’t a web application vulnerability the customer can patch.
We often debate priority with researchers that are focused on the bug type we provide as examples in our prioritization matrix and not considering the impact of the vulnerability. Ask yourself these questions:
- Can the vulnerability be remotely triggered without victim action?
- Does the vulnerability affect a single victim or multiple victims?
- What does the attacker achieve?
Here is another example:
Application Allows it users to change their USERNAME, and there is big issue is no prevention of account name takeover.
let’s explain:-
- suppose “Kymberlee” is change their username to Kymberlee1 ok but interesting bug is your application not blacklisting old username and anyone can takeover old username. and there is also no limit of username change.
security risk:-
i’m sure every researcher posting own cobalt,hackerone,bugcrowd links on social sites and other accounts for showing own rank.
but what if after 6th month of posting. user changed their username to another name? old link is stil not blacklisted any other fake core researcher can takeover old name .
So for you to “takeover” my username, I first have to willingly give it up? This is not a username takeover exploit but voluntary username abandonment followed by opportunistic name squatting. A user voluntarily giving up their user name is not a critical vulnerability. The ability to change usernames is intended functionality. Now if the attacker can change my username without my involvement, then THAT is a vulnerability to be rewarded and fixed!
One last example for fun:
- Create a $APPLICATION account.
- go to dashboard and click on $FUNCTIONALITY
- Enter all the details.
- There is a parameter called $NAME at the end of $FUNCTIONALITY
- Enter the javascript payload and you can see the popup.
This is a valid XSS vulnerability that results in elevation of privilege, but it is only a P4. Why?
- The attacker has to social engineer the victim to install code, this requires significant victim interaction and is not remotely exploitable.
- Once the cookie is stolen the attacker can only exploit that one victim; the attacker has to exploit each victim individually. The vulnerability does not affect multiple users or the system integrity.
Based on our vulnerability priority model, that would be a P4:
P4 – LOW Issues that affect singular users and require interaction or significant prerequisites
As a P3 affects multiple users.
P3 – MEDIUM Vulnerabilities that affect multiple users, and require little or no user interaction to trigger
Bugcrowd has thousands of awesome researchers around the world submitting vulnerabilities in our customer applications every day. Some have formal security education and others are self taught. Regardless of your pen test experience, if you’ve never worked in a security response team breaking down vulnerability impact and exploit risk to prioritize incoming vulnerability reports, bug prioritization can be tricky. CVSS is one approach to standardizing the objective classification and prioritization of vulnerabilities, and while it is imperfect (Heartbleed was a CVSS 5.0, which would be a P3!) familiarizing yourself with this model can get you in the habit of thinking about access vector, access complexity, etc.
Closing tip to writing great vulnerability submissions: think about and communicate “Attacker does X, Victim does Y (where Y may be nothing), Attacker now can do bad thing Z” in your bug submissions. This breakdown can really help make the risk immediately clear to both you and the developer who has to fix the bug!
-Kymberlee