Impact problems

[Rhynorater]

I've had some issues with BugCrowd's implementation of this VRT because it seems there isn't an accomidation for impact. Consider the following scenario: A hacker discovers a CSRF on a endpoint regarding authentication. By the BugCrowd VRT, this is a P2 (see below from an actual report). In this situation, the CSRF was to remove a social account that was linked to the user's account. That same hacker discovers an XSS on that same host. The XSS has the ability to perform a lot of different functions, INCLUDING bypassing CSRF protections on the SAME endpoint mentioned above. However, this XSS is considered a P3. Furthermore, that XSS is pivotable to account takeover because an attacker could change the victims email using the XSS.

As a result of this, we've got a CSRF that can disconnect a social account (not a ton of impact) being rated a P2 while an XSS with full Account Takeover PoC is rated at a P3. The response from the analyst on this was (and I quote) "the P3 rating for reflective cross-site scripting is already set with the assumption that it can be exploited". Clearly this is not the case, or if it is the case, the assumption was made by someone who doesn't understand basic web vulnerabilities and their capabilities. [/RANT]

To be fair, I realize that creating a framework for vulnerability categorization is very difficult and you all are doing a great job of being open to suggestions and feedback about the structure. I'd like to respectfully recommend that the BugCrowd team consider the final result in the exploit chain as the vulnerability they categorize.

Thanks, Justin

[truemongo]

CSRF are set as "Varies" (depending on the action) so to me it seems weird that particular one got P2. Supposedly, a P2 would be for site-wide CSRF (all actions!).

I do agree with the point that a XSS lets you do everything you can do with a CSRF and more (with the slight caveat that with XSS you have to deal with browser XSS auditors, but thats not a huge hurdle).

I'd like to respectfully recommend that the BugCrowd team consider the final result in the exploit chain as the vulnerability they categorize.

I think this is a can of worms because then every single XSS by some users will start to be reported as "account takeover" and getting a higher priority than the exact same XSS reported by a different user.

If a XSS allows "account takeover" it is because it does not require a password confirmation to change sensitive information such as the email or the password - but then you can submit that as a separate vulnerability, and report the XSSes as normal.

[Rhynorater]

Hey Mongo! Thanks for the reply.

I think this is a can of worms because then every single XSS by some users will start to be reported as "account takeover" and getting a higher priority than the exact same XSS reported by a different user.

I think this is exactly as it should be. If there is a misconfiguration that allows a user escalate their XSS into an account takeover, there is a seriously problem. Hackers who take the time to build a PoC and apply that to each of their XSSes deserve a higher payout. Think about it - that's how an XSS would be exploited in the real world. Blackhats aren't interested in popping alert boxes, they are interested in hijacking user's accounts and stealing PII.

Now, of course, there is the scenario where a user reports 15 Account Takeovers because of 15 different XSSes. In that scenario, 1 XSS should recieve the full ATO payment, and the other 14 should be a partial dupe (the part that allows the attacker to escalate to ATO) to the first report.

If a XSS allows "account takeover" it is because it does not require a password confirmation to change sensitive information such as the email or the password - but then you can submit that as a separate vulnerability, and report the XSSes as normal.

I disagree with this. If there is CSRF protection on that endpoint, that is not a vulnerability. There is no way to exploit that beyond physical access to the machine. This "lack of security best practice" (so to speak) only becomes a vulnerability when combined with something like an XSS. If we're gonna shift to reporting stuff like this as a standalone vulnerability (with no PoC, because there cannot be one without an XSS), then we're gonna see a very large increase in trash vulns being submitted.

(Sincerely, please excuse me if my tone sounds frustrated or confrontational. I love bug bounty and each one of y'all who are working on this problem and just want to help make a better future for bug bounty)

[Rhynorater]

CSRF are set as "Varies" (depending on the action) so to me it seems weird that particular one got P2. Supposedly, a P2 would be for site-wide CSRF (all actions!).

Hahahaha, maybe I should have kept my mouth shut. Now that one is going to be downgraded lol.

All kidding aside, if you look at the VRT, it says account takeover is a P2. As a result, an XSS that can be escalated to an account takeover should be considered a P2, IMHO.

[truemongo]

Your tone sounds fine to me!

Now, of course, there is the scenario where a user reports 15 Account Takeovers because of 15 different XSSes. In that scenario, 1 XSS should recieve the full ATO payment, and the other 14 should be a partial dupe (the part that allows the attacker to escalate to ATO) to the first report.

I could see that, but would that be enforced per program+researcher, or for the whole program? ie if I submit a XSS as "account takeover" and get the full payment, can you still do the same on the same program with a different XSS and get the full payment?

I don't disagree with your points but lets say reflected XSS with account takeover becomes P2 instead of P3. Then, a stored XSS with account takeover would probably need to become P1 instead of P2. Now all the things that affect all users and the platform itself (SQLi, RCE, XXE, etc) will be at the same priority level as a stored XSS, and they cannot go any higher... see where that's going.

Maybe one more priority level would help a bit with such things? But it will always be hard to maintain the relative priority of all bug types, specially if chains/interactions have to be considered. Btw, I submit plenty of XSS normally (without account takeover) and personally I do feel reflected XSS is fairly set to P3 regardless of other factors.. it is still a mostly targeted attack, which requires user interaction of some sort outside of the target website. For most websites this will never happen at scale and is just not of great value to the "bad guys", an exception being perhaps for sites like Facebook or Twitter. Just my opinion :)

[Rhynorater]

I could see that, but would that be enforced per program+researcher, or for the whole program? ie if I submit a XSS as "account takeover" and get the full payment, can you still do the same on the same program with a different XSS and get the full payment?

I would say no, I wouldn't get the full payment because someone already reported the escalation. That would be similar to what I described above as a "partial dupe." However, what we are discussing here is what I would call a company's "minimum responsibility." I know of several companies who pay out full for something like this and I think they are GREAT for doing so. So I continue to hack on them and they have my respect. I think more companies should strive for this.

Absolutely - I totally agree. I even cringe at how the current VRT puts Stored XSS on the same level as internal SSRF. However, I'm not lobbying for reflected XSS to be brought to a P2 - I think that would be a poor decision. What I'm lobbying for is Account Takeover being paid as a P2 as it says in the VRT, whether the researcher got there with an XSS or an OAUTH misconfiguration.

[Rhynorater]

I don't disagree with your points but lets say reflected XSS with account takeover becomes P2 instead of P3. Then, a stored XSS with account takeover would probably need to become P1 instead of P2.

I disagree, I think that would still be a P2 because account takeover (as exploit result) should be a P2. In that case, I would suggest the research not waste his/her time building a ATO PoC because it won't net them any additional money and will result in a dupe for anyone trying to use a RXSS to escalate their bug. However, I would be open to something like arbitrary account takeover (such as password reset token acquisition or something like that) being considered a P1.

EDIT: Turns out arbitrary account takeover is a P1 in the current VRT. Didn't notice that before.

[jquinard]

Hi @Rhynorater,

Thank you for taking the time to create an issue for this and thank you @truemongo for also weighing in here. This has been a complicated subject to tackle but definitely a worthwhile one. I just wanted to let you know that we are reevaluating our policy here. It may take a bit of time before we circle back but I can assure you that this is something that is being discussed.

[roberttreder]

Regarding account takeover via XSS, the main stumbling block we're running into with raising its priority is that for account takeover to occur, we're chaining XSS with another vulnerability (e.g. Missing Secure or HTTPOnly flag, lack of password confirmation on password/email change, etc.) Currently, there's no way in the Bugcrowd platform to link two vulnerabilities other than the duplicate mechanism, and all of the workaround options that we can think of have significant tradeoffs or downsides.

Support in the platform for chaining vulnerabilities is in the works, and when that has been delivered, we will be able to provide a more elegant solution for situations where the impact of one vulnerability is elevated as a consequence of another.

[TimmyBugcrowd]

I've looked into this deeply and also taken into consideration what has changed from the day this issue was created until today.

That CSRF entry is no longer the case, it's now Application-Wide. Based on that, I've no longer seen an issue with this. However, the VRT in general aims to provide a consistent and standardized framework for classifying vulnerabilities. By assigning priority levels based on the vulnerability type rather than the specific impact or exploit chain, the VRT allows for a more consistent and easily understandable rating system.

Issues regarding chained vulnerabilities are in most cases unique and therefore I suggest discussing the priority within the submission itself.

Thank you guys for your input here. If you have any other questions/concerns feel free to reach out to me via BcBuzz or create a new issue.

-Timmy