Please Send me Your Facebook Anti-CSRF Token!

In the last few months we have seen a variety of spam campaigns propagating on social networking websites. Most of these attacks use some flavor of social engineering tactics. Every now and then, we see some innovative social engineering techniques used by attackers. Here is one such technique that tricks the victim into revealing their all-important Facebook Anti-CSRF token.

Cross-site Request Forgery attacks

A Cross-site Request Forgery (CSRF) is a type of attack in which attackers can re-use an already authenticated session to a website to perform unwanted actions on that website without the user’s knowledge or consent. For example, let’s say that a user is logged into his or her banking website. If this bank’s website suffers from a CSRF weakness, then another malicious website (say, bad.com) can instruct the user’s browser to navigate to the bank’s webpage to perform actions, such as transferring funds, without the user’s knowledge. For the browser and the bank’s website, it is equivalent to the user opening another tab and performing these actions themselves. Anti-CSRF tokens are one of the many ways employed by websites to prevent CSRF attacks.

Anti-CSRF tokens are usually one-time randomly generated tokens generated by the website. These tokens are submitted as hidden input parameters in Web forms. The tokens are validated at the back-end of the website to rule out any CSRF attacks underway when a form or action is posted. In order to generate a CSRF token, the attackers need to know or guess the Anti-CSRF token, which makes CSRF attacks hard to execute.

This blog details techniques used by the attacker to get access to this Anti-CSRF token. There are three stages to this attack

Stage 1 – Falling for the scam

It starts with an enticing message, like the one below, appearing in the user’s newsfeed from the user’s friend.

Stage 2 – Tricking the user to send their FaceBook Anti-CSRF token

Upon clicking this link, the user is directed to a fake YouTube Web page as shown below. In order to view the video, the user is prompted to verify their identity.
Step 1 of this verification process involves generating a verification code by clicking the Generate Code link. The next and final step is Copying and-pasting the code obtained in step 1 into the verification text box and clicking the Confirm button.

Let’s take a closer look at both of these steps. The following screenshot is the JavaScript snippet for this Web page.

The “Generate Code” link is actually a request to 0.facebook.com/ajax/dtsg.php. This request will return JavaScript code similar to the code shown in the screenshot below. Many browsers like Chrome and Firefox support “view Source URI scheme”. This means that any URL supplied with “view-source:” as the URI handler will open up the source code of that page. So clicking the “Generate Code” link will display the data (JavaScript) returned from the request to dtsg.php in a “View Source” browser window.

The user is then prompted to copy and paste this JavaScript code into the “Insert Verification Code” textbox and then click the Confirm box.

So what is so special about this JavaScript Code? The answer is the Anti-CSRF token called “fb_dtsg”. In order to prevent CSRF attacks, Facebook pages have a unique per session token called “fb_dtsg”. The request to “facebook.com/ajax/dtsg.php” returns JavaScript code containing the “fb_dtsg” token.

The attacker is tricking the victim into revealing his or her Facebook Anti-CSRF token.

In this case the attacker’s third party site receives this Anti-CSRF token when the user copy and pastes the JavaScript code and clicks Confirm. The attacker is now in a position to perform CSRF attacks.

Stage 3 – CSRF attack: Malicious links silently posted to the user’s wall

The picture below details the JavaScript code returned by the attacker upon clicking the Confirm button. This code executes a CSRF attack to post a malicious link on the user’s Facebook page using the CSRF token that was stolen in stage 2.

The thing to note here is that the “post_form_id” value is irrelevant for the success of this attack. In fact, the attacker decided to randomly generate a “post_form_id” value in the code above.

Comparison to self-XSS copy and paste attacks

This attack technique is similar in nature to the Self XSS copy and paste attacks that we saw on the Facebook platform this summer.

In the previous Self-XSS attacks, the attacker managed to trick the user into copying and pasting malicious JavaScript code into the user’s browser. The malicious JavaScript code ran in the same origin context as Facebook.com , and so it was able to extract token values such as the fb_dtsg by parsing the DOM.  These extracted token values were later used to post malicious spam messages to the user and the user’s friends.

However, in this latest attack, instead of tricking the victim to execute JavaScript code whilst accessing their Facebook account, the attacker is tricking the victim into sending his or her Anti-CSRF token to the attacker. With the Anti-CSRF token in hand, the attacker then executes a CSRF attack to propagate scam messages.


Although by and large we haven’t seen attackers propagate malicious browser exploits and drive-by-downloads using these spam campaigns, we conjecture that attackers might naturally gravitate towards this in the near future. Furthermore, attackers are using some really innovative social engineering techniques to trick their victims. We advise users to keep their security software up-to-date and not click on any links that seem suspicious.

It's worth noting that we’ve reached out to Facebook and they inform us that they've had great cooperation from browser vendors to fix these issues and will continue to work with them on these issues. They also stated that they try to prevent this behavior by automated monitoring of accounts for suspicious behavior.

Tidak ada komentar:

Posting Komentar