The month of searching for vulnerabilities: how we prepared for it and how it survived

April 21, together with Hacker One, we launched a vulnerability scanner . May 20 ended the competition , which became the first step of this program. Today we want to tell how we strengthened our defense, preparing for the competition, how the researchers looked for gaps in it and what they helped us find.

Of course, we did not intend to rush open chest to the embrasure of the bug bounty. We launched the vulnerability scan program as the most serious and effective endurance test for those security features that we have implemented over the past couple of years. One of the most powerful frontiers of our defense was the introduction of SDC. But let's start with a little background.

Projects combined domain Mail.Ru, represent a huge heterogeneous structure. Now in the Mail.Ru domain there are more than 50 different projects with their own subdomains. Teams with their established approaches, tools and quality standards participate in their development. In addition, there are one-time projects that are created for a specific event. And this is not to mention the projects of partners.
')
How to make it so convenient for a user with such volumes of code (and did not have to re-enter the password on each service), and at the same time, the security did not suffer (so that an error in the site with singing cards did not lead to mailbox hijacking)? We decided: Separate @ Segment.

Separate @ Segmented

The first part of our user protection plan, privilege separation, has worked at Mail.Ru for many years; as part of our work on enhancing security, we restructured it, reduced it to a single standard, and strengthened it. The second part of the plan - access segmentation - we implemented relatively recently.

Privilege separation implies that only a well-controlled part of an application with limited functionality and minimal API has access to critical data.

Segmentation of access means that the compromise of one application does not lead to the compromise of other applications.

In the organization of user sessions, this approach is implemented using session sharing, or secure domain cookies (SDC), which will be described in more detail in a separate post. The introduction of SDC allowed us to logically differentiate access to different projects, as well as standardize and minimize code for controlling user access in different projects.

We are actively working on the transfer of all Mail.Ru Group projects to the SDC, but the process is not fast. Nevertheless, we were able to secure the most critical project. First of all, Mail.Ru Mail has been transferred to the SDC.

So, we conducted an audit of the projects, eliminated the found flaws, implemented the SDC. The time has come to arrange for our security system to check under stressful conditions, and we decided that the best way would be to launch a vulnerability scanner program.

We awarded the award for detecting vulnerabilities in the web versions and mobile applications of Mail, Cloud and Calendar, as well as in Mail.Ru for Business and the Mail.Ru Authorization Center. HackerOne.com was chosen as a partner and site. HackerOne is a non-profit organization dedicated to cyber security. Why HackerOne? First, it is one of the most authoritative hacker communities in the world. Among the co-founders are leading world experts in this field. One of the major initiatives on the site is finding vulnerabilities in popular open source software. 30% of the money contributed by commercial services (including us. By the way, we became the first Russian company at HackerOne) goes into their research. It was through the Hackerone platform that the reward for detecting the infamous Heartbleed vulnerability was paid, which recently led to the largest data breach in human history. Secondly, HackerOne has very convenient conditions and an interface for participants.

So, we started bug bounty and waited for reports.

Army scanners to the rescue

I did not have to wait long. Almost in the first seconds after the program started, reports began to fall down. It seems that researchers from all over the world (especially from Asia, especially beginners) under the motto “Here it is, my finest hour!” Rushed to storm our defenses. During the first 4 days of the program, we received 750 bug reports. It would seem that it is time to clutch at the head, but after the first hundred we understood that:

1. In Asia, there are very, very many people who can run Acunetix and other security scanners.
   Most of the first bug reports were identical, carefully copied Acunetix reports, many of which were not accompanied by a URL or a website address. Fortunately, the wave of such reports subsided fairly quickly.
   
   
   
2. Manuals for wimps. The overwhelming number of remaining reports related to projects that were outside the scope of the announced remuneration program.
   

Valuable exhibits

However, relevant reports also came. Vigilant researchers have found:

• insufficient SSL certificate validation;
• client HeartBleed (HeartBleed versus client, which is not as dangerous as the server one, but still quite critical);
• information leakage (information may be available to another application on the device or transmitted over an unprotected connection);
• remote DoS-vulnerability in one of the email applications (in the letter with certain data);
• substitution of content;
• a number of XSS and CSRF vulnerabilities;
• Vulnerability allowing to execute commands on the server (RCE).

About the last - in more detail: the error was found on a project not included in the program. However, since it turned out to be the only vulnerability with the execution of the code - and the most serious of the programs found during the month - we decided to include the participant who discovered it among the winners.

We will certainly tell you about the most interesting cases in one of the following posts.

Some statistics

During the month of the program, researchers discovered 194 bugs (non-duplicates and replicable). This number includes errors on projects that participate in the program, and bugs on other projects.



In numbers:

	On the projects included in the program	On projects not included in the program
Remote code execution	0	one
SQL injections	0	7
Xss	14	68
Access data between domains or applications	14	four
CSRF	eleven	26
Insufficient transport protection	four	2
Other low-critical	18	27

Winners

1 place ($ 5000) - niwasaki
2nd place ($ 3000) - reactors08
3rd place ($ 1500) - d1g1

We awarded the first two places to researchers who found XSS vulnerabilities in the Mail.
XSS is one of the most common security errors in web applications. According to the OWASP classification, the technical risk of this vulnerability is rated as “moderate”. However, for some services, it presents a rather serious danger: XSS potentially allows an attacker to get temporary access to the contents of the mailbox of the user who visited the malicious page or opened the malicious link in the letter (although it is impossible to take control of the box, change the password in it, or get permanent access).

We gave the third place for the vulnerability of insufficient SSL certificate validation. Such a vulnerability allows access to the transmitted data if the user exits through an insecure network - for example, in a cafe or other public place.

And we decided to establish an additional prize of $ 2000 for the most serious vulnerability outside the osprey (the same RCE) for xlimbolandx.

What's next?

Scan reports of the same type did not spoil the overall positive impression
We received valuable professional reports and were pleased with the results. Therefore, we are transforming the competition into an ongoing program (you can read about its terms on HackerOne: https://hackerone.com/mailru ).

The program has established the following rewards for different types of vulnerabilities:

For Mail.Ru Authorization Center:
RCE: $ 10,000
SQLi or equivalent, authentication bypass or equivalent information leak: $ 5000
XSS: $ 500 (except self-XSS)
SRF: $ 150-500
Open Redirection: $ 150-300

For other projects participating in the program (from scope):
RCE: $ 3000
SQLi or equivalent, authentication bypass or equivalent information leak: $ 2000
XSS: $ 300-500 (except self-XSS)
SRF: $ 150-500

So, if you want to try to find a gap in our defense and get a reward for it - welcome .