Multiple CSRF vulnerabilities in the largest portals of the Runet

Forgive my title in the style of Securitylab, but the fact remains.

At first, I planned to write about CSRF vulnerabilities, which I found in one of the largest portals of Runet. But it turned out that not only this portal is affected by these vulnerabilities, but most of the largest resources. I reported the problems found to the relevant companies a month and a half ago. Now I have time again and I looked, what is already closed. It turned out that in a month and a half only 1 vulnerability was closed.

Because vulnerabilities are still working, I will write only where they are found and how they can be used. A week later, I promise to lay out working examples for dummies - so that schoolchildren and housewives could use it. Ready or not, here I come.
')
I am intriguing: I was looking for vulnerabilities in Yandex, Rambler, Mail.ru, Vkontakte, LiveJournal and other popular resources. If you can not wait to find out where and what vulnerabilities I have found - immediately go to the "List of vulnerabilities" section.

To understand the vulnerabilities found, you will need at least a basic knowledge of what CSRF is. If they are not there - do not worry, below I tried to explain it easily (though, in my opinion, it did not work out). If you already know what it is, or vice versa, you are not going to figure it out - safely move on to the results of my superficial audit.

For a start, it makes sense to read Wikipedia . If you are too lazy to read English (there is almost nothing on the topic in Russian on Wikipedia, the topic is very poorly covered in Habré), and you want to know something, here’s a summary of the previous episodes of this vulnerability.

UPD: The main developer of Liveinternet.ru does not believe in the existence of CSRF. I reveal his vulnerability before the promised week. Here is an example of use. Be careful if you have an account in LiRu.

UPD 2: The work of the vulnerability is demonstrated, the example so far removed.

UPD 3: A week has passed. I post the working / working examples. Time is short, so for now I’m not checking what works and what doesn’t. I would appreciate it if you write about it in the comments. All questions, suggestions, suggestions - in the responses to this comment .
Rambler , Mail.Ru , Liveinternet , Yandex

What is CSRF?

To perform any actions with a Web application, users send HTTP requests. In order to determine on behalf of which user the action is performed, sessions are usually used, which are stored in a cookie. The server receives the request, looks at the cookie, makes sure that the session associated with the data of the cookie exists and performs the action on behalf of the user associated with this session. In order for the user to remain logged in to his favorite resource, browsers automatically send cookies to the server that installed them. Thus, if you send a request from the user's browser, a cookie will be sent along with it. And the server will think that it is dealing with the logged in user of the resource and will perform actions on its behalf. And you can force the browser to send a request from a third-party page. And if the server processes such requests in the same way as requests from its pages, this is a vulnerability.

How to use?

A little confusing, of course, turned out, so a simple example. You can read only it from the whole explanation.

To delete your profile from the popular social network, Vasya needs to click on the “Delete profile” link, which leads to http://vulnerable.site/delete_profile.php?sure=yes. Petya places a picture on his page that should be downloaded to this address (of course, there is no picture at this address, but the browser does not know this in advance). When Vasya enters the Petit page, Vasya’s browser tries to download this picture. He does not find the pictures and calms down. But the popular social network received a command to delete the profile on behalf of Vasya. And Vasya's profile was safely deleted. Perhaps you still do not understand - change Vasya and Petya to Alice and Bob and read again. From these Vasya with Petya is always a mess.

So, to use, you will have to lure the user to the page you have created yourself (or to the page with XSS, on which your code is placed through XSS - but for this article there is no difference). On this page there must be something that will send a request. The easiest way is to place a picture:

<img src="http://vulnerable.site/delete_profile.php?sure=yes"/>

You can hack a popular blog and place a hidden iframe there - the result will be amazing.

And in my application, all actions are performed through POST requests

For some reason, many developers believe that it is impossible to take advantage of a CSRF vulnerability that requires sending a POST request. Usually they motivate this by saying that through JS you cannot send a POST request to another domain. This is true (at least under normal conditions). But for some reason they always forget about the root of the world evil iframe tag. Firstly, it can be hidden (display: none) and it will still be loaded. Secondly, you can download it from anywhere (from your own server as well). And, thirdly, it can have an already completed form with method = "POST" and action = "http://vulnerable.site/delete_profile.php", and onload it can be called to submit this form. To demonstrate the following vulnerabilities, I used exactly this method.

I am a user - how can I protect myself?

Here I must upset you. The only way to protect - do not use the Internet. Or at least that part of it, in which you need to log in somewhere (social networks, twitter, email, forums, etc.). No, you can of course never leave open sessions and always press the exit button immediately after using the resource - but it still will not save you, because while you are logged in - you are vulnerable. Regular users can only hope for the professionalism of the developers and the fact that they have taken care of their users. And there is little hope.

UPD: For FF there is addon - RequestPolicy , thanks Vanav

I am a developer - how do I take care of my users?

It is to take care of your users - using the CSRF server does not disable the system and does not allow SSH access. Only some actions on behalf of the user are performed. Well, the user himself could execute them. Therefore, some developers do not consider this a vulnerability. And I consider such an attitude a blatant lack of professionalism and not looking at one’s own users. Get out of the profession. Moreover, the vulnerability is far from new.

I’m probably won’t dwell on the methods of protection - I’ll just list the methods and give small comments - because if you are a developer, you yourself can already figure it out.

I must say that I took the methods from the English Wikipedia and, in my personal opinion, many of them are not any protection.

1. A one-time token for each action is the most reliable way; I personally choose it.
2. In each request, requiring the transfer of a login and password is also secure, but if you are not using HTTPS, then the password can be stolen from any request using a sniffer
3. Limiting the lifetime of a session doesn’t protect against anything, it simply reduces the time during which a vulnerability can be exploited.
4. Referer header check - not bad, but this header is not always set, the first method is still preferable
5. Making sure that clientaccesspolicy.xml and crossdomain.xml (for Silverlight and Flash respectively) do not allow requests from unverified sources - this is how you first remove the lock from the door and allow anyone to go and then hang it back to protect it
6. Check for X-Requested-With - will help for AJAX requests and even then not always

Practice

In principle, the search for CSRF is a very simple task. We simply set up an account on the resource we are interested in, turn on the Firebug / Chrome Developer Tools and do everything that a regular user does - set up a mailbox, read, write, delete letters, write to blogs, etc. In this case, do not forget to look at the sent requests. If the request does not contain incomprehensibly formed data (various one-time tokens), this is a potential vulnerability. Repeat this query from the local page and look at the result. If the action occurred - the vulnerability is detected. We write a page with a form, upload it to our server and load this page in a hidden iframe from some other page - just to demonstrate the work (or for industrial use). You can still show them to some of your friends. Only soberly assess the vulnerability and your relations with friends - it is unlikely that classmate Peter will be glad if 300 thousand dollars will be transferred from his account.

Some requests could not be traced either through Firebug or through the Chrome Developer Tools - the AJAX request is first sent, and after receiving the answer to it using JS, the next page opens. In this case, the query that interests us is visible only for a few seconds. But nobody will hide from Wireshark anyway.

UPD: Smart people in the comments suggest that in FireBug there is a “Do not clear” button and in Chrome Developer Tools - “Preserve Log upon Navigation”

When searching for vulnerabilities, we must not forget about additional services (like Yandex calendars) and mobile versions.

List of vulnerabilities

I did not set myself the task of finding all CSRF recognizability on a specific portal. Each resource was allocated no more than 2 hours. Checked only Russian portals - Google.ru, Facebook.com and the like were left aside. On some portals in the allotted time, I did not find anything, but I added it to the list in order to leave a general review about their method of protection. I do not consider some of the portals on the list to be the largest in Runet, but this is what the rating I used to use.

Liveinternet.ru

There is no protection against CSRF at all. You can do anything you want - send private messages, post to blogs, write comments, reconfigure an account, in general, everything that a resource allows. Therefore, to make a list of vulnerabilities did not. This resource was the last one I reached, and I don’t consider it one of the largest. After him, my hands had already dropped - everything became clear.

Rambler.ru

Protection against CSRF using method # 1 is a one-time token. It would seem that there can be no CSRF. But, first, this protection is not everywhere. And, secondly, the token is not checked - you can send any token (and even empty) and you still need the action to be executed. As an additional protection, in one of the forms I saw a hidden “referer” field with the address of the current page. Even a little tears.
It seems that the developers of Rambler one day were told that there is such a CSRF vulnerability and that to protect against it, you need to send a unique token with each request. But you forgot to say that it is also necessary to check.

What can be done

1. In Rambler. Friends (yes, who uses them at all?), You can create a group of friends with an arbitrary name, add or delete an arbitrary friend, change the settings for notifications about friends actions / adding to friends
2. In the account settings, you can add or remove a user from the blacklist, change the signature, change the location, change the list of your interests, enable / disable to display the list of your friends and your full name
3. In the mail, you can send an arbitrary letter on behalf of the user, enable unconditional forwarding to an arbitrary e-mail (without saving), change mail settings (especially valuable for displaying images from third-party servers), delete all letters from the folder (in fact, they will move to the trash ) and empty the trash
4. Also in the mail, you can delete the letter, mark the letter as read and send the letter to an arbitrary mailbox. True, for this you need to know the id of the letter and the name of the folder in which it is stored. 2 folders are known - "Inbox" and "Sent". Letter id - letter number in the current folder, so no one has canceled the brute force.

In general, a huge scope for spam and mail fraud. Even the potential usage scenarios did not begin to reflect - it is easier to say what cannot be done without the knowledge of the user.

This is not the whole list, because there is no protection (or rather, it is, but it does not work, which is equivalent).

Mail.ru

At the post office, the protection against CSRF using Method 2 is entering a password. Those. Initially, this is not from CSRF protection, but where a password is required, CSRF also does not work. Other services have normal protection.

So, what are the characteristics found in the most popular postal service in the CIS?

1. Sending a letter on behalf of the user with any text and subject to any mailbox. An email with a unique code can be sent to the attacker's mailbox, and then he will know the visitor's email. This email via AJAX will get to the page where the user is already located - this is useful for exploiting vulnerabilities # 2, # 7
2. Sending a copy of the letter to any address (the letter is not saved in the sent ones, the user cannot find out about it in any way). To exploit this vulnerability, it was necessary to know the id of the letter - 20 digits, of which the first 10 are timestamp, and the second 10 are the number of letters among those processed by the server at that second (this is only my personal assumption of course). According to my observations, this number does not exceed 1000. You can ask the server to send 1000 letters at once, and then it will send those that the user actually has in the mailbox, although the interface pro.mail.ru (and this vulnerability is located there) says That it is impossible to send more than 3 emails at the same time. You can use bruteforce - send emails received in 10 seconds, requesting a shipment of 1000 pieces each time. In order to send emails per day you need 2.5GB of outgoing traffic, but to steal a letter with a password you don’t need it - the password of a third-party resource is reset to the user's mailbox (it may already be known from # 1) and the time of arrival of the letter is already approximately known. Can be used with vulnerability # 3
3. Delete letters - again by id. Again brute force. We start password recovery, we steal the letter with the password and we delete it
4. Connecting and disconnecting SMS notifications - everything is simple here. Some mailbox settings can be changed without entering a password. You can turn off notifications, and you can turn them on to your phone, tied in paragraph number 7
5. Disable saving sent emails and enable Web mail-agent on mail pages - these checkboxes are on the same page in the settings and, just like the previous vulnerability, did not require a password to change state. Disable saving sent clear why. And it makes sense to turn on the Web mail agent if there is also a CSRF in it
6. Disable notification of the approaching size limit of the mailbox - the essence is the same as in the previous 2. Turn off notifications and fill up the box with large letters
7. Snap / delete a phone number - this is all a bit more interesting. All actions require the user's email (or rather, the username and domain), which can be obtained from point 1. You also need to specify a phone number, so removing the user’s own phone number will not work (at least if you don’t recognize it in advance - for example, it is displayed to authorized contacts in the mail agent - and how to log in is another matter). To bind your phone number you need to send the corresponding request. After that, the phone will come with an SMS code. At this stage, you will need software that will retrieve the code from the SMS and report it to the AJAX request. JS on the page after receiving this code will create another iframe, which will confirm the binding phone number. You can delete this phone number in the same way. There really is one feature here - if the phone number is unique, then it will be removed only after 15 days, and not immediately. You can delete it immediately only if you know the code from the SMS (it is the same as for the binding)

Yandex

Protection against CSRF is. But since Yandex is not only a search or mail, and protection is different everywhere. And somewhere something is missing. Yandex responded to my letter within 3 days and promised to check the information. And they are the only ones who have fixed at least one vulnerability.

What can (was) to do

1. It was possible to reconfigure the search - to enable saving search queries and results in the “Finds” service, to change the level of search filtering (for example, to prohibit a colleague from searching for pornography - just because of harm). This visibility is currently closed.
2. You can change the location of the user - and the search results, ads and traffic jams in Kherson instead of Peter will be shown to him. And you can change the location of all visitors to some not very popular and drive ads from Direct at prices much lower than Moscow ones.
3. You can create a ToDo-list user with an arbitrary name in the calendar and add arbitrary cases to it. To add cases, you need to know the list id, but you can first create the list at home, then at the user, and then again at home and sort through the id between two of your lists (and, given the number of created lists, you will most likely not even have to sort through) . Vulnerability in the mobile version of Yandex. Calendar
4. You can delete the phone from Yandex.Passport. You need to know his id, but knowing the approximate date of addition, you can pick it up and brute force
5. In Yandex.Market, you can add an arbitrary product to the comparison list. Or remove it from there.
6. In Yandex.Market, you can subscribe a user to a notification about a price reduction for a specific product below a certain level. Or unsubscribe user from notifications. For example, an unscrupulous online store has purchased a lot of gray iPhones and is planning a sale on their sale. Before the action itself, he arranges some PR campaign and signs all visitors to a notice that the price has fallen below 8,000 rubles. And then the iPhone is exported to Yandex.Market at a price of 7999 rubles, and all users receive spam from Yandex with an offer to buy this very iPhone
7. Global logout. You can terminate all user sessions on all computers. Can be used as a minor dirty trick. Competitors can place on their sites an iframe that will complete all Yandex sessions, users will be annoyed. In general, the only site on which there is no such problem is Vkontakte. There, with the wrong token, you will not even get out of your account. Not sure if it can be considered a vulnerability at all, but it seems Vkontakte considers

Not the most serious vulnerabilities. Most likely the reason for their appearance is that Yandex is a large number of services, each with its own team of developers and everywhere protection is organized differently. And somewhere just overlooked.

And what about Vkontakte and LiveJournal?

Of course, I could not get around these resources with my attention. But I did not find any vulnerabilities, although this does not mean that they are not there. In any case, it is worth telling how they have protection against CSRF.

In contact with

Tokens for any user action. It seems to be added automatically, so they are not forgotten. Exactly the same protection in the mobile version. One service, one development team, no such problems as, for example, Yandex. Only one thing confuses me - the token for a particular action is always the same for a particular user. Those. This is a kind of a mixture of protection methods # 1 and # 2 - tokens are not disposable, but are known only to the user. You can consider them a password to perform an action - for each action, your password. I don’t like something in such an organization, but I still don’t understand what it is.

LJ

Protection by method number 1 - disposable tokens. In the mobile version, protection is a bit simpler, but still there. Here is who you can look at as an example. It is really worth noting that the service is not very Russian. So he is out of competition.

Classmates

I really wanted to check them too. But for this you need to be able to use them. And I have a nervous tick from their design. So it did not work out. I will try to fix it sometime at night with disabled images.

Conclusion

In general, the picture is completely sad. If such monsters make such mistakes in their projects, then all other developers should check their resources again. The first place in the speed of closing vulnerabilities is occupied by Yandex with the speed of 1 vulnerability per month and a half. The remaining resources occupy an honorable second place.