Posted by theharmonyguy in Facebook | 1 comment

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.

Posted by theharmonyguy in Facebook | No comments

Illustrating Facebook Privacy Problems

In my last post, I outlined four privacy problems with the current Facebook Platform.  To illustrate how serious I think these problems are, I’ve put together some more details on how they could be exploited.  I doubt much will change unless Facebook users get worked up about it, so perhaps this will help get people’s attention:

https://theharmonyguy.com/facebook-privacy/

If you can’t get this to work, try logging into Facebook first.  Also, a few browser technologies may get in the way.

And if you find all this disconcerting, please spread the link above to your friends via e-mail, Facebook, Twitter (http://bit.ly/1w3dyy) and so on.

Technical details to follow.

Update: As people are noticing, users who did not previously have SuperPoke FunSpace the currently exploited application installed will likely have it installed after this. You can easily remove an application by accessing the Applications menu in the lower left corner of a Facebook page, choosing “Edit Applications,” and clicking the “x” on the row for a particular application.

Posted by theharmonyguy in Facebook, General | 4 comments

Facebook Platform Privacy Issues

For the record, Facebook has some of the most flexible and robust privacy controls I’ve seen in any online social networking service. I never want to take for granted that Facebook engineers have built remarkable privacy controls into their product, and for that they should be rightly commended.

But unfortunately, since launching the Facebook Platform, the company has unwittingly introduced several privacy problems inherent in the platform’s structure. These issues are not without solutions, yet so far Facebook’s management does not appear to view them as serious or worth the time to fix. In this article, I intend to summarize four specific problems that I believe deserve a second look.

Problem #1: One Access Level

If an application retrieves user data, a user must give it full access. A review of the top 150 Facebook applications in October 2007 found that nearly 91% had access to unnecessary private data. Given the recreational nature of many top applications today, this statistic has probably not changed drastically. Users have become accustomed to authorizing even simple applications and do not know what data will be used prior to authorizing an application. Rogue applications can thus harness a wealth of user data, and even legitimate applications can misuse data or allow potential misuse. Solutions include privacy-by-proxy for FBML applications and offering tiers of data access. With the latter, users could be prompted more specifically for authorizing data beyond basic information.

Problem #2: Single-Click Authorization

Not only do users allow applications access to a wealth of data on authorization, this action only requires one click on a button when an application page is first accessed. This opens the door to clickjacking attacks, similar to attacks launched against Twitter users earlier this year. A user could click a seemingly innocent link that authorizes a rogue application. Solutions include code for detecting possible clickjacking, such as framebusting, and requiring additional interaction, such as a prompt.

Problem #3: External Script Access

Facebook has taken admirable steps to limit code within an application that originates outside the application’s hosted domain. However, external JavaScript can not only access data within the application but can also make requests for additional user data. As an example, one major application ad program requires developers to add an HTML file to their application’s domain and include the file as an inline frame within the application. This file then calls external JavaScript that makes API calls to Facebook using the session information passed from the application to the frame. This problem is admittedly more difficult to solve, but perhaps better educating developers and advertisers on safer code techniques would be a starting point.

Problem #4: Secondary Code Vulnerabilities

Since every application has full access to user data, any code vulnerability in an application becomes a security problem for Facebook itself. For instance, a recently uncovered cross-site scripting vulnerability in an application allows a malicious hacker to access a user’s profile data if they simply access a specially crafted URI. By giving applications access to user data, Facebook and its users trust third-party developers to build applications secure enough for handling personal information. Unfortunately, many developers overlook basic security measures. Once again, this issue can be thorny, but solving it starts with educating developers. Also, offering tiers of data access for an application could limit the impact of vulnerabilities in applications that only require basic information.

Conclusion

I personally have not witnessed any major concern or forthcoming solutions to these problems from Facebook, despite security researchers noting them for some time. I have already seen these flaws used in previous attacks on Facebook, and I can foresee them being used in future attacks of significant severity.

Addressing these issues, however, begins with awareness. Users need to better understand the ramifications of platform use and need to learn better habits for using applications. Developers need to better understand proper coding practices and help protect user data. Advertisers need to avoid using personally identifiable information and clarify how they target users.

Most importantly, though, I believe that Facebook needs to adjust their platform to continue their track record of respecting user privacy. But it appears this will only happen if Facebook users realize the severity of the situation and ask for a change.

Posted by theharmonyguy in Facebook | 2 comments

SuperPoke XSS Vulnerability

This morning I randomly came across an old article on Inside Facebook that quoted yours truly on application security.  In the quote, I described injecting FBML into applications via a query string, though I also noted that I was unsure how serious such an attack could be.  One of the applications I had in mind was SuperPoke.  Since the Inside Facebook article was published in February of last year, I decided to check SuperPoke once again.

To my shock, not only had the hole not been fixed, it was worse.  SuperPoke is now loaded as an iframe instead of an FBML canvas page, and the injection method still works fine.  That means one can now use it to inject arbitrary HTML into the SuperPoke iframe.  Using this, a malicious coder could easily insert JavaScript (and set or modify cookies) into the page (XSS).

Normally this is serious, but in a Facebook application, it’s even worse.  Since the script would be embedded in an application iframe, it would be able to make FQL queries using the application’s session information, just as I previously discussed SocialReach and SocialCash doing.  In fact, such script could probably use just about anything in the JS API.  I’ve already tested building URLs for FQL queries via the REST API.

Did I mention that SuperPoke is a Facebook Verified Application?

Granted, this type of attack requires a user to make a click, but any security researcher knows that’s not difficult.  And since the JavaScript loads silently, the user would only see a normal SuperPoke page appear and not realize anything was amiss.  As always, e-mail for details.  I thought it would not be wise to release details publicly given the significance of this attack, though as usual they’re not that hard to figure out.

Update (6/19): I’ve put together some proof-of-concept code that exploits this XSS vulnerability.  Loading a particular SuperPoke URI executes a remote script which then retrieves user data via the Facebook API.  The API call to Facebook appears to come from the application page.  Details available upon request.

Posted by theharmonyguy in Facebook, General | No comments

More Problems with Facebook Platform Ads

Yesterday, I posted a few updates on problematic ads in Facebook applications, and stated that despite a ban, SocialReach was still showing ads.  Today, AllFacebook followed up on comments and got word from SocialReach claiming they were still banned, but SocialCash was imitating their ads.  SocialCash maintained they were abiding by the Facebook TOS.

And so the plot thickens.  I made my update yesterday after still seeing network traffic from socialreach.com.  After further checks today, I’m still seeing content loaded from ads.socialreach.com that is setting cookies for socialreach.com and making REST API calls to Facebook using application session information.  I’m also still seeing content from SocialHour that is similarly storing and requesting information.

Further investigation, though, revealed why this was happening.  SocialReach and SocialHour ads were not actually appearing on an application page.  The application page’s source code revealed that it was loading three hidden iframes: one for SocialCash, one for SocialReach, and one for SocialHour.  Each of these iframes loaded pages that were actually hosted on the domain of the application itself, but they then made calls to the ad network domains that allowed the ad networks to access profile information and set cookies.

The FQL queries submitted by SocialCash to the REST API are extremely similar to the three examples I posted previously from SocialReach.  SocialCash then uses not only names and pictures of friends in advertisements, but in one example, dates of birth.  The AdMazing iframe currently used for displaying ads in the application often loads SocialCash ads, so they do actually appear to users.

Furthmore, another network, LockedOn, also publishes ads with friends’ profile pictures, though I’m not entirely sure how it accesses them.  (Ads vary on refresh, so it can be hit or miss finding and examining particular ones can be difficult.)  However it finds them, once it has them, it stores the information in a cookie for ads.lockedonmedia.com.  This ad was also loaded via the AdMazing iframe that actually displays in the application.

And as I’ve mentioned before, profile information is still being sent in the URL of AdMazing ads.

All of the examples in this post came from We’re Related, a Facebook Verified Application.