I recently came across an article regarding a CSRF vulnerability on Facebook discovered by M.J. Keith. Keith documents how Facebook does not enforce the CSRF protection token “post_form_id”. He states that when it is omitted entirely from some of the requests, Facebook executes the request as if it wasn’t even required in the first place. A demo video is located on the site which shows how someone can exploit this flaw to seamlessly update a user’s Facebook profile information.

Although Facebook has reported that it has fixed this flaw, I decided to look into it a bit further.

After playing around with a few requests, I noticed that there still remains a CSRF vulnerability pertaining to the request used to delete a friend. By completely omitting the “post_form_id”, as well as a few other parameters, I noticed that Facebook will still carry out the deletion of the friend whose id was specified in the request. This allows an attacker to seamlessly delete specified friends from the currently logged in Facebook user by getting the user to visit a specially crafted web page.

I than began thinking if it would be possible to delete ALL the friends of the currently logged in Facebook user at once, just by making them visit a malicious web page. Being aware of Facebook’s privacy settings, I remembered that most users’ friend lists are public. Having done a little bit of Facebook application development in the past, I began looking into some of the old REST API calls to see if there was a quick and easy way to obtain the profile ids of each of the victim’s friends without authorization. I noticed that this was possible, but it required authorization from the user. Authorization is also necessary for the new API calls. I decided to do a raw HTML scrape of their friends list. After parsing out the id from each friend on the target’s friend list, I can then execute the user deletion request for the id of each of the victim’s friends.

The PoC that I wrote to demonstrate this uses Ajax to constantly fetch and parse waves of friend ids from the victim’s public friend’s list. It then dynamically creates an iframe in the DOM for each friend id gathered and uses the iframe’s source to pass the id to a another script. This script then populates a form with the appropriate request variables, then auto-submits the vulnerable request to Facebook, using javascript.  This process seamlessly loops in the background until all of the victim’s friends are deleted.

Below is a simple demo video demonstrating the CSRF vulnerability on a single friend.

*Update (5/22/10): After reporting the flaw to Facebook Wednesday afternoon, I have confirmed as of Friday afternoon that the flaw has been successfully patched. Facebook now strictly enforces the existence of the “post_form_id” CSRF protection token in the request. Hopefully they do this for all other serious requests as well. I have updated the above post with more details pertaining to the flaw, as well as my method of exploiting it.

It is quite evident that clickjacking is becoming more and more popular amongst popular social networking sites. I believe this to be the case strictly because of the simplicity, flexibility, and effectiveness of the CSRF variant.

Clickjacking first got my attention through this article I came across at Guya.net which exemplifies how a users webcam can become comprised by utilizing clickjacking to manipulate how your webcam can be accessed by flash on Adobe’s website.

Quite honestly, anybody with a basic knowledge of HTML, and a tiny bit of creativity, can embed an iframe into a malicious site and point their sources to any other website with a clickable element. But the beauty of clickjacking is that you can bypass any form of authenticity or session token passed from the victims browser session to the target server without any means of obtaining that token individually. Your basic CSRF vulnerability on a server that allows something such as: “http://bank.com/withdraw?total=1000&from=victim&to=attacker” can be patched by adding in any form of session or authenticity token and passing that along with the other variables. But since clickjacking is just embedding the website directly into a malicious website and convincing the user to click something on that site, any need to obtain that token individually, which is not a simple task due to the same origin policy, is bypassed.

Facebook has most recently been hit with two clickjacking worms that interestingly enough, propagated at immense speeds. Facebook’s first attack, noted for its tagline “Click Da’ Button, Baby!”, was really the first time clickjacking has been used in the wild. When the victim actually clicks the button, he/she is actually clicking the ‘Share’ button on Facebook which has been embedded in a multiple iframes, given an opacity of 0, and overlapped on the big red button. Clicking the share button in turn shares the malicious URL to all of your other friends in an attempt to infect their sessions as well. In another recent clickjacking attack against Facebook, you can actually see part of the “Share” button on the page.

Twitter also fell victim to such an attack that consisted of a user’s standard twitter homepage being embedded in an iframe. Twitter quickly responded by adding a few lines of frame-busting javascript below the body tag to prevent it from being embedded in an iframe. Below is an excerpt of that javascript:

if (window.top !== window.self)
{
document.write = "";
window.top.location = window.self.location;
setTimeout(function(){document.body.innerHTML='';},1);
window.self.onload=function(evt){document.body.innerHTML='';};
}

I like how they set the innerHtml of the body to nothing after 1 millisecond, so even if you attempt to stop the page load, it would just show the background. Unfortunately, this is not the case with the mobile website. The simplicity of many other popular social networking mobile websites makes many of them a perfect target of clickjacking. Because the security measures built into the robust standard site cannot be used in the mobile versions of the site because of the platform that they are being accessed on. And that is exactly what I, and others, are demonstrating. By simply embedding an iframe with a source of “http://m.twitter.com/home?status=Clickjacked” or with a source of “http://m.facebook.com/sharer.php?u=http://en.wikipedia.org/wiki/Clickjacking”, the GET variables ’status’ and ‘u’, are automatically inserted into their corresponding text boxes. And with a little CSS, I aligned both iframes in such a way that the update status button and the share button are on top of the input buttons on the main page with an opacity of 0. I put together a simple proof of concept of such an attack to demonstrate this more clearly. This demo was made for Firefox. The styles can be manipulated to work with other browsers that allow clickable iframes with an opacity of 0.

Twitter/Facebook Clickjacking Demo, with an iframe opacity of %70

The victim thinks that he/she is clicking on the button on my page, but is actually clicking on the update status button on their Twitter page or the share button on their facebook page. This demo also works with javascript disabled. As you can imagine, the possibilities with such an attack are endless. All an attacker has to do is set the victims status to the URL of the malicious website containing the embedded iframe, and watch it propagate. The attacker can also craft the webpage to redirect to another webpage after the user reposts the vulnerable website. This website can then serve malware, attempt a phishing attack, or perform any other form of malicious attack.

Implementing worm-like propagation on social websites such as Facebook or Twitter, or taking advantage of One-Click purchase buttons in Amazon, makes clickjacking a serious threat. Thankfully, browsers such as Safari and Internet Explorer 8, have implemented clickjacking protection, but it’s always best to protect yourself. For Firefox users, I suggest the ‘NoScript‘ plug-in.