Posted by theharmonyguy in Facebook | 4 comments

Facebook Hacked (Updated)

This morning I discovered a cross-site scripting vulnerability on a facebook.com page. The hole allows a hacker to execute scripts within the page and harvest a user’s post_form_id. That means an attacker could access the user’s profile and feed information, edit their profile information, change their status, send messages to their friends, post on their friends’ walls, authorize applications, authorize extended permissions for applications, and otherwise wreak havoc.

I have reported this problem to Facebook and expect them to respond quickly. Obviously, I intend to withhold details of the hack until Facebook issues a patch.

I would also note that while you might find this story of great interest, I personally think it pales in comparison to ongoing problems with the Facebook Platform. While this type of vulnerability is serious, Facebook normally acts swiftly in removing such a hole due to the readily apparent threat. Yet if nearly any Facebook application contains a similar hole, that allows a hacker to execute scripts, access profile information, issue notifications, post feed stories, and otherwise wreak havoc.

In the last few months, I have uncovered such holes in seven applications, three of which currently have monthly active users numbering in the tens of millions. Of course, an attacker can often reach users who have not already authorized an application using a trick known as clickjacking. I have written at length on how these attacks work, and have even demonstrated them several times.

Such hacks are not simply problems with Facebook applications – the current structure of the Facebook Platform itself enables the attacks. I am quite pleased that Facebook is today announcing new privacy controls which address at least one of the problems I outlined. I can only hope they continue to address remaining issues, and that malicious hackers do not launch any serious exploits in the mean time.

Update (8/29): Patched. Details later.

Update 2 (8/29): Technical details now available.

Posted by theharmonyguy in Facebook | No comments

Facebook Needs to Act Now on Application Security

Readers of this blog know that many Facebook applications suffer from code vulnerabilities that hackers can exploit.  I’ve brought up numerous examples of such problems, and have described several techniques for exploiting them that put users and their data at risk.  Most recently I noted that a hacked application could issue API requests that post to a user’s feed or send notifications, enabling viral attacks.

Those familiar with the Facebook Platform know what other sorts of requests are available with extended permissions.  These include changing a user’s status, posting larger news stories automatically, creating notes, accessing a user’s news feed, and so on.  All of these present powerful means of attack if available to a hacker – but as noted, all require extended permissions that most applications never request.

But today I was intrigued by a report on Inside Facebook about a new application from SocialToo.  The application allows you to post status updates which are automatically posted on your Twitter as well.  In essence, this application requires extended permissions to be useful at all.  That means if an attacker targeted SocialToo, they would nearly be guaranteed that a user had granted the application certain extended permissions.

That also means I immediately installed the application to check for any issues.  To my surprise, the application fell at my first attempt – I found it vulnerable to an extremely basic attack.  I could easily launch a Facebook virus that takes advantage of a user’s trust in SocialToo to post status updates, harvest news feed items, and otherwise wreak havoc.

I have contacted SocialToo about this particular hole and trust they will patch it soon.  But this story highlights a much larger issue.  As users increasingly trust applications and as more applications take advantage of extended permissions, more possibilities for application hijacking open up.  Facebook cannot simply continue treating application security as a “not our problem” issue.  The constant stream of code vulnerabilities in even top Facebook applications erode the image of privacy and control Facebook is trying to convey.  I know that Facebook tends to use very secure coding practices (I’ve tried to hack their code many times), but none of that matters if application developers fail to implement even the most basic security techniques.

I do not know of a surefire solution to all of this, though I have offered several solutions to specific platform problems in the past.  But I am sure of one thing: Facebook cannot afford to let powerful application hacks keep happening.

Update on SocialToo: Kudos to SocialToo for such a quick response – I received a reply to my e-mail in about a half-hour that said the hole was patched.  I did a quick check, and my attack no longer works.  The attack came through the SocialToo page for setting a vanity URL.  Entering test\"><fb:iframe src='http://google.com/'> in the page’s input box would bring up a confirmation page that included the injected iframe.  Also, the malformed code resulted in the confirmation page’s input box also being a link, meaning if a user clicked on it to edit the URL, they could be forwarded to an attack page.

Posted by theharmonyguy in Facebook | 4 comments

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.

Posted by theharmonyguy in Facebook | 3 comments

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.

Posted by theharmonyguy in Facebook | No comments

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.