Bug Bounty Transparency Update

Over the past two years Coinbase has benefited greatly from running a public bug bounty program and we believe strongly in incentivizing the white-hat community to responsibly disclose vulnerabilities to us and our partners. In light of a recent public discussion, we’d like to take this moment to transparently share more inner-workings of our program and affirm our commitment to growing our collaboration with the white-hat community in 2016.

Program Performance

In 2013, we chose to run our bug bounty program through HackerOne and review the results of our program every quarter. Since the beginning, we’ve paid out a total of $103,801 in valid bounties. 9% of our submissions were resolved by working with a researcher while the remaining 91% were closed in one of the below categories:

Bug Bounty Stats

Looking only over the last three months, we have:

  • paid out $10,300 over 19 bounties for an average of $542 per bounty
  • resolved 21 additional bugs submitted through the program
  • averaged 23 hours to respond to every new submission
  • averaged 18 days from submission to payout for valid bounties

One of the challenges with a white-hat program is effectively managing the majority of submissions that do not result in a paid bounty. One recent public example highlighted some aspects of our security program that we’d like to reflect on here:

Submission #606921: publicity pending: Balance Manipulation:

Reported on May 31st, a researcher identified a race condition in moving funds between multiple wallets within a Coinbase account. This allowed a user to send funds offsite, leaving one wallet with a negative balance. When reviewing this case internally, we confirmed that other security controls would have protected us from losing funds (you could only send funds that you did indeed own) and initially contemplated the severity of the finding. Despite employing defense-in-depth, this was a valid vulnerability in one of our layers and we rewarded the researcher with a $5,000 bounty within 24 hours of the original HackerOne submission.

Submission #949251: publicity pending: Balance Manipulation v2:

Reported on October 20th and similar to #60692 this report suggests that a similar race condition is possible while moving funds out of our vault. This purported exploit posed several challenges for our security team:

  1. Though the attack was described, neither our security or engineering teams were able to reproduce or validate this exploit. Further, we saw no indication that the researcher had actually been able to exercise the vulnerability. Lack of information is common in all white-hat programs and we regularly work with researchers to provide clear test cases and that’s what happened here.
  2. The researcher then explained that they only “half way completed the bug” but could not finish the exploit due to a lack of funds. Our Security Team attempted to provide the user additional funds to execute the purported exploit but could not because of separate restrictions on this user’s account applied by our independent Compliance Team for unrelated reasons.
  3. The reasons that our Compliance Team may place restrictions on a user’s account can be found in our User Agreement. Further, Coinbase has never, and will never ban a user for any responsible white-hat security testing of our public endpoints. In fact, we have paid over $100,000 to reward white-hat researchers and are planning to grow this program over time. Banning a researcher for security submissions would be bad for both security and business and is counter to our mission.

Despite these challenges, we recognize that our response should have better communicated our understanding of the issue in several ways:

  1. From public discussions, it may have appeared that the restrictions and security activity may have been connected. In reality, these represented separate communications with separate employees on separate teams at separate points in time.
  2. We failed to clearly communicate and close this ticket out in a timely manner. From the first submission on October 20th to the final response on December 1st, 42 days passed including several without answering following requests for comment by the researcher. This was neither professional nor courteous to the researcher and we should have more promptly dispositioned the submission.

1N.B. Publicity Pending: A good bug bounty program should be prepared for disagreements and HackerOne supports this with a mutual disclosure feature. We have requested that both of the above submissions be made fully public which will occur when the researcher agrees or after a 30 day waiting period that ends on 1/20 2016:

Bug Bounty Disclosure

Looking Ahead

Just as Bitcoin is being bootstrapped by an elegant incentive structure, well designed bug bounty programs can optimize incentives between public & private security engineers. Companies pay for the vulnerabilities or better practices that are reported (instead of abused) and responsible researchers can work without fear of retribution while they explore endpoints and even make a healthy profit. We believe that any organization that truly cares about security is clearly incentivized to run a healthy bug bounty program.

After reflecting on the performance of our bug bounty program in 2015, we’re now working on optimizing our program terms, interactions with team and the increasing the engagement with participating researchers. In 2016 we will be expanding the scope of our program and publicizing at least 30% of our valid submissions. We believe strongly in the value of our program and encourage the rest of technology to similarly engage the security community.

For additional discussion:

Please note: We’re hiring engineers (both in our San Francisco office and remote anywhere in the world). If you’re interested in speaking with us about a role we’ve set up a coding challenge that you can take in about 30–45 minutes. You can also apply through our careers site if you prefer to start the conversation that way.

Written by Rob Witoff