Many companies have made their first attempts at so-called bug bounties. Voluntary researchers are to be paid if they find vulnerabilities in components and report them. It is tempting to think that regular security tests can be dispensed with to a large extent and instead only have to pay out per finding. This article discusses when a bug bounty makes sense, how it should be approached, and what the challenges are.

With a bug bounty, voluntary researchers are to be motivated with remuneration to find vulnerabilities in components and report them at an early stage. This should enable specifically exposed vulnerabilities to be discovered and addressed as quickly as possible in order to reduce the time window for successful attacks to a minimum. In order to perform a bug bounty professionally and efficiently, certain aspects need to be worked out, documented and made publicly available.

Narrowing the Scope

Basically, you have to agree on the scope a bug bounty should cover. Here it is up to you which delimitations you want to establish. Many companies define all publicly accessible systems. Others focus on individual services and exclude certain components completely.

However, delimitation can also take the form of specific attack techniques. For example, many bug bounties exclude destructive attacks that seek to overload. These include classic flooding attacks, such as those used in denial of service attacks.

Defining a scope that is as broad as possible naturally allows the full advantage of a bug bounty to unfold. However, one must be aware that a bug bounty always motivates more testers. It is therefore to be expected that the components contained in the scope are exposed to more accesses, stress and attacks.

This is also one of the reasons why DoS and DDoS attacks are usually excluded. These are usually David versus Goliath attacks, where sooner or later the strongest will win. Proving this obvious concept in the context of a bug bounty adds no value and instead only disrupts regular operations.

Some manufacturers have restricted the participants allowed for a bug bounty. Apple, for example, only pays those who have been invited to its product-specific bug bounty program. So-called Invite-Only is a questionable approach, as it fails to motivate a large proportion of potential participants.

Define Rewards

The motivation for researchers to deal with a bug bounty is in most cases the bounty itself. After all, they want to be rewarded for their efforts. For this reason, it is important to define and clearly communicate what rewards are available. In the early days of the concept of bug bounties, printed coffee mugs and t-shirts were awarded. Nowadays, such possibilities can only be used as a supplement, since monetary incentives must now be offered in order to motivate researchers.

The higher the remuneration, the more willing testers are to invest their time to find high-quality vulnerabilities. A transparent pricing construct helps all sides establish clear and fair relationships. Basically, there are price ranges for individual servers, services or mechanisms. Traditionally, they define gradations for individual vulnerability classes. A missing HTTP header, which theoretically allows information disclosure, is of course classified quite differently than an SQL injection or a memory corruption. A model such as CVSS (Common Vulnerability Scoring System) can also be used here. By creating a vector for a vulnerability, the base score can be determined and the price derived based on this.

For bug bounties from vendors, it is important that the prices are as high as possible. This can prevent the vulnerabilities found from being monetized through exploitation or resale instead. This is partially comparable for bug bounties from productive environments. Again, of course, the compensation should be high enough that malicious exploitation is not worthwhile. Especially in the case of very critical problems that may allow for holistic compromise, there should be no skimping.

Paying out bug bounties can sometimes be more difficult than anticipated. Especially when the researchers are located in foreign countries and banking is not or only partially established there. So it is not uncommon that in such cases the payouts are implemented via Paypal or even Bitcoin. You should deal with which payment mechanisms you want to support early on. Clear communication in the definition of the bug bounty helps here as well.

Establish Communication Channel

The bug bounty can be advertised as such on the public website. This makes it easy and straightforward to reach by the interested parties.

In RFC 9116 a simple file format is defined to standardize and simplify the offering of bug bounties and the establishment of communication channels. Thus, a text file is to be stored on a web server under /.well-known/security.txt, which can contain the following information:

So a simple security.txt, that’s how we use it, can look like this:

Contact: mailto:info@scip.ch
Contact: https://www.scip.ch/?contact
Expires: 2023-09-30T23:59:59.000Z
Acknowledgments: https://www.scip.ch/?bugbounty
Policy: https://www.scip.ch/?bugbounty
Hiring: https://www.scip.ch/?jobs
Preferred-Languages: en, de

A simple communication channel is preferred, which is why conventional communication by email should be established first and foremost. Contact forms on websites can also be used, although these should be kept as simple as possible (no registration required, only a few fields). Encrypted communication thanks to PGP is recommended.

Deploy Processes

A certain number of submissions must be expected, especially in the initial period after the bug bounty has been activated. Some security researchers are on the lookout for newly opened bug bounties and try to find possible vulnerabilities first. These are reported accordingly via the established communication channel. The processing is then as follows:

1. Confirmation of the receipt of the submission
2. Plausibility check of the submission (if the correct components have been tested, the vulnerabilities sound plausible)
3. Request further details from the submitter, if needed (e.g. exploit, video of the attack)
4. Report and technically follow up on the vulnerabilities
5. Evaluate the vulnerability (priority, criticality)
6. Planning, initiating, implementing and testing countermeasures
7. Accept or reject the vulnerability to the submitter
8. Prepare transaction of reward (payment method, payment information)
9. Submit the reward and add the submitter to the Hall of Fame
10. Lessons Learned to be incorporated into the new process and documented

As with all processes, these should be formalized and documented. This will ensure that even with a high volume of data and tight schedules, the correct process and with it the expected quality can be guaranteed.

It is possible to outsource this processing to an external bug bounty program. Various companies worldwide, including those in Switzerland, offer such services on a commercial basis. You can benefit from their experience and established processes. Of course, there are additional costs involved. An alternative is the open project OpenBugBounty.

In general, it is a problem if many wrong, erroneous or inaccurate submissions have to be processed. It is not uncommon for certain security researchers to use automated scripts to find simple vulnerabilities and profit from them. Such low hanging fruits are often taken out of scope and their minimal risk is accepted. This often includes, for example, accepting older communication ciphers or the many HTTP security headers. Nevertheless, some security researchers ignore these specifications and generate more work due to the unnecessary submissions.

It is not uncommon for such weak submissions to degenerate into so-called beg bounties: The submitters beg for their submission to be considered and paid out. In this case, it is advisable to document the scoping very consistently and also to enforce it. Those who make a good submission should be paid fairly. And those who do not play by the rules must expect restrictions. In extreme cases, submitters can be blacklisted and excluded from the program.

In order to be able to process a high volume of submissions as efficiently as possible, appropriate templates should be prepared for each communication step. These allow to quickly and easily communicate the current status or the next steps.

Conclusion

Bug bounties sound tempting. After all, one simply has to define a few rules and can then profit from the voluntariness of any specialists. However, this is only partially correct. Most security researchers who specialize in bug bounties want to make as much revenue as possible with as little effort as possible. The use of automation and the focus on the simplest possible vulnerabilities is then the focus. Accordingly, an absolute majority of submissions are of poor quality. Experience shows that 99% of the submissions are wrong or of inferior quality. Nevertheless, they have to be processed and coordinated. Accordingly, you can only profit from a few really good submissions.

In addition, a bug bounty does not replace other security measures. Information security starts with secure development and is supported by professional security testing. Establishing bug bounties is an addition that should be considered only at the very end. Otherwise, a bug bounty program will be more expensive and time-consuming neither the use of the established mechanisms. Relying first and exclusively on bug bounties is ill-advised.

About the Author

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

• https://www.cobalt.io/blog/the-history-of-bug-bounty-programs
• https://www.openbugbounty.org
• https://www.rfc-editor.org/rfc/rfc9116
• https://www.scip.ch/.well-known/security.txt
• https://www.theverge.com/2016/8/4/12380036/apple-bug-bounty-program-vulnerability-security
• https://www.troyhunt.com/beg-bounties/