Initial Details on Facebook Attack

It’s now been 24 hours since I posted an attack illustrating the four Facebook Platform privacy issues I mentioned previously, and the attack stopped working some time in the last 3 hours due to Slide patching a hole in SuperPoke, the specific application exploited.  In this post I’ll give the basics of how the attack worked without actually getting into code details.

When you accessed the attack page, you’d see a 301 error message.  This error page is entirely fake, and much of the action occurs when it’s loaded.  In fact, Facebook users who have already installed the recreational application exploited in this particular attack (an application that currently has over 2.5 million monthly active users) were compromised before ever leaving the error page.  The second page, which actually displays profile info, is basically a courtesy to let the user know what could have just happened invisibly.

Ironically, IE8 is the only browser that foiled the attack by default, thanks to its XSS filter.  (That does not mean I recommend people use IE8, though.)  Disabling third-party cookies also stopped the attack, and of course one must be logged into Facebook for it to work.  I believe the Firefox add-on No-Script also prevents the attack.

The initial fake error page invisibly loaded a Facebook page for the vulnerable application.  If a user has not authorized the application, the supposed redirect link, also fake, would unknowingly authorize it (Single-Click Authorization).  Once the application was authorized, the attack page exploited a cross-site scripting hole (Secondary Code Vulnerabilities) to execute a specially crafted script (External Script Access).  This script then gathered the information necessary to request all of a user’s profile data (One Access Level).

Remember that the attack served merely to illustrate privacy problems and certainly does not cover the full scope of what’s possible.  I have already been brainstorming and testing ways a similar attack could utilize viral channels, such as notifications and messages, to create a worm that spreads itself.

By the way, the cross-site scripting vulnerability employed was in a Facebook Verified Application.  It was first reported about a year and a half ago, then its current implications were published 11 days ago.  The possibility of users unknowingly authorizing an application was published four months ago.  The use of external scripts to harness user data was reported over three weeks ago.  And the problem of applications having full access to user data was raised about a year and a half ago.

As I mentioned, SuperPoke has now been patched their specific problem.  However, the larger privacy issues I raised will remain until Facebook takes further action.