Update 05 June, 2015: added some details and an online vulnerability test. If the app is loaded from a URL containing the user:password part, the dotless decimal trick is not required.
The Unity Web Player plugin has a vulnerability which allows a malicious Unity application to bypass normal cross-domain policies and access any website with credentials of the current user. For example, the application could download the target user’s private messages from Gmail or Facebook and quietly pass them to the attacker.
When running on Internet Explorer, it’s also possible to read local files from the target user’s hard disk.
The attack can be carried out when the target user views a web page containing the attacker-crafted Unity app. Depending on the web browser and its version, the plugin may or may not start directly without confirmation.
Unity Web Player is a fairly popular plugin. In 2013 the company estimated the number of installs as over 200 million.
The plugin is used e.g. in Facebook games. Facebook “endorses” the plugin and has an API for embedding Facebook features in games:
One of the initial barriers to entry when using Unity is the installation of the browser Unity Web Player plug-in. We’ve constructed a Facebook branded Unity Web Player installation flow, showing potential players that Unity Web Player is endorsed by Facebook, a brand they know and trust.
As an NPAPI plugin, Unity Web Player has been available for all major browsers. However on Chrome, NPAPI plugins have been disabled by default since version 42 (April 2015).
The Unity Web Player plugin implements the normal cross-domain policies: an application running on a website can only access resources (URLs) on the same website, not other websites nor the local file system. These policies can be extended with crossdomain.xml files.
A specially formatted URL in a HTTP redirection can be used to bypass these restrictions. A malicious app loaded from “http://x:email@example.com” could access a URL from e.g. “http://x:firstname.lastname@example.org/redirector” which could return a HTTP redirect status code (301, 302, 307) and a Location: header pointing at “http://x:email@example.com/”.
The redirect should be denied as it points to a different domain. However, Unity Web Player allows the redirect because it erroneously bases its evaluation on the user:password part of the URL which is identical in both URLs (“x:y”).
The screencap below shows Firefox’s Network Monitor when running our demo exploit. After the application is loaded and the plugin has checked for updates, it accesses a URL on the “attacker site” and gets a 301 redirection to mail.google.com. The browser loads the target user’s email list (about 12 kB) and posts it back to the attacker. The demo exploit then parses the list and proceeds to download individual email messages.
We have set up an online test/demonstration:
Attempts to contact Unity Technologies by email and web contact form were made in December 2014. We also submitted two bug reports using Unity’s bug reporting tool on February 1 and April 13, 2015. There has been no response.
Update: we got a response from Unity Technologies on June 3rd. According to their email, the QA team has picked up the bug reports today and an improved security response procedure is in the works.
The vulnerability was found by Jouko Pynnönen of Klikki Oy, Finland.