Facebook XSS Details

Earlier this week, I reported finding a cross-site scripting vulnerability on a facebook.com page. Last night, I asked a friend with contacts at Facebook to let their developers know directly, and the company responded quickly. I confirmed just after midnight that the hole is now patched, which means I will now share technical details.

The problem was a fairly typical XSS issue. In poking around various pages related to application permissions, I noticed that several URI parameters appeared in the source of the page, but Facebook did a good job of filtering out characters which could allow cross-site scripting. Further experimentation revealed that specifying various parameters on one page led to various error messages.

This specific page was www.facebook.com/connect/prompt_permissions.php, a pop-up that can appear when an application requests extended permissions, such as read access to a user’s stream. A typical use of this page came by issuing a GET request with several parameters: api_key (the API key of the requesting application), v=1.0, extern=1, next (the next URI to load), channel_url (the cross-domain receiver file for communicating with Facebook), dialog_id, locale (language), and ext_perm (the specific extended permission requested).

For instance, if an application with API key d41d8cd98f00b204e9800998ecf8427e wanted to access a user’s stream, it may issue a GET request to this URI:

http://www.facebook.com/connect/prompt_permissions.php?↵
api_key=d41d8cd98f00b204e9800998ecf8427e&v=1.0&extern=1↵
&next=http://uri/&channel_url=http://uri/xd.php&↵
dialog_id=0_0.37541312664788107&↵
ext_perm=read_stream&locale=en_US

Note that the extended permission parameter is simply the text read_stream. When I tried setting it to a number, say ext_perm=1, I received a page with this error message:

The application cannot ask you for permission 1

Sure enough, this error message was not filtered.  I could then easily craft an XSS link. The trick only had two requirements: the user had to be logged into Facebook, and the API key had to match an application that the user had authorized. Since finding the API key of any third-party application is fairly trivial, one could easily target widely installed applications in an actual attack.

To demonstrate the possibilities of an XSS link, I set ext_perm=%3Cscript%3Ealert(document.getElementById(↵
%22post_form_id%22).value);%3C/script%3E
and saw this output:

Illustration of XSS vulnerability on facebook.com.

Illustration of XSS vulnerability on facebook.com

Those experienced with Facebook code will recognize what can be accomplished with post_form_id. Facebook uses this code to sign AJAX requests for all sorts of operations when someone uses pages on facebook.com, hence the list of activities I gave in my last post.

Of course, to perform such activities, an attacker would need the user’s Facebook ID, which does not occur in the source code of prompt_permissions.php. But since we’re injecting code into a facebook.com page, browser security no longer prevents script access to iframes or XHR objects that reference other facebook.com pages, since none of them happen cross-domain. In fact, by setting ext_perm=%3Ciframe+src%3D%22http%3A%2F2Fwww.facebook.com↵
%2Fprofile.php%22+id%3D%22x%22+onload%3D%22alert(↵
frames%5B'x'%5D.document.getElementById('profile_pic').src)↵
%3B%22%3E%3C%2Fiframe%3E
, one would see their profile image URI, which contains their Facebook ID.

Anyone familiar with JavaScript DOM manipulation can already see how much would be possible with such an XSS vulnerability. A malicious link could provide a hacker with nearly every bit of information or capability that a user can access when logged into Facebook. An attacker could also craft a sophisticated phishing scheme, since the page would be coming from facebook.com.

Facebook did act swiftly to correct this problem, as they’ve done with previous cases, and I commend them for their response. However, I would once again note that many Facebook applications, including widely used ones, have this same type of vulnerability.  An application cannot be exploited to the same degree as a facebook.com page, but it does allow a hacker to access profile information, send notifications, and publish stories on a user’s wall.  Facebook’s recently announced privacy changes should eventually help limit profile access via hijacked applications, but many security issues still remain.

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

Social Zombies: Your Friends Want To Eat Your Brains Video from DEFCON Posted

The video from the talk Kevin Johnson and I did at DEFCON 17 called “Social Zombies: Your Friends Want To Eat Your Brains” is now up on Vimeo.  If you missed us at DEFCON Kevin and I will be presenting an updated version at OWASP AppSec DC in November.

Share and Enjoy


FacebookTwitterDeliciousDiggStumbleUponAdd to favoritesEmailRSS


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.

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

Social Media Security Podcast 1 – Zombies, Bad Facebook Apps, Twitter SPAM

skullThis is the first episode of the Social Media Security Podcast.  This episode was hosted by Scott Wright and Tom Eston.  Below are the show notes, links to articles and news mentioned in the podcast:

Please send any show feedback to feedback[aT]socialmediasecurity.com or comment below.  You can also call our voice mail box at 1-613-693-0997 if you have a question for our Q&A section on the next episode.  Thanks for listening!

**You can subscribe to the podcast now in iTunes!

ACLU Facebook Quiz Exposes Privacy Issues in Facebook

While we would normally not recommend you take any of those annoying Facebook Quizes, we found one that has some merit and value.

The ACLU has developed a Facebook Quiz about Facebook privacy.  If you didn’t know…Facebook Quizzes are simply Facebook applications.  So by taking any quiz, the quiz developer has access to any of your potentially private information including…your friends information.

Take the quiz to find out more and support the efforts of the ACLU via this petition to help change Facebook’s policy on applications and what they can access.

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.

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

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

Vote for Inherent Dangers of Real-Time Social Networking panel at #SXSW

SXSW2010_logo_squareWe were happy to see that one of the panels up for selection at the South by Southwest (SXSW) Interactive Festival next year (March 12-16, 2010) is a panel about the security of social networks called “Inherent Dangers of Real-Time Social Networking”.  The way panel selections work st SXSW is that they are up for open voting which ends on September 4th.  Basically the voting works like this (from the SXSW site):

“SXSW is a community-driven event. So, knowing what kinds of topics you want to hear at the event next March is extremely important to us. Your voting accounts for about 30% of the decision-making process for any given programming slot.

Also important is the input of the SXSW Advisory Board, which is a group of industry professionals from across the US and around the world. The final part of the panel decision-making equation is the input of the SXSW staff.”

So yes, you have a big part in the selection process!  This panel includes the following participants:

Jennifer Leggio (@mediaphyter), ZDNet
John Adams (@netik), Twitter operations and security incident response team
Damon Cortesi (@dacort), security consultant at Sevicron, founder of TweetStats, Twitter app developer
Mike Murray (@mmurray), CISO of Foreground Security

Awesome, awesome group for this panel.  Here is the description of the panel (from the SXSW PanelPicker site):

“There’s plenty of chatter about social media and security issues, from social engineering to the naïveté of users. This panel of experts will explore how cyber criminals are taking advantage of socnets flaws and lack of user awareness, and what both individuals and companies can do to help protect themselves.”

Since this is one of the biggest media conferences of the year, we highly encourage you to vote for this panel.  This will be one not to miss if selected!  What are you waiting for?  Go vote now!

1 17 18 19 20 21 28