Bounty program in Badoo

Today, many IT companies have their own bounty programs (or vulnerability scan programs). Badoo - among them.

In this article I will talk about how we, without having an information security department, launched and run our bounty program. I will talk about the problems that we faced, how they were solved and how they came to what we now have. And, of course, I will mention some interesting bugs sent by the participants of this program.
')
Three years have passed since the start of our bounty program. We still continue to send messages to participants from around the world.

We want to increase interest in it, including from foreign researchers. Therefore, we, firstly, opened the page with our program on the largest portal of researchers hackerone.com , and secondly - increased the amount of rewards for the found vulnerabilities! Now the amount of remuneration, depending on the category, starts from £ 100 and can reach £ 1000 , the amount of the super premium is £ 2000 (which is more than 200,000 rubles at the current rate!) And even more if the detected vulnerability represents a real threat to our users.



Badoo is the world's largest dating service. Here you can meet your love, make new friends or just find interlocutors who are nearby.

Today, Badoo has over 300 million registered users who speak more than 50 languages ​​and live around the world. This system is supported by about 3,000 servers located in four data centers (in America, Europe, Asia and Russia). Our product is a collection of applications for all popular mobile platforms, a mobile web and a web version for a desktop browser. We are a highload project, and at the peak of traffic we have 70-80 thousand requests per second.

It is obvious that the system is quite large-scale and requires a lot of work in various areas, including in the field of information security.



Oddly enough, we do not have an information security department. And we, too, do not have specialists who deal exclusively with this area.

Nevertheless, we value our users and take care of the security of their data. Despite the fact that we are not a bank, not an online payment system, and we have no possibility of withdrawing funds (but there is a deposit of funds that are transferred to the local currency “Badoo loans”), we have quite a lot of data that needs to be protected.

Oil is added to the fire and dictated by business need not to deprive users of convenience. So, for example, we have a feature, when in a letter to a user there is a direct link to access to an account without the need to enter a login and password. Obviously, this is a huge security risk. We try to insure to the maximum, and we have mechanisms to protect user data even in this case. But, of course, no one is perfect.

Why we do not have a dedicated department is a difficult question, answering which I would like to remind you that our project has grown out of a startup. And any startup initially aims at the rapid development and achievement of business goals; he does not focus much on quality, safety and other aspects that are obvious to mature projects. That is why most startups think about their testing department not from the very beginning, but about the information security department even later. And that's fine.

Until now, in our company, some methods and approaches characteristic of a startup have been applied. We generally dealt with information security from the very beginning (our guys are professionals), but there was no systematic approach. Probably someday we will come to the need for individual specialists or the whole department dealing with information security.

And today we provide security and support the bounty program as follows:

• system administrators are involved in infrastructure, network and other security. And they began to do this before all other teams;
• developers (including during the code review) check the code from the point of view of security and possible errors;
• testers in auto tests and when checking tasks manually also check the security of features (for example, unauthorized access or code injection);
• we regularly conduct checks with automatic tools, in particular Skipfish and Acunetix;
• we are certified by PCI DSS (we have the first, highest level). Within the framework of this standard, a lot of safety measures are regularly carried out: complete isolation of the process of developing and displaying the code and equipment processing payments; regular penetration tests; regular infrastructure audits and much more. All these activities have allowed us not only to get the highest category by standard, but also to keep it for several years now;
• we tried to make the code development system itself, the framework, the template engine, the operating environment, and other things, first, to minimize the possibility of error, and second, to minimize the consequences of possible errors. The simplest example: we patch our php-fpm so that it executes PHP-code only from certain directories (closed for writing, of course). Thus, even if we assume that we have managed to upload third-party code to our servers, we minimize the possibility of its launch.

Once upon a time, third-party security specialists helped us. Someone we asked ourselves, someone wrote us about bugs of their own accord and received a reward for it. But the process itself was unorganized, so we decided to systematize it, streamline it, and put it on stream.

A couple of years ago, we seriously thought about a permanent bounty program, especially since, on the one hand, it is a kind of challenge that would allow us to reach a new level, and on the other hand, an independent test that would help us understand how our dealing with security.

Training

Of course, we did not immediately take up implementation, but began with preparation and conducted several internal checks to increase confidence that we are ready.

• Make sure that access to databases and other resources in order. Checked the rights to run, write and other actions for system users on the servers. Of course, a lot of work was done and much had to be redone in order for the system to meet the new requirements. In some places, the access API was changed so that it could be controlled.
• Enhanced XSS attack protection for our templating system. Now everything has become screened by default, and not only when the programmer explicitly writes this.
• We have conducted several stages of the internal audit of the entire system, code, environment.
• Prepared tools for processing user requests. We did not want to immediately launch a large program. To begin with, they decided to experiment and launch it for a month, so they didn’t bother with tools too. First of all, we organized a system for processing applications in Google Groups (we use Google mail in our company). From the point of view of customization, the interface of the service is quite flexible, so many things (whether the application was accepted, which category was assigned to it, whether it went into development, whether money was paid for it) was not difficult to do.
• We decided to start the program from the main website to see how it will go and how effective it will be.
• It was also decided to hold the program in the Russian-speaking segment of the network, because, first, we were already familiar with several strong researchers from Russia who were asked to participate, and secondly, we were afraid of a global failure in case of failure.

In the interface of the corporate site, we made a page where the bids were submitted, their statuses and categories. The description of vulnerabilities appeared on this page only after the vulnerability was closed. A new application could be sent to us through the same page.



This turned out to be very convenient: people received an application number from us in a letter and could monitor its condition in the same list. And they could give a link to this page to others, increasing their own karma.

As an additional motivation, we made a rating of participants, which took into account not only the number of accepted applications from a particular participant, but also their criticality. After the end of the month we awarded the leaders of the rating with special prizes.

This page also helped us point participants to duplicates. In case of duplication, the participant received a notification with the number of the application already accepted. As a result, he could track the status of such applications on this page.



When evaluating the bugs found by the participants, we did not rely on common vulnerability assessment systems, such as, for example, OWASP. On the contrary, we decided to award a category depending on the potential damage that vulnerability could inflict on us and our users. We introduced 5 of such categories, and in monetary terms they were estimated at between 50 and 500 pounds sterling.

At first glance, this may seem strange, but we were guided by the fact that often not the most critical OWASP vulnerability can cause us serious harm, therefore, it should be assessed higher. In addition, we have provided a super premium of £ 2000 and above in case of finding a particularly critical vulnerability. So we decided to further motivate our researchers not only to report on vulnerability, but also to come up with the most effective vector of exploitation for it. Further in the article, I will give an example of a simple XSS vulnerability, for which we were given a super bonus because of an unusual and very interesting attack vector.

Competition

So, the “D-day” has come. We launched the program, announcing it in several sources, and waited for the results. Let me remind you that we launched it only for a month. He was tense, but very helpful to us. The results of the Safety Month at Badoo were:

• we received about 500 applications with potential threats;
• about 50 of them turned out to be duplicates;
• about 150 applications were just bugs or suggestions for improvement, unrelated to security;
• just over 50 were real vulnerabilities;
• more than half of the vulnerabilities were various CSRFs.

The main percentage of bugs sent within a few days was CSRF. Affected were mostly pages on which users filled out information about themselves, uploaded photos, and so on. We can not say that at that time we did not have any protection against CSRF attacks. Many pages were protected by a session token. However, as it turned out, not all user actions on the site were protected from CSRF threats.

We responded quickly and within a few days after the start of the competition we launched a large project for the protection of user data - anti-CSRF. We redesigned all the pages and web services so that they began to check CSRF tokens by default. So we closed almost all the CSRF vulnerabilities on the site.

Interesting bugs

Top 3 most stupid bugs received during the first “safety month” looked like this:

• In our application there are “loans” - an artificial internal currency of the system for which the user exchanges real money and then buys some services. The error found was very stupid and existed in the system for quite a long time. If it were not for the bounty program, we would not have known about it for a long time. The bottom line was that, due to an error in the code, despite all the precautions, the number of credits that would be credited to the user after payment was taken directly from the form. Editing these values ​​in the html-code of the page allowed the attacker, by paying a small amount of money, to put more credits into the account of credits. We analyzed the transactions and paid a substantial reward to the finder (although no one, except him, took advantage of it).
• The second mistake was just as simple. It consisted in the fact that one of the handlers incorrectly validated the value of the parameter that identifies the user when his data changes. As a result, by changing the user_id in the request, it was possible to change some information of other users. As you can see, both errors are simple, however they received the highest rating.
• What was the third bug? Badoo has the ability to link external social network accounts to your account. After that, through them, you can log in to the internal account. So, in the binding mechanism there was an error that allowed you to link your account in the external social network to someone else's internal account and, accordingly, access to someone else's profile.

What's next?

During the month of the competition, we learned how to respond to requests from participants within a few hours, fixed bugs and created a separate project to protect against CSRF attacks. It became clear that this program is a good and necessary thing. She fully justified the time and resources spent on its preparation and implementation. Therefore, we decided to move on and began to prepare for a permanent program to look for vulnerabilities in the Badoo security system, slightly changing the format.

Within a month, we understood how a convenient flow should look for processing applications, and transferred it to JIRA, since the tracking of all tasks in our company is done in this system.

A simple flow in Google Groups looked like this:


Applications from the participants came to us in two ways: through the form on the corporate website and a special email-address. Next, the competition jury evaluated the applications and sent them (in the case of real threats) to the development of specific teams. The Developer Relations Manager helped us to communicate with the participants at this stage, although many letters could be generated automatically.

Flow in Jira, which we did for the permanent program, looked a little different and already included automatic answers to the participants, excluding the human factor.


We also decided to add mobile apps to the permanent program.

At about the same time, we were included in the list of bounty programs of Bugcrowd , which brought us additional popularity and attracted the attention of researchers from around the world. Strengthening the announcement, we launched the program.

Results of the ongoing program

The results were not as impressive as after the month - the flow of irrelevant reports about usyazimosti was more. Nevertheless, in the first year of the “big” program, we received reports of several interesting bugs.

• We received about 870 applications.
• About 50 of them were real security vulnerabilities.
• More than 30 applications sent in the first year turned out to be duplicates.
• More than 20 sent bugs were about mobile applications.

As expected, there was more “noise”, but there were also quite a lot of useful reports, so we are satisfied with the result of the program as a whole.

Interesting bugs

Many interesting bugs in the first year were sent to us about mobile apps, which is undoubtedly nice. This area is new and interesting for developers and researchers.

Top 3 bugs found in the first year of the program:

• A special award was awarded vulnerability with a very unusual vector and not very difficult to operate. In many places, we use a comet-server to send messages of different types over already open connections. This technology is also used to display the “pencil” in the messenger - a standard indication that something is being written to you right now at that end. And it was in this type of message that there was an unused field left over from debugging times, and arbitrary data could be entered into it. These arbitrary data "as is" were transmitted to the user to whom you are writing the message. And there it was processed as html. There is an atypical XSS, content spoofing, DDoS and many other "goodies", and the victim does not need to do anything - if only the messenger was open. Precisely because such vulnerability could be applied massively, we awarded a special award for it. The quick fix, as you understand, was simple - the unused field was simply deleted. And then rechecked all similar moments in other places.
• The second interesting mistake was in the Badoo mobile app on the Android platform. Our developers once discovered an interesting hack: to speed up the rendering, they used their own handler via the addJavascriptInterface android API on screens using web-view, which did almost nothing except instantiation. And in the case of a MitM attack (when you can’t completely trust the data arriving to the client), an attacker’s JavaScript could get into this interface. Thus, arbitrary code could be executed on client devices.
• The third bug (from the author of the previous bug) was that our own cache loader in an Android application did not sufficiently check the path to that same cache. As a result, it could be used to receive application files (after all, the downloader works with the same rights as the application), including authorization keys in external systems (for example, to log in via Facebook, VKontakte, etc.) .

In general, we believe that the bounty program has brought us a positive and rewarding experience. We receive daily expert appraisals of our applications and websites from a multitude of researchers around the world and are working to improve our products, following news from the field of information security. We appreciate the trust of our users and try to do everything to preserve the security of their data.

Participate in our program, look for bugs on websites and applications of other companies. This is a very entertaining process that can not only bring you positive emotions and interesting knowledge, but also make a significant contribution to your budget. We pay in pounds sterling, and recently also significantly increased the amount of premiums.

To send us messages about vulnerabilities or bugs is best through the Hackerone platform. Successful bug-hunting!

Ilya Ageev
Head of QA, Badoo.

PS: While the article was being written, we were told about new and interesting vulnerabilities in the program on Hackerone . We will definitely write about them in detail next time.