How to Write a Facebook Virus

  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.

Facebook Instapaper Twitter Digg FriendFeed Delicious Google Bookmarks Yahoo Bookmarks Share/Bookmark

Your Facebook Profile is Already Public

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.

Facebook Instapaper Twitter Digg FriendFeed Delicious Google Bookmarks Yahoo Bookmarks Share/Bookmark

View proposed changes to the Facebook SRR/ToS

fb_governanceYou can view and comment on changes to the Facebook SRR (Statement of Rights and Responsibilities or better known as “Terms of Service”) located on the Facebook Governance Page.  You can download and review the redlined proposed changes here.  The deadline for comment is 12pm PST August 18th.  It is important for Facebook users to review these new terms as there are significant changes to the SRR and the wording that is used.  Most of the SRR will affect your privacy as a Facebook user.

For example, make sure you note the following:

1. For content that is covered by intellectual property rights, like photos and videos (“IP content”), you specifically give us the following permission, subject to your privacy and application settings: you grant us a non‐exclusive, transferable, sub‐licensable, royalty free, worldwide license to use any IP content that you post on or in connection with Facebook (“IP License”).  This IP License ends when you delete your IP content or your account (unless your content has been shared with others, and they have not deleted it).

3. When you add an application and use Platform, your content and information is shared with the application.  We require applications to respect your privacy settings, but your agreement with that application will control how the application can use the content and information you share.

4. When you publish content or information using the “everyone” setting, it means that everyone, including people off of Facebook, will have access to that information and we may not have control over what they do with it.

You should already know these things though, right?  :-) Remember: Anything you post to Facebook private or not…consider it public information.  You can leave your comments on the Facebook Governance Page or feel free to comment here.  We would love to hear your opinion of these upcoming changes.

Twitter and Facebook DDoS was Targeted at One User

The following article was just posted over at CNET News regarding the massive DD0S (Distributed Denial of Service) that targeted Twitter, Facebook, LiveJournal and more.

Via CNET News:

A pro-Georgian blogger with accounts on Twitter, Facebook, LiveJournal and Google’s Blogger and YouTube was targeted in a denial of service attack that led to the site-wide outage at Twitter and problems at the other sites on Thursday, according to a Facebook executive.

Read the entire article here.

New Research Released on Koobface

Today Trend Micro released probably the most comprehensive research yet on the Koobface social network worm.  This research details how Koobface works, the malicious payloads it carries and how this worm has spread to all the major social networks.  The most recent victim being Twitter.   Most alarming is that Koobface will still continue to evolve and is the beginning of a new generation of malware targeting social networks.

Check out the article and download the PDF for the full report.  We will also have this link posted in the “Research” section of the site.

Facebook Taking Action on at Least One Issue

Late last night, Facebook issued a statement on their development blog with the cheery title, “Good Ads Make for a Good Ecosystem.”  I’ll begin by saying this post is very good news, and I applaud Facebook for addressing ad networks that violate application policies.

Finally.

My enthusiasm is a bit tempered by how long it’s taken for Facebook to respond on this issue, and I’m still mystified by some of the remarks in their post.  But first, let’s recap the good news.  By noon Pacific on August 3rd, Facebook will require all application advertising to meet a revised version of their own guidelines.  As part of this change, ad networks will no longer be able to use profile pictures or the names and birth dates of users without Facebook’s approval.  As Justin Smith notes, “To our knowledge, this is the first time Facebook has said all ads that display user data must be ’specifically approved’ by Facebook.”  Facebook also reminded developers that they can’t send user data to third-party advertising networks, and that ads are part of an application – meaning they fall under the same rules as the application itself.  I particularly appreciated this bit:

If you run code provided by an ad network in the operation of your application, be sure you understand what this code does.

Now for the less heartening aspects of this announcement.  Yesterday, July 28th, Facebook said:

Please remember that developers have never been allowed to send user data received from Facebook to ad networks…

Stop the tape.  On May 28th I posted the following tidbit about a Facebook Verified Application:

I was surprised to see right in the HTML for the application that when it called for an advertising banner, the iframe URL included my full name, sex, date of birth, age, relationship status, and college information (schools, years, degrees, and majors). I didn’t really think an application, particularly a verified one, should be passing such profile information to a third party.

On June 10th, I named names, noting that AdMazing was the ad network getting the data.  Fast forward over a month to July 25th, when I made this comment:

I did mention one example over a month ago on this very blog, yet the methods of that particular ad network have not changed at all in the mean time, nor has Facebook taken any action against them.

Now with that background, let’s finish the sentence from Facebook’s July 28th post:

…and we take firm action against this.

Right.

I might also note that on June 7th I filed a report about a different type of unsettling ads on Facebook which used user profile data, and on June 18th AllFacebook’s Nick O’Neill left this comment:

Just as a heads up I’ve been in discussions with Facebook for the past week about this exact issue and soon enough I should have a post up about the result. This is definitely a workaround that while they may be abiding by the terms, it results in shock to many of the users that see it.

Apparently Facebook was, in fact, working to address the issue and… oh wait a second.  That blog post was from June 7th of last year.  (By the way, Nick made good on his promise with a discussion of Social Banners and related issues.)

So why the sudden flurry of activity from Facebook regarding these application ads?  Perhaps the Financial Times can shed some light on the subject:

Facebook has found itself the victim of its own success. A user revolt is underway, as a huge number of users are updating their status to warn of a rumoured invasion of privacy by the site….

Also worth noting is how suddenly this message went viral. Ms Smith first reported her experience last Sunday, and the news was picked up, and dismissed by Mashable among others. But like a buried ember that sparks a raging brush fire, the meme caught a gust of wind, and by Friday was spreading across the social graph.

As I’ve pointed out before, Facebook has shown remarkable agility when their users raise an outcry en masse.  Say what you will about Facebook protecting their users, you can’t deny that Facebook works hard to defend its image.  After that viral wave of status updates, Facebook has moved swiftly to restore user confidence in the site’s advertising, whether from Facebook or on applications.

That’s why I’m not holding my breath for any action on the other privacy problems with the Facebook Platform I’ve noted, all of which remain and which, together, leave private information at risk.  Until users realize the current reality and make an issue out of it, Facebook apparently has little incentive to change the status quo.  I would love to believe that Facebook is more proactive and that I’m simply unaware of certain measures or underestimating the situation, but so far the company’s actions have inspired little confidence.

Facebook Instapaper Twitter Digg FriendFeed Delicious Google Bookmarks Yahoo Bookmarks Share/Bookmark

Privacy Policies on the Top 25 Facebook Applications

Today, I performed a little experiment.  I went through the current top 25 Facebook applications, based on monthly active users and excluding applications by Facebook, and checked to see if they linked to a privacy policy.  I noted not only whether a privacy policy existed, but where one could find it.

Each of the applications currently have at least 5.5 million monthly active users, and 12 of them are Facebook Verified Applications.  Keep in mind that every application is entrusted with the same access to user data on authorization, regardless of the application’s purpose.

With each application, I checked for any links on the Info page, then checked to see if any of these pages linked to a privacy policy.  I then looked for application terms of service on the installation page, and checked to see if the TOS linked to a privacy policy.  (Throughout this experiment, I made a distinction between “terms of service” and a specifically designated “privacy policy.”  I also considered plaintext URIs to be links, even if they were not hyperlinked.)  Finally, I looked for help or supports links within the application that then linked to a privacy policy.

Following this method, I was unable to find any link to a privacy policy in nearly a third of the applications.  Of these, one was a Facebook Verified Application (more on that in a bit).  Also, one application only posted to a user’s wall and never requested authorization to access user data.

Two applications linked to a privacy policy only after installation, one on the first page after installation, and one via a second linked support page.  Seven applications linked to pages on their Info page that then included links to a privacy policy.  In five of these cases, the page containing a privacy link was the About link, a rather subtle one that points to the developer’s web site, which at times applies to more than one application.  Three of the seven included links to application TOS on the install page which did not include privacy policies.

Eight applications not only had a privacy link via one of the Info page links (five being the About link), but included a link to a privacy policy in the application TOS from the install page.

Only one application linked to its privacy policy directly from the Info page of the application: CourseFeed.  Major props to its developers for making that decision.  A close second in terms of disclosure was Zoosk, whose privacy policy is included in the application terms of service, which are linked to from the installation page.  Also, Zoosk’s Info page links to a support page, which then links to a privacy policy.

All of these findings are summarized in the chart below.

Chart of findings on the top 25 Facebook application privacy policies.

Chart of findings on the top 25 Facebook application privacy policies.

A few other specific applications stood out in various ways.  While Birthday Cards linked to the RockYou homepage, which includes a privacy policy link, the homepage was taken over by an advertisement in Firefox, and I saw no way to close the ad and get back to the actual page.  Also, Slide’s FunSpace presented a rather strange dynamic.  The application seemed to behave as if it were a Facebook Connect page, only prompting for authorization in a pop-up dialog when I tried to create a post.  In fact, since I had used the application previously, it included such details as my name and friend list before I even authorized it.  I’m not sure exactly what was happening behind the scenes in that instance.

Finally, one application deserves mention for its rather pitiful performance: RockYou Live, formerly Super Wall.  This is a Facebook Verified Application, yet I could not find any link to a privacy policy within the application or via its links to other pages.  In fact, the About link on the Info page points to a section of the application, which requires user installation.  Finally, it provided no link to application terms of service on the install page.

Once again, keep in mind that a user grants the same level of trust to each of these application on installation.  Yet 36% either have no published privacy policy or only offer links to a privacy policy after a user has authorized the application.  I’ve seen people get upset over the lack of a privacy policy on web sites that have access to far less personal information than a Facebook application.  If this sample of the most popular applications is any indication, however, people have another reason to be upset about the current state of privacy on the Facebook Platform.

Facebook Instapaper Twitter Digg FriendFeed Delicious Google Bookmarks Yahoo Bookmarks Share/Bookmark

Application Data Retention (Updated)

As many who follow news on privacy and technology know, Canada’s Privacy Commissioner Jennifer Stoddart recently issued a report criticizing Facebook for various problems with privacy on the site.  The report addressed several aspects of privacy on Facebook, including data access by third-party applications.

One item in the report, though, concerned data retention by Facebook.  As TechCrunch describes:

The organization and Commissioner’s main concern is that Facebook provides confusing or incomplete information about its privacy practices, like not giving users to opportunity to complete wipe out their accounts instead of merely deactivating them. Stoddart also criticizes Facebook’s policy of indefinitely keeping the personal information of people who have done just that.

Commissioner Stoddart is not the first to raise this issue, as it’s been a subject of debate for some time.  However, I have not heard many people discuss a related aspect: data retention by third-party applications.

Unfortunately, with the way the Facebook Platform is currently structured, applications receive no notification when a user removes an application’s access to their data or shuts down their Facebook account.  Consequently, an application developer has no way to determine when a user has “uninstalled” the application, and thus for most applications, data retention lasts forever.  You can see this in action by removing an application then later authorizing it again: all of your data generated within the application will likely remain.  For some applications, this data continues to be accessible to other users even if you’ve uninstalled the application.

And this is not simply a Facebook problem.  From what I understand so far, the same issue applies to OpenSocial platforms, such as MySpace.

Granted, there’s not simple solution to this problem, but as concerns grow over the amount of data shared on social networking sites, third-party data retention policies will have to enter the discussion at some point.  One can argue that each application developer is responsible for their own policies, but most applications probably have no policy, and lack of notification on uninstall makes any policy difficult to implement.

Update (8/26): Upon further research, I discovered that I was quite incorrect with this blog post; my apologies to Facebook for making an erroneous statement about the Facebook Platform.  Facebook does, in fact, allow developers to set a post-remove URL which is notified when a user removes an application.  Apparently my experience has mostly been with applications which do not take advantage of this feature, meaning the issue primarily lies with application developers, not Facebook.  I do wonder how many applications actually remove data upon uninstallation.

Facebook Instapaper Twitter Digg FriendFeed Delicious Google Bookmarks Yahoo Bookmarks Share/Bookmark

1 10 11 12 13 14