Shortly after my recent blog post concerning widespread XSS in ad network code, I discovered similar vulnerabilities in Flash video ads (and other Flash products/components), resulting in a substantial industry-wide mitigation of XSS in Flash-to-JavaScript communication. Perhaps most interestingly, these vulnerabilities presented risks similar to my previous findings except that, in most cases, Ad-Block solutions employed by the client would not have prevented exploitation.

It all started with a DOM XSS payload (similar to my previous post), for example:

1

http://www.cnn.com/#'-alert(1)-'"-alert(1)-"

Though this payload did not trigger the exact previous vulnerability, it produced console errors suggesting it was exploitable.

I found similar console errors across many top-tier sites, leading me to dig deeper into the root cause. After tracing the source of the console errors, I completed the syntax to produce a successful payload against one of CNN’s video ads:

Note the
LR_PAGE_URL value above which breaks out of the string using two backslashes — one provided by my payload in the URL, while the other seems to be added by the code that processes the input. This code obviously isn’t handling escape sequences correctly, which is the cause of the DOM XSS vulnerability.

I noticed a similar vulnerability in several different Flash components involving the same
__flash__toXML function, though I couldn’t find it defined in any of the surrounding code. It turns out that this function is implemented by Flash, for instance, when developers make a call to
ExternalInterface.call() in order to pass data from Flash to JavaScript on the page. Below is an example scenario using such a call in order to send data to a logging server:

As you can see, Flash wraps the JavaScript function in a try/catch and executes the specified function with its parameters (however unsafely). The mishandling of these parameters seems to be a weakness in Flash’s implementation of
ExternalInterface in general, rather than an issue with individual projects using it. After researching the issue a bit more (see here and here), it seems that Adobe does not plan on fixing it, leaving it up to developers to mitigate. One such mitigation is the use of base64 encoding when passing parameters. This would limit the characters in the resulting JavaScript strings such that special characters would be impossible.

Disclosure

While identifying affected sites was straightforward, tracing individual vulnerabilities to a responsible vendor was not. In many cases, an affected site may not have triggered the payload on every page view due to the nature of the components involved. Further, a given page view could have used a combination of Flash components which only added to the complexity of identifying the source.

LiveRail (Facebook)

As shown in the above example, LiveRail’s Flash Ad Player was affected by this issue, so I began researching contacts in order to report it. Since LiveRail was acquired by Facebook in 2014, I felt good about reporting it — until I realized LiveRail was out of scope per Facebook’s bug bounty terms.

Understandably, I wasn’t entitled to a bounty payout, but I wanted to get the issue patched regardless. Thanks to Alex’s quick response, I reported it to Facebook on 2016-03-09 and, after a little back and forth with their security team, it was patched on 2016-03-10.

Akamai/Inform

A number of the sites affected by this vulnerability were partnered with Inform — a 100% video digital advertising company. The company’s “NDN Widget” was vulnerable, of course impacting all customers using it. Here’s a sample payload and the respective vulnerable code:

Note the vulnerable parameter, in this case, is the
windowLocation string within the
params property.

Reaching out to Inform ended up being one of my poorer experiences with vendors. Not only were they completely unresponsive in my numerous attempts of contact (until I phoned their office directly), their “Head of Programmatic & Advertising Technology” was quite dismissive of the report and its risks (at least at first). Nevertheless, Inform’s team came to eventually understand the issue, its impact to customers and end users, and worked to get the issue resolved.

After a bit of discussion on the issue, I learned that Inform actually licensed their player through Akamai. After some group discussion between the two organizations, Akamai patched their Adaptive Media Player, resolving the issue for Inform as well as any other users of the player. Akamai had to be contacted multiple times to get status updates, but apparently released a fix on 2016-03-31.

Akamai sent the following communication to their customers:

Akamai was recently notified that one of the components included in the Adaptive Media Player (AMP) for Web contains a cross-site scripting vulnerability. Please upgrade your AMP Web to version 4.45 (Standard) or 2.45 (Premier) to ensure to your AMP is secure. If you have questions or need further assistance, please contact the AMP Support team amp-support@akamai.

Adobe

Adobe’s AppMeasurement for Flash library was also affected by this vulnerability, though only impacted sites with
debugTracking enabled. An example payload with its respective vulnerable code is below:

Again, the
hostedAtURL was vulnerable to the same issue as the other products in this post. I reported the issue to Adobe on 2016-03-11 and they released a fix with a security bulletin (CVE-2016-1036) on 2016-04-21.

Conclusion

Though plans are being made to phase out Flash entirely (at least in Chrome), it’s here to stay for the short term (much to the dismay of the security community). There are likely many additional products in the wild affected by this vulnerability, most of which have probably been vulnerable since their initial release. Until Flash has an end-of-life date announced, serious abandonment of it on the web is likely to be slow, meaning we will continue to discover and mitigate vulnerabilities in similar components for the foreseeable future.