4 X Security Team

Jouko Pynnonen posted a message to the Full-Disclosure mailing list today, citing multiple “script injection” vulnerabilities within Facebook. I’m not sure if this is a surprise to anybody out there, it’s certainly not to me, as numerous web applications have major problems with Cross-site Scripting vulnerabilities, but I think this is important to note due to the widespread use of Facebook.

Facebook and other social networks that are heavily populated are increasingly drawing the eye of security researchers and hackers alike, as due to the heavy amount of traffic they receive, they provide an excellent attack deployment point. In fact, there will be a wonderful talk this year at Black Hat Las Vegas 2008 on attacking Social Networks, called “Satan is on My Friends List: Attacking Social Networks“, by Shawn Moyer and Nathan Hamiel. Combining Cross-site Scripting (XSS) with several pieces of research uncovered in the last year (see research by Billy Rios, Rob Carter, and myself on Protocol/URI Handler Abuse [slides/whitepaper], research on attacks against the same origin policy [see here and here], and the new hotness “Ghost in my Browser” based research kicked of by Manuel Caballero, sirdarckcat, Aviv Raff, etc.), a deployment vector like a persistent XSS on Facebook is extremely attractive to attackers.

Read on…

The following message was posted by Pynnonen to the Full-Disclosure mailing list, describing the vulnerabilities:

Hello,

This is a summary of various Facebook security issues found and reported since June 13, 2008. Two of the vulnerabilities still remain on the site, so no details of them are disclosed here. The rest have been fixed.

Any of these could be exploited to take over the victim’s web browser temporarily to e.g. read inbox messages, forcibly install FB applications, manipulate friend lists, post messages as the victim user, etc. Any of these would also allow creation of a self-propagating JavaScript virus/worm.

Most of the issues require the victim user to click on a profile box or visit a canvas page of an application in order to trigger the injected JavaScript. Issues 2) and 3) don’t require mouse clicks.

The vulnerabilities were tested with two browsers: Firefox 3 (Linux + Windows) and Internet Explorer 7.

1) Escaping JS sandbox with literal Function constructor reference
Impact:execution of unrestricted JS on canvas pages or profiles (mouseclick required on profile pages)
Description:The JS sandbox denies references to Function.constructor but using a literal such as “function f() { }” in the code and refering to its constructor with the “bracket syntax” was possible.

The example below uses this method and calls the constructor with a
string argument, then calls the resulting Function object.

Browsers: FF, IE
Reported: June 13, 2008
Fixed: yes
Example:

(function f(){}[”constructor”](”alert(’any javascript here’);”))();

2) Fb:silverlight JS injection
Impact:execution of unrestricted JS on canvas pages, profiles
Description:Simple XSS, described in the previous message to full-disclosure.
Browsers: FF, IE
Reported: June 16, 2008
Fixed: yes
Example:

3) Injecting JS in Feeds
Impact:execution of unrestricted JS when viewing Feeds on profile page or the “home” page
Description:Insufficient input validation in the publishTemplatizedAction API method.
Browsers: FF, IE
Reported: June 16, 2008
Fixed: yes
Example:

# using the perl API
$facebook->feed->publish_templatized_action( title => “My Title”,
title_template => “{actor} is testing feed stories”,
body_template => “hello”,
image_1 => “http://www.mysite.com/image.gif’\”
onload=(function f(){}[’constructor’](’alert(1)’))();”,
image_1_link => “http://www.mysite.com” );

4) Escaping JS sandbox with literal Number reference
Impact:execution of unrestricted JS on canvas pages or profiles (mouseclick required on profile pages)
Description:Using the “bracket syntax” to reference the __parent__ property of a floating point number to get a Window object reference, then calling its eval() to run arbitrary code. IE doesn’t support the property.
Browsers: FF
Reported: June 18, 2008
Fixed: yes
Example:

5) Injecting JS in video attachments
Impact:execution of unrestricted JS when a inbox, wall or forum message is viewed (mouseclick required)
Description: When sharing video content with the http://www.facebook.com/sharer.phpform, some input fields can be modified e.g. with JavaScript. The example below can be typed in the address bar to inject JS in a message.
Browsers: FF, IE
Reported: June 20, 2008
Fixed: yes
Example:

javascript:f=document.forms[0];f[’attachment[params][video][src]’].value=’#” a=b>

6) Escaping JS sandbox with E4X
Impact:execution of unrestricted JS on canvas pages or profiles (mouseclick required on profile pages). Works in browsers supporting E4X (Firefox)
Description:JS parser in browsers supporting E4X understand XML, which can contain multi-line strings. Facebook’s JS sandbox technology didn’t expect XML and multi-line strings. The example below demonstrates how this could be used to fool the sandbox logic.
Browsers: FF
Reported: June 26, 2008
Fixed: yes
Example:

7) Escaping JS sandbox
Impact:execution of unrestricted JS on canvas pages or profiles (mouseclick required on profile pages)
Browsers: FF
Reported: June 21, 2008
Fixed: no

8) Escaping JS sandbox
Impact:execution of unrestricted JS on canvas pages or profiles (mouseclick required on profile pages)
Browsers: FF
Reported: June 21, 2008
Fixed: no

We’ll see more of this as social networking and other web 2.0 apps continue to grow in popularity, and as research in the space of combining XSS with other attack vectors continues (see my presentation at Black Hat Las Vegas 2008 with Heasman, Carter, and Rios).

[Source: zdnet]