Rewarding vulnerabilities for the fourth year in a row

IT security experts who know how to find vulnerabilities and exploit them are always faced with a choice - what, in the end, with this knowledge and skills to do? And it must be admitted that a fairly large number of such specialists choose the path of responsible disclosure of information on the problems and vulnerabilities found. It is with such people that companies must be able and willing to interact. This is Bug Bounty, a vulnerability search program announced by companies in their products and services for a cash reward.

Bug bounty

We only hear in the news that we again found <name of the vulnerability> in <product name> and everything is very, very bad. Companies try to find problems in the security of their products before others find them, and for this they create internal security teams, hire external auditors, and also launch incentive programs for detecting vulnerabilities (the so-called Bug Bounty). This article is devoted to the last aspect: how the search for vulnerabilities is organized for a fee in our Mail and Portal business unit, how much money we have already paid, and what are the global trends and practices in this area.

Such programs usually run as follows:

• The company announces that it is now ready to thank researchers for the found vulnerabilities in its products and services.
• The researcher reports the vulnerability.
• The company checks it, if there is - corrects it.
• The company brings the researcher to his "hall of fame" and pays a cash reward (or gives gifts in the form of sweatshirts, T-shirts, etc.)

Often, companies use their mail or their ticket system to conduct Bug Bounty, but there are two very popular sites that automate the above process: hackerone.com and bugcrowd.com . These sites are a directory of companies that can search for vulnerabilities and report them through the same site. One of the main properties for which these sites and companies, and security researchers appreciate, is a convenient reward system. Companies can replenish their account by bank transfer (accounting is much simpler), and researchers can seamlessly withdraw money to their accounts (Paypal, Coinbase, bank transfer) without undue delay (1-2 days).
')

Bug bounty in Mail.Ru Group

The Mail.Ru Group is now running four Bug Bounty programs:

• hackerone.com/mailru
• hackerone.com/icq
• hackerone.com/vkcom
• hackerone.com/ok

Our Mail product security team (several security teams in the Mail.Ru Group) deal with the / mailru and / icq programs (also recently launched for delivery-club.ru and lootdog.io - are included in / mailru). Vulnerabilities from all subdomains come to us: * .mail.ru, * .my.com, * .icq.com and some others. By the way, we have 5 people in a team + 1 people in a testing team, and everyone has some experience in finding vulnerabilities in other company's Bug Bounty programs ( for example ).

As an example, consider the program hackerone.com/mailru . Some statistics for all the time of its work (launched April 21, 2014):

• ~ 700 monetary reward vulnerabilities.
• 446 researchers who sent confirmed vulnerabilities.
• Total paid ~ $ 250,000.
• The average payout is $ 345.
• The average response time is 13 hours.

The maximum payout (without bonuses and not in the framework of any competition is $ 5000 ( https://hackerone.com/reports/315837 ), the minimum is $ 100.

How our program works:

1. On HackerOne we get a message about the presence of any vulnerability.
2. Check: is it in skoupe? Is there enough information to reproduce the vulnerability? Isn't the message a duplicate? After all checks, we appropriately mark the report.
3. If everything is in order, one of the security team analysts checks the vulnerability.
4. If the vulnerability is confirmed, information about it is exported “as is” to our Jira (the project “HackerOne” is started in it).
5. The analyst describes the vulnerability in Russian, specifies specific details for programmers and creates a ticket in the project of the desired product (linking the ticket with paragraph 4). Ticket "falls" on the head of development and is included in the plan. The task of eliminating the vulnerability is transferred to the responsible people who developed this functionality or are now engaged in its maintenance, and they begin to heroically close the hole.
6. On the next Wednesday (since the moment the vulnerability was taken), the security team is going to decide on the payment. Most often, if the vulnerability is confirmed and is payable, the researcher receives the money within a week after the vulnerability has been posted.
7. As soon as the vulnerability is fixed, two tickets in Jira (p.4 and p.5) and the vulnerability report on HackerOne are closed.
8. From a business point of view, the main value of Bug Bounty is not to learn about the vulnerability before the “dark side” and fix it (although it is also important), but to find out where everything is bad and where the team lacks qualifications or badly lined up processes.

Myths and Facts Bug Bounty

Obtaining vulnerabilities from researchers, you can easily try them on other sites!

• In 95% of cases, vulnerabilities apply only to this code.
• In 5% of cases, the researcher himself will go and check this vulnerability in other Bug Bounty programs.

You can mark a vulnerability message as already known and sent by another researcher, and don’t pay money!

• No, HackerOne has a mechanism for adding a researcher to the original report (thereby confirming that the vulnerability was indeed found earlier).
• This is unprofitable for the company in the long term, as the community of security researchers is not very large, and we ourselves live in it and see who behaves like it. Such information spreads very quickly.

Your task is to pay less money!

• Our task is to pay a decent reward for a decent report.
• The size of our payments always depends on the maximum possible threat that the found vulnerability carries. Even if it seems to the researcher that vulnerability is trivial, but in fact it is not, we will pay for serious vulnerability. Example: the researcher found a query for which 500 error is returned. It looks like a DoS or just an exception, but under the hood the security team opens a more serious problem for which the reward will be paid.

In the "black market" vulnerabilities can be sold more expensive!

• Not always. For example, no one buys on the black market vulnerabilities like "changing the sorting order of letters after visiting example.com" or Self Cross Site Scripting (i.e., implementing JS only for your account). And we accept such messages and, most often, pay a certain amount for them, depending on the threat and complexity of exploiting vulnerability.
• As an example: we are ready to pay $ 15,000 for RCE on auth.mail.ru, and that is ~ 935 thousand rubles at the current rate, which is a large sum.

And a little more about Bug Bounty

Since HackerOne is an international platform, we get vulnerabilities from researchers from around the world, which allows us to draw some conclusions about the general trends in Bug Bounty. Now people have started looking for vulnerabilities not only in the code written by the company, but also in various popular solutions that are used by several organizations at once. And it became a real situation when they send a zero-day vulnerability in one of the products that we did not write (that is, the vulnerability does not have a patch from the manufacturer - 0day). What we are doing in this case:

1. Temporarily disable the vulnerable service or “virtual” patch. For example, we write the rule nginx. If there are source codes of the service (for example, this is a vulnerability in nginx itself), then we fix, rebuild, roll it all over the company.
2. We inform the vendor with the indication that this vulnerability was sent to us by such a researcher on HackerOne.
3. We pay the researcher a reward. Yes, we pay for the vulnerability in someone else's code, but we fixed the problem, increased the security, and understood: if this is not a one-time problem with a specific software, it may be worth isolating it (transferring it to another network, putting it in a sandbox) or refusing from him at all.

There is also a reverse situation: the researcher was looking for a vulnerability with us, found it, but it was not in our code. Then we also act on the points above. For example, they send us a vulnerability found in the software of company X, which also has its own Bug Bounty program. In theory, the researcher should receive a reward both from us and from company X. But from the point of view of X, the situation looks like the researcher inadvertently revealed the vulnerability together with the “3rd party persons”, i.e. with us. And in such cases, X may refuse to pay, but we still pay the researcher.

Bug Bounty Development

If you suddenly think about your Bug Bounty program (or have already launched it), then it is important not only to describe the rules, set prices, accept and fix vulnerabilities, pay money, but also develop the program. We do this as follows:

• The most "simple" - increase payments. For example, just recently we raised payments for all Server Side-vulnerabilities by an average of 3-5 thousand dollars (on an ongoing basis), and before that we raised last summer.
• Join the Google Play Bug Bounty program. If your application is on Google Play, you have a Bug Bounty program, and someone found a critical vulnerability in the application, then Google will pay the researcher $ 1,000. In our case, we pay extra for vulnerabilities in Android applications of Mail, Cloud, Access Code (TOTR) and Calendar.
• It is important that the researchers themselves write about your program. Therefore, not only do not be afraid of disclosing the found vulnerabilities, but also ask the researchers about it (on HackerOne this can be done limitedly, for example, if there is confidential or other information in the discussion of vulnerability that is not subject to disclosure). Also, all the disclosed vulnerability reports on HackerOne fall on Twitter and the Telegram channel , to which bug hunters from around the world have subscribed.
• Trying a system of grants. We select the most "cool" researchers (we estimate by the total amount of payments per year and the number of valid vulnerabilities), we write to them what the scope of work is now (we choose important products and features) and offer them to look, and at the end - write a short summary, which Vulnerability searched and what looked. Regardless of whether vulnerabilities are found or not, we pay $ 500. We pay for each found vulnerability separately, in accordance with the current rules. It is worth noting that it worked very effectively.
• Also, there is a system for checking new features that are not yet available to all users.

Bug Bounty Popularization

Unfortunately, not all, even large companies, have Bug Bounty programs. Many still underestimate this tool to improve the safety of their products. As the experience of companies that have announced Bug Bounty, the hacker community can greatly help in finding vulnerabilities.

We are sure that Bug Bounty should be promoted, especially in Russia. For example, the other day we took part in a large conference on information security Positive Hack Days 2018.

Bug Bounty Section



First, we put together a Bug Bounty section. The goal was simple - to get together with baghunters and talk “for life”. What they talked about:

• How us ( hackerone.com/mailru ) lives on the receiving side.
• About approaches in the exploration and collection of domains.
• Considered various vulnerabilities that were found by bughunters.
• We discussed tools for Blind XSS, SSRF and more.

By the way, the hall was almost crowded, about 150 people gathered to listen to the reports. We also participated in a couple of round tables.

Promotional codes for $ 50. The phrase “50 bucks is 50 bucks” was uttered by Cyril 'isox' Ermakov from Qiwi on one of the Mail.Ru Security mitsaps, where he told how to make a million from Bug Bounty



We pay these $ 50 (for promotional codes from the cards distributed at the conference) in addition to the standard payments for the bug (the main thing is to pass, validate and submit for payment until August 31).

By the way, about payments: in honor of the conference, during the week we paid for the server side-vulnerability in a scopa at a double rate! And, of course, after the conference there was a very emotional closed after party, where discussions on new vulnerabilities and experience in bug-bounty programs continued in a more relaxed atmosphere.

Probably, you can still tell a lot - about the options for managing Bug Bounty-programs (you can do them by the strength of the company's employees, or you can outsource, it is becoming more and more popular); about why it is important to fix vulnerabilities that are not even affecting other users now and can be used by the attacker only against themselves. So ask questions in the comments, I will be glad to answer.