Why are bundled occurrences valued less?

[am0o0]

Hello dear Huntr team
I hope you always have a great and nice days
bundling feature is a good idea in my opinion but there is somethings as a security researcher that bothering me :

1.If an application ( mostly web apps ) already has a good and strong XSS protection then I found a XSS on it I will get a full bounty amount but there is a problem!!! for finding second XSS I should searching more and more as this will be exist harder finding procedure after first one that I found before OR The second XSS get my time as same as first one but give me only the 20% of first one

2.The same issue like 1 but for CSRFs that assume a App that already have a good CSRF protection and I found two CSRFs in it and this take my time for every of them 30 min (totally 1h)

in these situation we can find out that if there isn't any side-wide CSRF or XSS this can be very hard to trying to find second same kind of a vulnerability

some other situation like recent VIM report I can guess that the current bundling system can be make a big loss in motivation of security researchers as for A bug like BOF if we want to find a second one for it we should put 4x more time for finding second BOF rather than the first BOF with only 20% of real bounty.

[adam-nygate]

Hey @amammad, I've moved this over to a Discussion to hopefully promote collaboration from the community (rather than leaving it as an Issue for bug/feature tracking).

You make some good points, but we feel like that this is at an extreme and that for most reports, this isn't the case. Most submissions we see today are people finding a lot of occurrences in vulnerable applications, and that for this scenario a reduced price for each occurrence is fair for everyone (so that researchers get equal opportunity to earn from an individual pot, and so that maintainers get the most value out of their pot, rather than all the pot going to a single researcher, for a single type of vulnerability).

If a maintainer (or another sponsor), finds the quality of contributions compelling to fund the bounties, they'll have full control over the pot and how to value reports, and so will be able to better define how money is spent.

[am0o0]

The bundling feature should be exist forever in my opinion !!!
But your current procedure have many problems and I think this can be better if you do this :
with example:

I found 3 CSRFs then we have two ways :

1. They are same vulnerability that can be fixed with one commit and also need one CVE
2. the site is already CSRF protected and need three commit for each CSRF and need Three CVE

till here If anyone have any opinion against these states I want to ask write and after that we can continue further ....

[am0o0]

Well, here the way that when we encounter these two ways :

we can check that all CSRF reports for the same Repo ( can reported from multiple hackers ) then if some reports fix commits be same then we notice that the reports all same and should get one bounty and Also should have one CVE not two or more
Otherwise that commits are different we can get each of them a CVE and separate bounty

more complex example :

we have three CSRF reports like these
A , B , C

A and C have same commit ( and can be reported by different bug hunter ) and then one of them can get bounty and CVE

B has a different commit from A and C and we can publish A separate CVE and give separate bounty for it

At the end we have Two CVE for two different CSRFs

another complex example :

We have 8 CSRFs like this
A1 , A2 , ... ,A8

All of this Have same commit and reported by different of same bug hunter

For all these suggestions *** We should ask maintainer to submit for each report a single commit not one commit for all reports that came from Huntr.dev to them

[am0o0]

My suggestion for reducing the bounty amount

first at all Huntr should give bounties according to the CVE score with a base bounty for each report

this is my idea :
for a repository we have two report, a RCE and a XSS
this repository gave hunters 25$ for each report before that but with new feature hunter get more bounty for a RCE rather that XSS
and now huntr Give for RCE 50$ and for XSS 15$ which it is fair and if you ask me huntr should give hunter more bounty then I can said that the RCE is a vulnerability that hard to find and if huntr want to their hunters found more impact vulns then they should give more bounty as the number of RCEs in a application often is less than 2

hunter should motivate hunters to looking for more impact vulnerabilities rather than others

There should be a blacklist CWEs here :
for example some of hunter report the httpOnly cookie that haven't any impact at all.

or There can be a graylist here :
for reports like httpOnly CWE or secure cookie CWE huntr can give hunter a thanks or 5$ bounty.

All of these lists in my oponion can be created by hunters ( top 40 or top 100 or ... ) and then the huntr team can buy more time for other stuffs.

[arjunshibu]

My suggestion for reducing the bounty amount

first at all Huntr should give bounties according to the CVE score with a base bounty for each report

this is my idea :
for a repository we have two report, a RCE and a XSS
this repository gave hunters 25$ for each report before that but with new feature hunter get more bounty for a RCE rather that XSS
and now huntr Give for RCE 50$ and for XSS 15$ which it is fair and if you ask me huntr should give hunter more bounty then I can said that the RCE is a vulnerability that hard to find and if huntr want to their hunters found more impact vulns then they should give more bounty as the number of RCEs in a application often is less than 2

hunter should motivate hunters to looking for more impact vulnerabilities rather than others

There should be a blacklist CWEs here :
for example some of hunter report the httpOnly cookie that haven't any impact at all.

or There can be a graylist here :
for reports like httpOnly CWE or secure cookie CWE huntr can give hunter a thanks or 5$ bounty.

All of these lists in my oponion can be created by hunters ( top 40 or top 100 or ... ) and then the huntr team can buy more time for other stuffs.

@amammad I agree with you man. Recently I found a critical RCE in a famous framework. The original bounty for disclosures against its repo was 300$. But when I tried to report, it was reduced to 125$. Turns out, one guy reported another issue a few hours before me and it's very less severe than my vuln. The thing is, in order to get the 300$ bounty, I have to wait for 30 days to report after his vuln gets validated, which I have no idea when would that be. If bounties were paid based on severity, this wouldn't have happened.

[am0o0]

I forgot to say a problem that can be exist in the ranking
Huntr should consider this that many of reports CVE scores are incorrect for example some CSRF vulnerabilities have 7.5 score for a little impact such change the state of a data not removing or creating data.
then Huntr can't trust the reports score to give hunters bounty according to that.

[am0o0]

I say that Huntr should only give bounties according to a categorized CWEs for example :
(RCE,SSRF) --- > 50$
(XSS,CSRF)---> 25$
(open redirect ) --- > 10$

A hunter can give own report ( a open redirect vuln ) 7 score and if you rely on score of a report then you give the hunter 25$ or 50$ bounty.

[adam-nygate]

Yeah, we know that we can't use CVSS scores as they're too subjective, but if you're able to compile a ranked list of CWEs, we can use this :)

[am0o0]

I do this very soon dear adam

[jaapmarcus]

There are multiple issues to solve:

1. How are we going to stop the number of reports simalar issues in this case bundling makes sense and is often totally valid.
   For example a XSS issue was reported 2 times as there were 2 templates used by the same main script. It doesn't make sense to create 2 different reports for it and or almost. Or 2 times in the same file towards 2 different end points.
   The issue is how to see if it is just an oversight of the maintainer / developer and

2. Valid report(s) with a low / none impact. I have seen multiple reports where the impact is so low (And according the researcher) still scores a 7.5. How ever the worst thing that could happen was logging out the user... Offcourse the report is valid and the "issue" should be fixed but it is not worth CVE in this case personally.

3. The impact for some reports have a way higher impact on the user then others and should be rewarded in such way. For example if I found a method to "hack" into an users server without user interference and the lack of csrf tokens + few other "weaknesses" and finally get root access should be paid more then a CSRF where the user accidentally log out or change the setting

It makes currently more sense to report 10 / 20 low impact vulnerabilities vs 1 large higher impact vulnerability that takes 3 times longer to find... And If recive 20 low impact vulnerabilities I could think this is a crappy "system" lets ignore it in the future..

4. CVE score vectors should be visible to the maintainer and if they disagree there should be a way to adjust it. For example on a project of mine even with xss Injection and the "attacker" got access to the full session data there are still additional checks in place to prevent any kind of abuse...

At least this will make it possible to change payments on CVE score easier.

[adam-nygate]

The issue around using CVSS scores is that many maintainers don't understand this framework, and the individual vectors are highly subjective and possible confusing. I.e Will a maintainer understand the distinction between a changed and unchanged scope?

Preliminarily we'll be enabling maintainers to manipulate the reward price directly so that they can influence what they find is low/high impact (#2136), and the future may look to do something like CWE ranking in order to influence the reward further.

[jaapmarcus]

I think it is an issue even on the researches side: For example a "exploit" as CSRF that requires a link to click or submit a page by a user should be marked as Local instead of Network: See https://www.first.org/cvss/v3.1/specification-document "Table 1"

The attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability (e.g., using social engineering techniques to trick a legitimate user into opening a malicious document).

So explain it to use maintainer / research more clearly...

For example https://huntr.dev/bounties/747e8de0-2ff0-4ced-b4fb-7354bf539bfc/ and https://huntr.dev/bounties/349f1437-bdd7-4600-87f7-f06e04955b70/

One has an value 7.5 and the other one 6.5 both do more or less the same but still the impact in the worse case a "client" side setting has been removed.

If we are going to recalculate then I come to a score of about: 3.6

CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N