Last week, I disclosed the existence of an unpatched Flash vulnerability on WordPress (https://opnsec.com/2017/10/cve-2016-9263-unpatched-xsf-vulnerability-in-wordpress/). Today, I disclose technical details about this vulnerability. However, contrary to what I announced before, I won’t provide a POC nor enough technical details to allow attackers to exploit it. Responsible disclosure of unpatched vulnerabilities is never easy, and I’m trying to do this right both ethically and legally.

If you want to know more about the type of vulnerability, the impact and how to patch it please refer to https://opnsec.com/2017/10/cve-2016-9263-unpatched-xsf-vulnerability-in-wordpress/.

Technical details

WordPress uses an independent open-source tool to play videos in a webpage, MediaElement.js. ME.js provides a Flash fallback for browsers that don’t support the <video> tag or certain video codecs, using the flash file FlashMediaElement.swf. Vulnerabilities on this file have been reported in the past, like the awesome Flash based XSS found by cure53 https://gist.github.com/cure53/df34ea68c26441f3ae98f821ba1feb9c.

While investigating the source of this file in summer 2016, one particular instruction catched my attention

Security.allowDomain("www.[XYZ].com");

Note: I changed the real name of the domain to [XYZ].com

Security.allowDomain() can be described as a vulnerable function: using it will downplay the Same-Origin Policy which is the basis of website client-side security. You can read more about Flash security sandbox model here.

This code will allow a Flash file hosted on [XYZ].com to execute code on the FlashMediaElement.swf file, which is hosted on the WordPress site domain. [XYZ].com is a very well established company, so you could safely think that they would not use this privilege to execute malicious code on your website, the same way you would allow Google Analytics or Youtube to run scripts on your website. However, it is not that simple. With Security.allowDomain(“www.[XYZ].com”), you allow not only one specific file hosted on [XYZ].com to access your Flash security sandbox but any Flash file hosted on [XYZ].com.

Quick reminder about Cross-Site Scripting: XSS is the ability to execute arbitrary code (script, in this case Flash ActionScript3) in an external website. Not only a XSS allows you to access private info (like cookies) and private functions (like xhr requests) on the external website, but the arbitrary code will also be considered by the browser (or the Flash player) to be originating from the vulnerable website. This subtlety is what we will exploit here.

The thing is that [XYZ].com is vulnerable itself to XSS, or in this case Cross-Site Flashing. Which means that an attacker can execute arbitrary Flash code that will be considered by the Flash player as being originating from [XYZ].com. This forms a chain of vulnerabilities that will end up with any WordPress website being vulnerable to Cross-Site Flashing. Let’s make a drawing:

 

Facebook was vulnerable, too

A few months after reporting this issue, I was investigating various Flash files on facebook.com. One file contained the following instruction:

Security.allowDomain("www.[XYZ].com");

Facebook was using a file similar to flashmediaelement.swf to embed external videos on Facebook wall. The same vulnerability was present in this file and I was able to create various POC exploits using this vulnerability that would lead to Facebook OAuth bypass and even Facebook account takeover without user interaction.

I reported the issue to Facebook WhiteHat program and Facebook Security Team quickly fixed the issue and generously rewarded me.

Conclusion

This vulnerability is complex because it relies on multiple factors, technologies and companies. However, once an attacker is able to create an exploit, exploiting this vulnerability is easy because all of the requirements are usually present by default on a system. This vulnerability not only affects WordPress websites, but every websites hosted on the same subdomain as a WordPress website.

I hope WordPress will patch this issue soon and that my report will help raise awareness about Chained XSS vulnerabilities. Thanks for reading!