bugbounty

Facebook’s Oculus – Cross-Site Content Hijacking (XSCH) to Bypass SOP

8:42 AM




First off, before going in-depth about this I would like to paste you what a crossdomain.xml file is,here is something that are taken from Ookla, you can read more here.

What is the crossdomain.xml file?

The crossdomain.xml file is a cross-domain policy file. It grants the Flash Player permission to talk to servers other than the one it's hosted on.

In what circumstances do I need to use one?

You need a crossdomain.xml file when your Speedtest uses external hosts as testing servers.

Crossdomain.xml files

Flash Player’s default security model enforces the same origin policy similar to contemporary browsers and does not allow cross domain data read operations. However, it can make exception to this rule and disregard its default security model if a website in question hosts a cross-domain policy file (named crossdomain.xml) to allow data access from other domains. Insecurely written cross-domain policy files can expose critical application data over the internet. The example policy file below shows once such example where the website opens itself to read access from every running instance of Flash Player.

“

This forexample is how a (super) vulnerable crossdomain file looks like,


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


When flash requests to access that domain, it first asks the domain if it’s okay to snoop its contents. It does that by requesting domain.com/crossdomain.xml file and reading it, that crossdomain file says "Allow-access-from *(all) domains". This means, where ever our flash file is hosted (attacker.com/hack.swf), it will be able to read the contents of domain.com. This is much like a Cross Site scripting, but less in some case. We can only request and read, we cannot write. So it less.

Using this we can steal AntiCSRF tokens, craft CSRF exploits. Read html files using victim sessions (Messages, account balance…)

Here is a great example,”

  1. A user logs on to the banking website.
  2. The user then visits another website in different browser tab and that website hosts a malicious Flash file to retrieve user information from the bank website.
  3. When the Flash Player notices an attempt to perform cross-domain read operation, it retrieves crossdomain.xml file from the bank website to discover the permitted operations.
  4. It then sends out a read request to a known bank URL that returns sensitive information like user bank account numbers, account balance etc…
  5. The browser adds user’s session cookies to the outgoing requests and since the user is logged in, the malicious Flash file is served with critical user information.
  6. Th Flash file then passes it on to the malicious server.

“

You see? This is serious s***!

There is a particular flash exploit for this attack by Gursev Singh Kalra here.http://pastebin.com/EwqkGkxp

I was bored so I gave a shot of each oculus domain. All turned out to be safe, excpet one. It says

<allow-access-from domain="*.oculus.com" secure=”true”/>



It means everything that is hosted at *.oculus.com have read access at developer.oculus.com domain.  




Luckily, I know support.oculus.com have an upload box. While submitting a ticket, you can also upload image files. You see what I am going with this? I made my malicious flash.swf file, change the extension to flash.jpg, upload it at support.oculus.com and that file now have access to developer.oculus.com because the crossdomain allowed it.



The great about flash is, despite the file Mime, or format say flash.jpg, when we embed it as flash, it will act like flash despire its content/mime type.  

The exploit Scenario follows as:

1.       1. Create a malicious flash.swf that does malicious action, like read antiCSRF tokens or   messages.

2.       2. Change the extension of flash.swf to flash.jpg

3.       3. Navigate to support.oculus.com, create a ticket and upload our malicious flash.jpg file as a supporting image to the support team

4.       4. In our malicious domain (say attacker.com) host,  


<object type="application/x-shockwave-flash" data="https://support.oculus.com/attachments/token/APToMFwKw6O45WRIS5lf1HTP7/flash.jpg" width="1" height="1">

<param name="movie" value="https://support.oculus.com/attachments/token/APToMFwKw6O45WRIS5lf1HTP7/flash.jpg" />

</object>



5.       6. Now we navigate our victim to attacker.com and as soon as the flash files runs, Boom! We get everything we need. 

   Facebook had an amazing (better?) support about this. I got the fix (less than 9hrs)
   Hope you enjoyed the post! Comments would be nice! :)
    

   Report Timeline:

      Dec 29, 2014 6:59am - Initial Report
      Jan 27, 2015 9:09am  - Facebook Initial Confirmation
      Jan 27, 2015 6:55pm  - Fix!
     
Great cooperation guys! and I would like to thank the Facebook Security team and the program it self.

Conclusion:


-          Permit access from your crossdomain.xml because a simple mistake or “*” can cause a disaster.

-          In another option, make your uploaded files have a content-disposition header with appropriate values.