Vulnerability contest, or Break me completely!

On March 19, we announced the start of the vulnerability search month “Check Badoo for Strength” . Today, we would like to take the first results and share with you intermediate results, tell you how we prepared for a strength test, examine the most interesting vulnerabilities, and make a feyspalm.

And first, some statistics:

• in the first two weeks, participants sent us almost 500 applications with potential vulnerabilities;
• about 50 applications were duplicates;
• every tenth application contained a real vulnerability (the most dangerous were corrected within a few hours);
• More than 150 applications amounted to errors that are not related to the security of the site, and about 10% of them are related to platforms that do not participate in the competition.
• most of the vulnerabilities accounted for the most important component of the system — the profile (as soon as the contestants did not mock user accounts: they deleted and uploaded photos, manipulated comments, interests, personal data and email addresses).
• More than half of the submitted vulnerabilities are various CSRFs, mainly affecting content uploaded or written by users (deleting and uploading photos and comments, working with a blacklist, favorites, etc.).

How we prepared for the contest ...

A few months ago, we embedded global XSS protection throughout the site. Immediately make a reservation that it is not a panacea and does not cover 100% of vulnerabilities. Its goal is to help the developer prevent a random error. The essence of the method lies in the automatic screening of absolutely all variables that are output through the blitz , except for those moments when the developer specifically allows the output data to appear in unshielded form.
')
The most interesting and the only full-fledged XSS recognizability was found in the output of additional SEO content in an unauthorized profile. Some profile data (mainly the “About Me” field) for various SEO needs was added to one of the meta tags. At this point, the output of raw data was once allowed, which allowed for an attack. Since the vulnerability worked only for unauthorized users, we assigned the first (least dangerous) category to it: it was impossible to get any confidential data through it. The only sensible uses that come to mind are to use account data as an open redirect for further phishing, but in this case you need to be sure that the user is not currently on the site.

... and how not prepared.

In 2013, the OWASP project lowered the CSRF attack rating by three points, despite the general growth of its popularity and the lack of protection of many large web projects. The essence of the attack is simple: when you go to a special page with a form containing a POST or GET request, you can change the content or account settings under a user session. In this place, everything was not as good as we would like. Only part of the functionality on the site (authorization, exit, change of personal information, etc.) was protected by unique session tokens. As soon as the first ten reports about this bug arrived, it became obvious that the problem had to be solved entirely. Within a few days after the start of the competition, we posted another global protection: all web services on the authorized part of the site began to check for the presence of tokens in POST or GET requests to them. With this fix, we closed most of the CSRF applications.

Next we look at some of the most interesting vulnerabilities and give comments to the participants who found them .

Vulnerability in processing the number of credits at purchase (BSI-13)
The author: Nikolai Ermishkin (Asd)
Category: 5

Why did we assign this vulnerability a fifth, highest degree of importance? Because it turned out to be so easy to use that it did not require any special skills and tools other than the browser and any debug console for it. The form for selecting the number of credits looked like this in the HTML code:

... <option data-ga-ev="100  - 45,00." value="100"> <option data-ga-ev="550  (50 !) - 200,00." value="550" selected="selected"> <option data-ga-ev="1250  (250 !) - 450,00." value="1250"> <option data-ga-ev="2750  (750 !) - 900,00." value="2750"> ... 

It turned out that the value of the value field was used directly! Replacing it with almost any number, it was possible to make a payment in the amount of 220 rubles and get this amount of credits to your account. The vulnerability was fixed in a few hours, and the user with the nickname Asd came in first place in our internal top as the first to discover the vulnerability of the highest degree of significance.

Misconfiguration when changing profile data (BSI-12)
Posted by: whitebureau
Category: 5

On the same day, another serious breach was found by the whitebureau user. When interacting with profiles of other users (displaying additional information, performing any actions), the cuid (current user id) parameter, which indicated the ID of this user, was passed in the request parameters.

 GET http://badoo.com/ws/profile-ws.phtml?section=pimore&cuid=31337 

These interactions were carried out through the same controller that was responsible for editing the profile, the differences were only in the action action, and whitebureau tried to add this userid parameter with an arbitrary value to the user editing request.

 POST http://badoo.com/ws/profile-ws.phtml ... section=interested_in&interested_in_text=cats&cuid=31337 

It turned out that checking this parameter against the current user ID was skipped when editing a profile. So we have a second critical vulnerability.

Clickjacking on all pages of the site (BSI-9)
By: Eugene Farfel
Category: 1

We also received reports of non-critical, but interesting vulnerabilities. One of them was the possibility of so-called clickjacking (English clickjacking) on ​​all pages of the site.
This term was first used by Jeremiah Grossman (English Jeremiah Grossman) in 2008, but so far few people thought about the significance and consequences of this vulnerability. What is clickjacking? As the OWASP says, “It’s a redistress attack”, it’s not a problem. top level page.

Simply put, you can show the site inside an iframe by blocking some of its elements with transparent div tags containing click handlers. In this way, it is possible to force an unsuspecting authorized user to perform arbitrary actions.

One of the most well-known methods of protection is called "framebusting". It checks the opening of the page inside the iframe using Javascript. If the address of the current page is different from what is written in the address bar of the browser, the redirection is performed:

 var frameBusted = (top != self); if (frameBusted) top.location.href = '/index.htm'; 

As it turned out later, this method can be circumvented in most modern browsers:

 <iframe sandbox src="http://badoo.com/></iframe> 

Therefore, since 2009, all modern browsers (even IE) support the X-Frame-Options header, in which you can completely prohibit inserting a site into an iframe, or allow this functionality only for a specific list of domains.

Is your site protected from clickjacking?

CSRF and Custom Email Changes (BSI-38)
Posted by: graphite
Category: 3
(partly about this vulnerability is in BSI-21, author Ilya Kiel)

This is what we did not expect, so these are descriptions of how to change the email address for an arbitrary user. But in one day, as many as three descriptions of various vulnerabilities related to the re-send password component came, with which it was possible to change the user's mailbox, that is, to “hijack” his account.
There is a form for re-sending the password during registration, in which you can change your email if a typo crept into it. It turned out that the user can even change the already confirmed email address using the CSRF:

 <form action=http://eu1.badoo.com/not_confirmed/" method="post" id="form"> <input type="hidden" name="post" value="1" /> <input type="hidden" name="newemail" value="attacker@somemail.com" /> <input type="submit" /> </form> <script>$('#form').submit();</script> 

There were several ways to fix the vulnerability:
1. Add a verification for confirmation.
2. Add a CSRF token.
3. Add a captcha.
Since the module is critical, all three methods were applied, and users who found vulnerabilities were rewarded.

CSRF and Linking External Social Networking Account (BSI-44)
Posted by: chipik
Category: 4

Also found vulnerabilities in the interaction of the site with external resources. We have a functionality that allows you to associate a profile on a site with external Facebook, VK or Google+ accounts. Through them, users can log in to the site without memorizing a username and password. A chipik participant checked this algorithm for strength and found a way to deceive him.
With the help of the Tamper Data plug-in for Firefox, you can intercept a request to bind an external account and get an Authorization Token. If an attacker forces an authorized user to click on a link with this token using CSRF, his account will be tied to the attacker's external account and allow the latter to log in with this user. The most correct decision was to add a session-unique CSRF token to all transactions with an account link.



We remind you that applications are accepted until April 19 and you still have a chance to take part in the competition, get a reward, and also help make our platform more secure.
After the end of the competition, we will select the 3 most active participants and give them an additional £ 1,000.
We also have 50 cool T-shirts with the symbols of the contest and thank-you letters signed by the jury, which we will distribute to the most active participants.

Keep testing us for strength!

Stanislav Eremin and the team Badoo Development