III. XSF via loaderinfo.url redefinition

Let’s have a look at how the Main App loads the Modules :

The url of the module is dynamically generated by the main app by using it’s own url (2) and replacing the filename (watch_as3.swf) by the module filename (subtitles.swf) (3). This allows to handle multiple versions on the Main App, each one with it’s own Modules location.

To find it’s own url, the main app uses the loaderinfo.url property of appLoader.

Since appLoader is similar to an <iframe> in html, appLoader.loaderInfo.url is similar to the “src” attribute of the iframe.

In flash a Loader can load multiple swf files while in html an iframe can only load one window at a time

This means that if appLoader first loads the Main App and then immediately loads another Flash file the loaderinfo.url property of the Main app will not reflect the url of the Main App but instead the url of the other loaded flash file.
POC workflow

We removed Youtube Wrapper and replaced it with Evil Wrapper. Evil Wrapper will first load the Main App (1), and then immediately load another file (Noop.swf) with the same Loader appLoader (2). When the Main app will try to load a Module, it will get the appLoader url value (3) (evil.com/Noop.swf), replace the filename with the module name (evil.com/subtitles.swf) and load an arbitrary Flash file into it own Flash security sandbox (4).

From there Evil Module will be in the Main App Security Sandbox and will appear to be located at s.ytimg.com/[[IMPORT]]/evil.com/subtitles.swf. However, s.ytimg.com is a sandboxed domain which doesn’t have any cookie, CSRF token or webpage to exploit.

In part 2 I introduced URLLoader, which is similar to XHR. You can make cross-domain requests with URLLoader if the remote server has a crossdomain.xml file allowing “s.ytimg.com”

crossdomain.xml mechanism is similar to CORS headers for XHR cross-domain requests in javascript

The good news is that https://www.youtube.com/crossdomain.xml does allow https://s.ytimg.com/. Even more, https://drive.google.com/crossdomain.xml, https://docs.google.com/crossdomain.xml and other google domains also allow https://s.ytimg.com/.

This means that Evil Module can send requests to any URL at youtube.com, drive.google.com and docs.google.com (including POST requests and custom headers) and read the response source code (5).
Attack scenario:
1. The victim is logged in Youtube or Google Drive and has Flash player
2. The victim visits the attacker evil.com/evil.html page which contains a Flash object evil.com/evil.swf
3. The attacker has control over the victim’s Youtube, Google Drive and Google Docs accounts

Impact:
The attacker can steal private information, CSRF tokens and perform any CSRF action on these domains. A very nasty exploit could steal and delete all the victim Google Drive files and then post the POC url on Youtube comments from the victim account to spread the exploit. I won’t provide such POC (I would like to safely return to DefCon next year…) but it would only take about 20 LOC to build it!

Timeline:
09/11/2015 – reported to Google VRP
09/16/2015 – “Nice catch” from Google
09/25/2015 – Temporary mitigation and reward
10/14/2015 – Issue fixed and verified

Conclusion:
When using a sandboxed domain for hosting untrusted applications, like s.ytimg.com, you should always make sure that the sandboxed domain has no privilege on sensitive domains, like crossdomain.xml files, CORS, framing or CSP.

[UPDATED] Part 4 is now online with 3 Flash based XSS on Youtube!

You can also see a live Flash based XSS on twitter here