6 ms·

Massive Facebook and MySpace Flash Vulnerability Exposes User Data

27 points by ed 17y ago

jacquesm 17y ago
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_accounts_hijacked/ http://www.yvoschaap.com/index.php/weblog/facebook_myspace_a...
cl3m 17y ago
He originally posted on reddit : http://www.reddit.com/r/programming/comments/a11mv/facebook_and_myspace_security_backdoor_wide_open/ http://www.reddit.com/r/programming/comments/a11mv/facebook_...
simonw 17y ago
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.
- wendroid 17y ago
  n.b. the space after asterisks are to avoid italics http://services.digg.com/crossdomain.xml http://services.digg.com/crossdomain.xml <allow-access-from domain="* "/> http://api.search.live.net/crossdomain.xml http://api.search.live.net/crossdomain.xml <allow-http-request-headers-from domain="* " headers="* "/> <allow-access-from domain="* "/> http://webservices.amazon.com/crossdomain.xml http://webservices.amazon.com/crossdomain.xml <allow-access-from domain="* "/> http://s.ytimg.com/crossdomain.xml http://s.ytimg.com/crossdomain.xml <allow-access-from domain="* "/> http://profile.ak.facebook.com/crossdomain.xml 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 http://www.vimeo.com/crossdomain.xml <allow-access-from domain="* "/> https://api.ebay.com/crossdomain.xml https://api.ebay.com/crossdomain.xml <allow-access-from domain="* "/>
  - danielh 17y ago
    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.
    - simonw 17y ago
      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_domain_policy.html http://www.adobe.com/devnet/flashplayer/articles/cross_domai...
      - danielh 17y ago
        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!
        deleted 17y ago
        [deleted]
pbhjpbhj 17y ago
http://kb2.adobe.com/cps/142/tn_14213.html 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?
joubert 17y ago
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.
- maukdaddy 17y ago
  One of those is not like the others.
stuff4ben 17y ago
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?
pasbesoin 17y ago
The techcrunch article links to this brief article, that I find both chilling and enraging. http://code.google.com/p/doctype/wiki/ArticleFlashSecurityPolicyAttack 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.]
CapitalistCartr 17y ago
" . . . 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.

27 points by ed 17y ago

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_accounts_hijacked/ http://www.yvoschaap.com/index.php/weblog/facebook_myspace_a...

cl3m 17y ago

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

simonw 17y ago

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.

wendroid 17y ago
n.b. the space after asterisks are to avoid italics http://services.digg.com/crossdomain.xml http://services.digg.com/crossdomain.xml <allow-access-from domain="* "/> http://api.search.live.net/crossdomain.xml http://api.search.live.net/crossdomain.xml <allow-http-request-headers-from domain="* " headers="* "/> <allow-access-from domain="* "/> http://webservices.amazon.com/crossdomain.xml http://webservices.amazon.com/crossdomain.xml <allow-access-from domain="* "/> http://s.ytimg.com/crossdomain.xml http://s.ytimg.com/crossdomain.xml <allow-access-from domain="* "/> http://profile.ak.facebook.com/crossdomain.xml 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 http://www.vimeo.com/crossdomain.xml <allow-access-from domain="* "/> https://api.ebay.com/crossdomain.xml https://api.ebay.com/crossdomain.xml <allow-access-from domain="* "/>
- danielh 17y ago
  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.
  - simonw 17y ago
    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_domain_policy.html http://www.adobe.com/devnet/flashplayer/articles/cross_domai...
    - danielh 17y ago
      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!
      - deleted 17y ago
        [deleted]

pbhjpbhj 17y ago

http://kb2.adobe.com/cps/142/tn_14213.html 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?

joubert 17y ago

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.

maukdaddy 17y ago
One of those is not like the others.

stuff4ben 17y ago

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?

pasbesoin 17y ago

The techcrunch article links to this brief article, that I find both chilling and enraging. http://code.google.com/p/doctype/wiki/ArticleFlashSecurityPolicyAttack 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.]

CapitalistCartr 17y ago

" . . . 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.