Quick Refresher on Cross-Site Request Forgery

For those who do not know what it is, here is a quick overview of what a Cross-Site Request Forgery (CSRF) vulnerability is:

HTTP is a stateless protocol, and because of this web servers cannot identify if a number of requests are coming from the same visitor or not. Though with the help of Cookies it is possible to track users' behaviour, because a cookie (or session ID) is unique to the website visitor. The cookie or session ID is created when the visitor's browser sends the first request to the web server. During the continuation of the session, the visitor's browser sends the cookie with every subsequent request to the server and if the cookie is not sent, the server will not recognize the visitor.

Exploiting a CSRF Attack

To successfully craft and exploit a CSRF attack, the attacker tricks the victim into accessing a malicious website that transparently forces the victim's web browser to perform actions on a trusted website to which the victim is currently authenticated without the victim's knowledge. For example,

1. The victim clicks on a link that was sent to him by the attacker.
2. Upon accessing the malicious website in another browser tab, it sends a request to the trusted website to which the victim is logged on to, typically via an iframe or something similar.
3. The browser cannot determine if the request was triggered by the user or the malicious website, so just like any other request the browser includes the trusted website's cookies in the request.
4. The trusted website distinguish the user based on the cookies sent in the request and it processes the request as normal.
5. At this stage the attacker can emulate the user by sending requests to the trusted website using the victim's cookie and web browser.

This means that the attacker can do anything the victim can do on that website when logged. Therefore if the victim is an administrator on the trusted website, the attacker can for example add a new user or delete data on the trusted website.

CSRF Vulnerability in Login Forms

As a means of protection against the exploitation of CSRF attacks such as the one described above developers can programmatically create a unique and unpredictable keys in forms, which are referred to as Anti-CSRF Tokens. However, they often neglect to implement this protection in login forms because they don't consider "CSRF in Login Forms" as a security issue.

Technical Details of a CSRF Vulnerability in Yandex Browser

Yandex is a Russian Search Engine company which according to recent reports it is the 4th most popular search engine, even more popular than Bing. Yandex has a number of products and services, one of which is the Yandex browser. In the remainder of this article we will explain the technical details of a CSRF vulnerability in the Yandex browser, which was identified by Netsparker researchers.

CSRF Vulnerability In Yandex Browser Login Form

The CSRF vulnerability was found in the login screen of the Yandex Browser that is used by users to login to their Yandex account to synchronize their browser data (such as passwords, bookmarks, form values, history) between different devices they own, such as smartphones, tablets and PCs. The Google Chrome browser has the same feature.

Exploiting the CSRF Vulnerability in the Yandex Browser

By forcing the victim to log in with his own credentials, the attacker can access all of the victim's information that is saved in the browser such as browser history, passwords, opened tabs and bookmarks.

Below is a step-by-step explanation of the proof of concept of the CSRF vulnerability in the Yandex browser:

1. The attacker tricks the victim into accessing a website that includes the below code that triggers a browser to send a POST request to sync the data using the attacker's credentials.

<form   method="POST" action="https://browser.yandex.com.tr/sync/" role="form">

      <input name="login" value="vvvait">

      <input name="passwd" value="n3t5p4rk3r"> 

</form>

<script type="text/javascript">

document.forms[0].submit();

</script>

2. When the victim accesses the URL and the code is executed, unknowingly the victim logs in to the attacker's Yandex account and the Yandex Browser is triggered to start synchronizing the data. Once the victim's browser synchronizes all the data the attacker can login to his account and access the victim's synced data. Note that unless the victim finds out what is happening the browser will keep on syncing data to the attacker's account, therefore things such as new credentials and bookmarks will be synced to the attacker's account without the victim's knowledge.

Summary

By combining the Yandex browser synchronization feature and the exploitation of the CSRF attack in the login screen the attacker managed to steal the victim's passwords, browser history, bookmarks and auto complete info. In addition to that, the attacker effectively backdoored the victim's browser to keep his account synced with future updates from the user. Therefore the victim's browser will continue syncing data without the victim being aware of this browser feature and of what is happening.

Disclosure Timeline

• 17th December 2015: We reported the vulnerability to Yandex via the Yandex Bug Bounty program.
• 15th January 2016: Since by now we did not hear from Yandex we got directly in touch with one of their engineers via Twitter and were told that an email account was automatically created for us on the Yandex email system. In this account we found an email dated 22nd December 2015 in which a Yandex engineer got back to us telling us that he was unable to reproduce the issue.
• 8th February 2016: We sent a video PoC.
• 15th February 2016: We chased Yandex since we did not hear from them.
• 2nd March 2016: Yandex replied confirming the issue and advised us that they are working on the issue.
• 7th March 2016: We chased them again to see what is the status, since we were not being updated.
• 16th March 2016: We chased them again to see what is the status, since we were not being updated.
• 29th March 2016: We chased them again to see what is the status, since we were not being updated.
• 12th April 2016: Yandex replied telling us that they are still working on the issue.

By mid May we noticed that the vulnerability was addressed, though we were never updated by the Yandex team about the fix.