Author Topic: [Worker Renewal] HackTheDEX.io -- a BitShares Bug Bounty Program (2019)  (Read 5233 times)

0 Members and 1 Guest are viewing this topic.

Offline R

  • Hero Member
  • *****
  • Posts: 1034
    • View Profile
HackTheDex appears to have been de-activated? Shame given the severity of recently resolved issues.

Offline R

  • Hero Member
  • *****
  • Posts: 1034
    • View Profile

Offline sschiessl

  • Administrator
  • Hero Member
  • *****
  • Posts: 662
    • View Profile
  • BitShares: sschiessl
HackTheDex team is still very much motivated for the renewal of the proposal! Any feedback or suggestion very much welcome.

Offline blockchainprojectsbv

  • Jr. Member
  • **
  • Posts: 24
    • View Profile
Here are our comments:

Quote
Several critical reports have been submitted and fixed through HackTheDex, proof for its value and necessity.

In terms of Owasp vulnerability ratings, HTD auditors have not yet rated any publicly disclosed vulnerabilities as critical, so this is an inaccurate claim to make.

Refined the wording. This was not meant to reference the OWASP scale and was merely subjective.

Quote
The proposal will use allocated funds to reward those that step forward with exploits, relative to the overall risk assessment of the exploit.

Do you want vulnerability disclosure reports, or are you requesting the full development of weaponized exploits?

By the owasp rating guide, two vulnerability factors (https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology#Vulnerability_Factors) incentivize the creation of automated metasploit modules.

All rewards are marked as "up to", and here is a quote from the proposal
Quote
To qualify for higher rewards, the submission should include everything
the auditing panel would need to reproduce and verify the vulnerability.
The submission should also be well-prepared and of high quality so that
it can be shared with the community as part of our transparency process.

We see your criticism in the process, and we will attempt to mitigate it. The new worker proposal will be using a new set of collaborative tools for auditors that will make the process clearer, and ultimately more transparent (the new tools would allow e.g. public fetching of the ticket status). It is our duty to make sure all auditors are fully aware of the OWASP factors/rating system and we will re-iterate on that.

Quote
How the vulnerability is scored, and the methods used to determine the score, are at the sole discretion of the panel chosen to audit the report

Since you're using the owasp vulnerability rating system, there shouldn't be undisclosed deviation from this scoring mechanism. I get not disclosing details before they're mitigated, but this comes off as a clause to avoid reporters successfully contesting low vulnerability ratings.

This is somewhat true as it is meant to give the final say to the audit panel. Several factors go into that calculation that would require full disclosure of reports, e.g.

- quality of report
- extent of attack vector provided, analysis and deduction of possible exploits
- completeness of report (hidden attack vectors that were found in review)

Disclosing that information would not be recommendable (at least we thought that) due to security concerns, and as such the calculation of reward may not be transparently comprehensible, not to the public, and in cases not even towards the reporter itself (at least not without NDA). We take it as our homework to research how other bounty programs handle such sensitive cases.

  • The turnaround time from submitting report to being in receipt of reward is multiple months. It's discouraging to wait months with an unknown payout status; if there was a faster turnaround time then researchers would be more confident in dedicating time towards HTD.
  • Reports which aren't vulnerabilities don't get responses & you can't check on progress of any submitted reports without manual telegram/email communications every couple weeks. Rejection emails would be great.

Certainly one of the biggest reasons for the change of collaborative tools, and as such I expect this to be no longer an issue (response on all submissions, status updates and finalized reports within weeks not months)

  • There has been no news update since late July 2018 nor changes to the website aside from populated reports/leaderboard/receipts. The organizer of the first HTD WP left the role & this role was filled by another community member without a blog update. What happened to Matt?

The dayjob dilemma appeared. Both Blockchain Projects and Ryan Fox are full-time working in the blockchain space.

  • One of my submissions broke the submission form, resulting in a partial report submission. Bug report for your bug report.

The submit form has been changed, it is now using local email client and highlights the submit email as well.

  • Final scores for vulnerabilities are not disclosed, only the grade category for Likelihood, Impact & Severity. This further distances the researcher from contesting low rewards. A simple final_owasp_rating:reward calculation would make researchers reward expectations more realistic months before final payout. The full disclosure of vulnerability details (inc final score) is an industry standard practiced by nvd.nist.gov , cvedetails.com and vuldb.com (etc..) which HTD aught to replicate so as to be more transparent.

Agreed, we will discuss how to refine the process in terms of disclosing the detailed OWASP scores.

  • It's the researcher's responsibility to report the vulnerability to nist/cvedetails/vuldb; HTD should take the initiative to boast about solved vulnerabilities to potentially attract veteran security researchers (and potentially devs/investors). Bitcoin has vulnerability reports on these websites.

Expect an update on that after we have discussed this internally.

  • Report 20180918A (reflected XSS vuln) has a high impact, whereas 20180728A (stored XSS vuln) and 20180801A (stored XSS vuln) have Medium impacts. Regardless of how they trigger (stored/reflected) the end result is identical (XSS attack). I believe that 20180728A and 20180801A aught to have been higher ranked & rewarded.

Once the new tools are setup we could reexamine those reports, no promises though. Please ping us then.

I love the HTD WP concept & don't hold any malice against anyone nor intend to grief/troll, I wish to simply improve the HTD process. I'll be voting to support this WP and hope that the above information helps.

And thank you for that!

Best regards,
  Blockchain Projects BV
  Stefan Schießl

Offline R

  • Hero Member
  • *****
  • Posts: 1034
    • View Profile
Can I request some changes to the wp doc?

Quote
Several critical reports have been submitted and fixed through HackTheDex, proof for its value and necessity.
In terms of Owasp vulnerability ratings, HTD auditors have not yet rated any publicly disclosed vulnerabilities as critical, so this is an inaccurate claim to make.

Quote
The proposal will use allocated funds to reward those that step forward with exploits, relative to the overall risk assessment of the exploit.

Do you want vulnerability disclosure reports, or are you requesting the full development of weaponized exploits?

By the owasp rating guide, two vulnerability factors (https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology#Vulnerability_Factors) incentivize the creation of automated metasploit modules.

Quote
How the vulnerability is scored, and the methods used to determine the score, are at the sole discretion of the panel chosen to audit the report

Since you're using the owasp vulnerability rating system, there shouldn't be undisclosed deviation from this scoring mechanism. I get not disclosing details before they're mitigated, but this comes off as a clause to avoid reporters successfully contesting low vulnerability ratings.

---

A couple issues I had with the previous HTD worker proposal:

  • The turnaround time from submitting report to being in receipt of reward is multiple months. It's discouraging to wait months with an unknown payout status; if there was a faster turnaround time then researchers would be more confident in dedicating time towards HTD.
  • Reports which aren't vulnerabilities don't get responses & you can't check on progress of any submitted reports without manual telegram/email communications every couple weeks. Rejection emails would be great.
  • There has been no news update since late July 2018 nor changes to the website aside from populated reports/leaderboard/receipts. The organizer of the first HTD WP left the role & this role was filled by another community member without a blog update. What happened to Matt?
  • One of my submissions broke the submission form, resulting in a partial report submission. Bug report for your bug report.
  • Final scores for vulnerabilities are not disclosed, only the grade category for Likelihood, Impact & Severity. This further distances the researcher from contesting low rewards. A simple final_owasp_rating:reward calculation would make researchers reward expectations more realistic months before final payout. The full disclosure of vulnerability details (inc final score) is an industry standard practiced by nvd.nist.gov , cvedetails.com and vuldb.com (etc..) which HTD aught to replicate so as to be more transparent.
  • It's the researcher's responsibility to report the vulnerability to nist/cvedetails/vuldb; HTD should take the initiative to boast about solved vulnerabilities to potentially attract veteran security researchers (and potentially devs/investors). Bitcoin has vulnerability reports on these websites.
  • Report 20180918A (reflected XSS vuln) has a high impact, whereas 20180728A (stored XSS vuln) and 20180801A (stored XSS vuln) have Medium impacts. Regardless of how they trigger (stored/reflected) the end result is identical (XSS attack). I believe that 20180728A and 20180801A aught to have been higher ranked & rewarded.

---

I love the HTD WP concept & don't hold any malice against anyone nor intend to grief/troll, I wish to simply improve the HTD process. I'll be voting to support this WP and hope that the above information helps.

Cheers.










Offline sschiessl

  • Administrator
  • Hero Member
  • *****
  • Posts: 662
    • View Profile
  • BitShares: sschiessl
I'd like to highlight that this worker also closes the gap since the last worker expired until now.

You can vote in the reference wallet using this link

https://wallet.bitshares.org/#/voting

The worker details are
Name201904-hackthedex
ID1.14.186

Offline blockchainprojectsbv

  • Jr. Member
  • **
  • Posts: 24
    • View Profile
Dear BitShares Community,

we (Blockchain Projects BV and Ryan Fox) are happy to announce (finally) the renewal for HackTheDex:

https://www.bitshares.foundation/workers/2019-04-hackthedex

Abstract

Quote
HackTheDex bounty program was started in July 2018 and is consequently renewed now. Several critical reports have been submitted and fixed through HackTheDex, proof for its value and necessity. Those reports included several possibilities for chain halt and other severe attacks. An overview can be found here:

https://hackthedex.io/#/reports

BitShares is a decentralized exchange (DEX) built on top of delegated proof-of-stake (DPoS) blockchain technology. With all financial technology in the blockchain space, a major concern for users and traders is security.

If someone found a critical bug in the DEX, they might be tempted to exploit the bug, and attempt to steal funds from unsuspecting users. Without a public bug bounty system, hackers do not have an obvious path of disclosure for reporting their findings. They also do not have any incentive to share their exploits and techniques, rather than using them for personal gain.

With this proposal, we’d like to start a BitShares bug bounty program for security researchers and penetration testers (…aka hackers!) to disclose important security vulnerabilities they find within the BitShares core protocol, reference wallet, and related code repositories.

This proposal requires little funding as most of the budget can be transferred from the old worker .

Thanks for any feedback and your support,
  Blockchain Projects BV
  Stefan Schießl