Massive Facebook and MySpace Flash Vulnerability Exposes User Data | Hacker News Reader

Massive Facebook and MySpace Flash Vulnerability Exposes User Data

techcrunch.com

27 pointsed14 comments

Open articleView on HN

A good reminder to audit your crossdomain.xml files, and make sure everyone who might edit them understands the security implications of doing so. I've seen this exact issue affect a whole bunch of very large services - it's an incredibly common mistake.

n.b. the space after asterisks are to avoid italics

http://services.digg.com/crossdomain.xml

<allow-access-from domain="* "/>

http://api.search.live.net/crossdomain.xml

<allow-http-request-headers-from domain="* " headers="* "/>

<allow-access-from domain="* "/>

http://webservices.amazon.com/crossdomain.xml

<allow-access-from domain="* "/>

http://s.ytimg.com/crossdomain.xml

<allow-access-from domain="* "/>

http://profile.ak.facebook.com/crossdomain.xml

<allow-access-from domain="* "/>

<site-control permitted-cross-domain-policies="master-only"/>

http://www.vimeo.com/crossdomain.xml

<allow-access-from domain="* "/>

https://api.ebay.com/crossdomain.xml

<allow-access-from domain="* "/>

Just having <allow-access-from domain="* "/> in your crossdomain.xml doesn't mean you have a security issue.

In case of an API, it makes perfect sense to allow crossdomain flash access. After all, this is what an API is made for, allowing access for third party services.

It is only problematic if you don't have proper authentication, e.g. when a flash app can use the cookie of the user to authenticate.

If the domain is the same one that the rest of your site runs on, it almost certainly does mean you have a security issue. The only practical way to protect against CSRF attacks is to use a secret token in a hidden form field to authenticate all form submissions. allow-access-from-domain="*" means that an attacker can steal your CSRF tokens using a hidden Flash applet running on their malicious page, then use that token to construct a CSRF attack form submission. That means they can perform any action on your site as if they were the targeted user. That's bad.

If you want to provide access to an API, put the API on a separate subdomain. That's why api.flickr.com has an open crossdomain.xml file and flickr.com doesn't.

Adobe actually have a pretty good explanation of the security issues caused by an open crossdomain.xml file:

http://www.adobe.com/devnet/flashplayer/articles/cross_domai...

If you want to provide access to an API, put the API on a separate subdomain. That's why api.flickr.com has an open crossdomain.xml file and flickr.com doesn't.

That's what I was referring to. OP listed domains which are probably used exclusively to provide an API, e.g. api.ebay.com, implying that the crossdomain files on these domains pose a security risk.

I was wondering if my comment is understandable, obviously it's not :) Thanks for the clarification!

And you are right, a * is not a exploit but the starting point of looking for one. You still need to get content on the domain somewhere and ppl to read it, I was taking that as a given from the description of the problem which states that explicitly.

tbh I just did a google for crossdomain ext:xml and pulled out the famous domains with * in the policy.

The researcher is called Yvo Schaap (not Schapp!), a dutch guy, here is the original article:

http://www.yvoschaap.com/index.php/weblog/facebook_myspace_a...

http://kb2.adobe.com/cps/142/tn_14213.html gives background info on what the crossdomain.xml file is for, for those like me who hadn't come across it before.

Wouldn't you use htaccess rules (or similar) to prevent the .xml file from being accessed except from domains who were to be allowed flash crossdomain access, belt and braces as it were?? Certainly you'd put it as a deny in robots.txt, no?

" . . . steal all of your account data, including your photos, personal messages, and basically everything else you’ve ever put on the social networks, without you ever realizing it."

Its Facebook! Everything you put on a site like that is public, or can be and will be at some point. Its a public forum, as this one is, and any promises to the contrary have been clearly proven false on about a weekly basis.

He originally posted on reddit : http://www.reddit.com/r/programming/comments/a11mv/facebook_...

What I find truly amazing is that I don't see it covered by the big news providers yet. Not on NYT, not on CNN, not on Reuters, not on NPR.

One of those is not like the others.

it doesn't sound like this is a Flash vulnerability per se, but rather a misconfiguration of Flash on Facebook's and MySpace's websites right?

The techcrunch article links to this brief article, that I find both chilling and enraging.

http://code.google.com/p/doctype/wiki/ArticleFlashSecurityPo...

System.security.loadPolicyFile() is an ActionScript function in a Flash application that loads any URL, of any MIME type, and attempts to read the security policy in the HTTP response. If an attacker could upload and store an image, audio, RSS feed, or other file on a server that can later be retrieved, then he or she could place the Flash security policy in that file. For example, the following RSS feed is accepted as an open security policy...

Even worse, the file does not even have to be XML. The GIF image below places the Flash security policy in a GIF comment and is also accepted as an open security policy...

In fact, an attacker can embed the security policy within the data of any valid image, audio or other data file. This is easier to do so with uncompressed file formats, like BMP image files, but is possible in virtually any file format. The only limitations are that each byte before the </cross-domain-policy> tag must:

    + Be non-zero,
    + Have no unclosed XML tags (no stray <, 0x3c), and
    + Be 7-bit ASCII (bytes 0x01 to 0x7F)

[YC admins: My trailing "emphasis" asterisk was remaining visible until I placed (this) further text following it.]

Reply on news.ycombinator.com