search

hakluke / bug-bounty-standards

A list of edge cases that occur in bug bounty programs, conversations on how they should be handled. The goal is to standardise the way that specific situations are handled in bug bounties.
228 stars 10 forks source link

Vulnerability reversion #7

Open hpy opened 1 year ago

hpy commented 1 year ago

A hacker submits a report for a vulnerability that was previously reported and fixed and has become vulnerable again due to a reversion. The program closes as dupe due to previous report.

Resolution: The program should pay the full reward amount.

hpy commented 1 year ago

Another issue I'm finding recently is that programs are not marking bugs as resolved when they are fixed. This makes it near impossible to prove that they are in fact vulnerable again, and that it's not just an un-patched prior reported vuln.

ItsIgnacioPortal commented 1 year ago

Another issue I'm finding recently is that programs are not marking bugs as resolved when they are fixed. This makes it near impossible to prove that they are in fact vulnerable again, and that it's not just an un-patched prior reported vuln.

A way to counter-act this is to first ask if the previous vulnerability has been fixed. That is, if you were the reporter of the first vuln. If you're an outsider, your only resource is to scavenge previously disclosed reports

A hacker submits a report for a vulnerability that was previously reported and fixed and has become vulnerable again due to a reversion. The program closes as dupe due to previous report.

What do you mean here by "reversion"? Something like a rollback?

hpy commented 1 year ago

What do you mean here by "reversion"? Something like a rollback?

Correct. Perhaps regression is a better term. I recently spent months in mediation fighting this exact scenario. A recent public example is: https://twitter.com/joaxcar/status/1665090645482954752?t=gCuyAG_EPPTzGzytu6rxBQ&s=19

ItsIgnacioPortal commented 1 year ago

In the case of a reversion, the administration must post a comment in the original report, to announce that due to a reversion, the fixes for that security issue have become undone. The comment should also explain that the fixes have been added to their future timeline, and that therefore no new reports for that issue will be awarded.

If no comment was left on the original report BEFORE the new hacker did their report, then the platform either did not know that they were vulnerable again, or they were negligent in tracking their active security issues. In both cases the bug bounty should be paid in full to the new reporter.

If they do make a comment on the original report, then the new report should be closed as a duplicate, with a message like this:

Dear [Researcher's Name],

Thank you for bringing this vulnerability to our attention. We appreciate your efforts in helping us maintain the security of our platform. However, we regret to inform you that your report has been closed as a duplicate.

The issue you reported was previously identified and addressed under the tracking ID INSERT-TRACKING-ID-HERE. Our team promptly resolved the vulnerability and implemented the necessary security fixes. Regrettably, due to a reversion, the platform has once again become vulnerable.

It is important to note that prior to receiving your report, we had already planned to re-implement the security fixes on our timeline. This intention is clearly documented in the comment section of the issue under the tracking ID INSERT-TRACKING-ID-HERE. Please refer to the screenshot below for reference:

[INSERT-SCREENSHOT-OF-COMMENT]

We sincerely apologize for any inconvenience caused by the reversion, and we assure you that we take this matter seriously. Our team is diligently working to rectify the situation and re-establish the necessary security measures.

Your contributions to our bug bounty program are greatly valued, and we encourage you to continue participating. Should you discover any new vulnerabilities or have further concerns, please do not hesitate to report them to us. Your efforts play a vital role in enhancing the overall security of our platform.

Once again, we appreciate your vigilance and assistance in securing our systems.

Best regards,

[Your Name] [Your Title/Position] [Company Name]

ItsIgnacioPortal commented 1 year ago

@hakluke do you agree with my proposed handling?

hakluke commented 1 year ago

I think that this needs to be handled with submission statuses - i.e. unless a program marks it as "resolved" then it should be treated as unresolved, even if it has technically been fixed.

There's a number of cases I can think of where a bug may have been unintentionally fixed and rolled back without the team actually properly fixing the bug.

One example:

From the hacker's perspective, the bug was fixed, then unfixed, but from the program's perspective they still haven't gotten around to fixing it.

For what it's worth I know Bugcrowd already follows this policy ^ and I think the other major platforms do too.

codingo commented 1 year ago

At least for Bugcrowd, this is already handled with submission states today, and a part of the retesting flow. Typically, a finding that has moved from unresolved to resolved, has already been retested, and any new submission is treated as a regression or a bypass not handled by the original fix.

I've queried against the past 50,000 submissions duplicated, and can't find an example of these being marked against resolved (which makes sense, as the platform speed bumps / enforces it), and don't believe this is an issue that isn't already handled. Good thought, but I think we've already solved this one.