In six years, the Russian web services giant has paid out more than $1.3m in bounties for hundreds of projects

Mail.ru Group Vladimir Dubrovin, why bug bounties should be part and parcel of security process

The Mail.ru Group is relatively unknown outside Russia, but its flagship domain is the fifth most visited website within the country and the 26th worldwide, according to Similar Web.

Founded in 1998, the company began by offering an email service but has since diversified into ecommerce, social networks, instant messaging, online games, maps, and business tools.

The Daily Swig caught up with Vladimir Dubrovin, information security technical advisor at Mail.ru Group, to learn more about its HackerOne bug bounty program for its email domain, Mail.ru, and for Russia’s biggest social networking sites, VKontakte and Odnoklassniki.

Dubrovin explains why Mail.ru Group offers security researchers a rewarding outlet for their talents, and outlines some of the security improvements set in motion by its bug bounty programs.


In what ways are the Mail.ru Group’s bug bounty programs a rewarding and satisfying source of income for security researchers?

Our program is notable for its extremely wide scope. We receive reports on hundreds of Mail.ru Group’s projects – and even those of our partners if their bugs affect our users.

Not every bug bounty report is rewarded, nor are the rewards hefty for all the projects.

However, we do offer large amounts for reporting significant server-side vulnerabilities in all our projects and pay liberally for detecting any vulnerabilities in our key services.


INTERVIEW Bug bounty leader Clément Domingo on cybersecurity in Africa, hacking events, and chaining vulnerabilities for maximum impact


We try to keep in touch with researchers, because we attach great importance to responding to any report as soon as possible, dealing with vulnerabilities in a prompt manner, and paying rewards out. In most cases, we reply to researchers in a matter of hours and reward them within a week, sometimes even on the same day.

Our bug bounty rules are completely transparent – we make it clear which vulnerabilities we focus on and what we offer to bug hunters in return.


What kind of challenges have you encountered with responsible disclosure, and how have you overcome them?

Responsible disclosure issues are hardly a common thing. As a rule we disclose vulnerabilities, and often this process is initiated by us rather than HackerOne researchers.

Most of the researchers act in a responsible way, and we appreciate that. Exceptions are very rare and usually unintentional, for example when a researcher makes a video on a vulnerability publicly available by accident.

The issues we are working on are mostly technical. For example, we try to automatically inform the researcher before submission if their report may not be eligible for the program or requires additional checks and corrections to be accepted.

We even clarify some technical aspects to prevent a reputation/signal loss by the researcher (reputation and signal are a kind of SLA for researchers, and if a submitted report is not accepted, it is bad for the SLA) because researchers often don’t read all of the rules.


Mail.ru Group logo on smartphone screenMail.ru Group pays “liberally” for security bugs found in key services


Can you think of a particularly interesting security vulnerability that you fixed as a result of a submission to your program, and why it stands out?

We have received several reports on vulnerabilities that used to be treated as purely theoretical. These belonged to a completely new vulnerability class or operation vector.

One of the most interesting issues resulted in the discovery of a few zero-days in popular open source projects.


RELATED Email security: Mail.ru patches critical memory disclosure flaw


What are your recent achievements in strengthening the security of Mail.ru Group domains and their dependencies?

One of our key achievements is making our bug bounty program with HackerOne part and parcel of our security processes.

It is more than just fixing vulnerabilities that get reported – we use bug bounties as external feedback that helps us find and remove bottlenecks and radically improve security by raising its baseline.

Another achievement is process manageability. We are now able to manage and spend our budget in an efficient manner and receive reports that are really relevant.

Mail.ru Group is a large holding company with hundreds of projects in its pipeline. We can now sell the idea of a bug bounty program to the group’s different business units and promote Bug-Bounty-as-a-Service.

This is clearly demonstrated by the exponential growth of the scope and budget of our program. Six years after the launch, we have paid out $1,335,691, with about half of that amount paid over the past 12 months.


What security functions and other security improvements are in the pipeline?

In one of my presentations, I made an attempt to list all of the processes that are in any way impacted by the bug bounty program. However, I gave up after having to make the font smaller once again for it to fit into two slides.

This is quite inspiring, because the more processes the bug bounty involves, the more useful the program’s information is.

Our pipeline has plenty of other amazing projects not related to our bug bounty program or other internal processes.

As one example, we have recently implemented WebAuthN for using tokens and biometrics in web browsers. Overall, we are actively working towards solutions that will replace passwords.

We are implementing support for new email security standards (for example, the deployment of MTA-STS has almost been completed), improving [the] security of authentication processes, and [adding] phishing protection.

In other words, we do everything to make ordinary internet users more secure, sometimes even without them knowing.


How do you make sure that dependencies adhere to high security standards, or that you only work with those that do?

We audit any third-party solution before integrating it into our products and services.

All external solutions we use are also covered by our bug bounty program. When contracting new partner services, we state that the service should be ready to be bug-hunted by researchers and have an SLA for fixing security issues.

Whenever SLAs are violated or any systemic issues are revealed as part of the bug bounty program, we can either change the white label solution provider or choose to develop a solution of our own.


DON’T FORGET TO READ Microsoft bug bounty payouts trebled to reach nearly $14 million in the last year