The Social Media Security Podcast

1. Find a cross-site scripting vulnerability in a widely used Facebook application.  At least three of the top 10 applications currently have one.
2. Craft a short link that redirects to a specially infected XSS link.  You can use a clickjacking attack to help ensure that users who don’t have the application installed still get infected.
3. Write JavaScript code for your XSS injection that harnesses a user’s session secret and uses it to make Facebook API requests.  More information about how this works is freely available online.
4. You’ll probably want to include code that harvests profile information (such as date of birth, interests, and educational history) from infected users and their friends, since that simply requires an FQL query.  You could also download photos if you so desire.  In order to appear inconspicuous, use the same FQL queries that advertising networks use for targeting.
5. If you want to include a few pop-ups or malicious redirects in your code as well, feel free.  If you can do it in JavaScript, you can do it here.
6. Finish up your code with a few API requests that post a one-line story to a user’s wall or send notifications to their friends, since both of these are also generally possible with injected code.  Include your short link in these posts.  Finally, redirect the user to an innocent page so they don’t suspect anything.
7. Note that after a little while, someone may catch on and patch the hole in the application you’re exploiting.  But since multiple applications typically have holes (see step 1), you can easily switch your code to a new one.  Since you’re using mainstream applications, they’re not likely to be banned as quickly as suspicious-looking rogue applications, so that should buy you some time.

Fully functional demonstration code available to security researchers and media outlets upon request.

Note that this is not simply a problem with Facebook applications.  This is a problem with the Facebook Platform.  These instructions will remain valid until Facebook takes action on publicly noted issues with their current setup.

As Facebook’s privacy settings continue to evolve, many have discussed the increased openness as users gain more options to share content publicly.  All the while, though, ongoing problems with the Facebook Platform detract from the perceived level of control over privacy.

In essence, you should already think of your profile information as public.  First, any application you authorize has carte blanche access to your data.  You have no way to limit this access apart from avoiding authorization to start with.  Second, if a friend authorizes an application, that application likely has the same amount of access to your profile via your friends’ sessions.  You can limit the available data if you have not also authorized the application.

Finally, the current architecture of the Platform leaves users vulnerable to attacks that allow others to harvest profile information.  I have demonstrated such attacks before, and the more I investigate them, the more ridiculous the situation becomes.

This morning I found yet another XSS hole in a top 10 Facebook application (by monthly active users).  However, this was another FBML application, and as with several other cases, I could not immediately replicate my old XSS+CSRF attack for stealing profile data.  With a bit of experimenting, though, I realized another trick.  Rather than trying to insert script directly, I took a slightly different approach for executing this script.  This new technique ensured script execution, at the price of easy access to the session secret.  Using referrers, though, I gained access to the session secret as well.  This does require a user to have referrers enabled for JavaScript, but I’m fairly certain that’s the default on most browsers.

Not only did this new trick enable the attack on that particular application, it allowed me to launch the attack using another top 10 application that I already knew had an XSS hole.  Both of these applications also allow for clickjacking installs, meaning I could once again relaunch the full attack if I so desired.

Keep in mind that you need not visit an attack page for this to affect you.  If you’ve not limited unauthorized applications or the attack uses an application you’ve already installed, your data is vulnerable if a friend visits an attack page.

In short, an attacker could launch pages right now (this is zero-day stuff, people) that silently harvest profile information and photos from nearly any Facebook user.  Between these hacks and the threat of rogue applications, you should regard anything you post on Facebook as public information.