Websecurity - Веб безпека

This is English version of my XSS vulnerabilities in 8 millions flash files article.

I’ll continue a topic, which I started in 2008 in my article XSS vulnerabilities in 215000 flash files. That time I found hundreds of thousands flash files vulnerable to Cross-Site Scripting attacks. After previous article, published at 12.11.2008, I continued researches and found, that much more flash files - millions flash files - were vulnerable to XSS attacks. As flash files in different global and local banner systems, as flash files at individual sites.

Vulnerable ActionScript code.

As I already wrote in previous article, vulnerability is in the next AS code. As with setting second parameter in function getURL (target), as without it.

getURL(_root.clickTAG, "_blank");

But, as my researches showed, in different flash files (at different sites and banner systems) different parameters are using for passing of a site’s address to flash file. Besides clickTAG there are also using url and other parameters.

getURL(_root.url, "_blank");

Attack occurs via passing of XSS code to flash file in clickTAG, url or other parameter:

http://site/flash.swf?clickTAG=javascript:alert('XSS')

http://site/flash.swf?url=javascript:alert('XSS')

There are also flash files which are using two parameters, particularly clickTAG and TargetAS, with the next AS code:

getURL(_root.clickTAG, _root.TargetAS);

Attack occurs with using of parameters clickTAG and TargetAS:

http://site/flash.swf?clickTAG=javascript:alert('XSS')&TargetAS=

After click on flash the transfer of string to function getURL occurs, which passed to flash via appropriate parameter. Thus can be executed JavaScript code, which was passed to flash. So it’s strictly social XSS.

Prevalence of the problem.

Vulnerability exists in ActionScript code for counting of clicks in flash banners. And taking into account that such code is using for many years in different banner systems of Internet (including widespread instructions for developing of flash banners with using of vulnerable AS code), so the problem is widespread enough. For example, I registered at banner.kiev.ua already in 2000, and, as far as I remember, already at that time they had recommendations at the site with using of vulnerable AS code.

So problem is concerned with faulty recommendations for developing of flash banners with possibility of counting of clicks. And it’s concerned millions flash banners in the Net.

Such vulnerabilities exist in many banner system, as global, as local ones. Particularly these vulnerabilities I found in systems phpAdsNew, OpenAds and OpenX (at many sites on these engines), and also in banner system www.banner.kiev.ua and in other banner systems of Uanet an Runet.

There are a lot of potentially vulnerable flash files in Internet (according to Google):

filetype:swf inurl:clickTAG

About 3960000 results. At 12.11.2008 there were about 215000. Growth in 18,42 times for this time.

filetype:swf inurl:url

About 4050000 results. At 12.11.2008 there were about 996000. Growth in 4,07 times for this time.

In total it’s about 8010000 (more than 8 millions) flash files which are potentially vulnerable to XSS attacks. Not all of these flashes are vulnerable, but many of them. And these are only those flash files, which were indexed by Google, and actually there can be much more of them.

Among them there are about 12400 + 275 gov-sites - the sites of state institutions of different countries.

Note, that some of these flashes are using method #1 for protection against XSS, which is mentioned bellow. But it’s small percent of flashes - mostly they are using vulnerable AS code.

Besides, similar Strictly social XSS vulnerability I found at 15.03.2009 in plugin WP-Cumulus for WordPress (in file tagcloud.swf).

filetype:swf inurl:tagcloud.swf

About 34000000 results. I.e. another 34 millions flashes which are potentially vulnerable to XSS attacks . Add 34 millions to 8 millions and result 42 millions of vulnerable flash files!

Nuances of work in different browsers.

In flashes with set target = “_blank” it’s not possible to get to cookies in Internet Explorer (particularly IE6), Mozilla and Google Chrome. But it’s possible to get to cookies in Firefox 3, Opera 9.52 and possibly in other browsers.

Also in case of set target = “_blank”, JS-code doesn’t work in browsers IE6 and Google Chrome.

If target is unspecified, or if target set to other than “_blank” (including via parameter TargetAS, if it’s using in flash), JS-code works in all browsers. And it’s possible to get to cookies in all browsers.

Examples of vulnerable flash files.

Among sites with flashes vulnerable to XSS there is server.cpmstar.com (attack via parameter clickTAG):

• alert(’XSS’)

Among gov-sites as an example of flash at www.fatherhood.gov (attack via parameter clickTag):

• alert(’XSS’)

Example of vulnerable flash at www.banner.kiev.ua (attack via parameter url):

• alert(’XSS’)

Example of vulnerable flash at www.wie-man-sieht.net, which allows to get to cookies in all browsers (attack via parameter url):

• alert(’XSS’)
• alert(document.cookie)

Example of vulnerable flash at www.adspeed.com, which allows to get to cookies in all browsers (attack via parameters clickTAG and TargetAS):

• alert(’XSS’)
• alert(document.cookie)

Protection of flash files against XSS attacks.

To prevent such XSS attacks via flash files it’s needed to not use vulnerable AS code and it’s needed to use one of the next methods.

1. Instead of vulnerable AS code it’s possible to use more secure code. E.g. code which is mentioned at Adobe’s site - Designer’s Guide: Building Macromedia Flash Banners with Tracking Capabilities.

on (release) {
if (clickTAG.substr(0,5) == "http:") {
getURL(clickTAG);
}
}

It’s code on button. If using of code on frame, then for button “button” code will be the next:

_root.button.onRelease = function () {
if (clickTAG.substr(0,5) == "http:") {
getURL(clickTAG);
}
}

But this method isn’t protecting against URL spoofing, which allows to conduct of redirection attacks to arbitrary (including malicious) sites. So it’s better to use more secure AS code.

2. To use direct URL in flash (http://site), without using of parameter clickTAG.

3. If needed to count clicks, then it’s possible to use URL to banner system (http://banner/click?id=1), which will redirect to necessary site.

For example, in my system MustLive Banner System directly in the interface I’m recommending to use for flash banners above-mentioned methods #2 and #3, so there is no this problem with XSS via flash files in it. So attend to your flash files and don’t allow such vulnerabilities in them.

This entry was posted on 22:49 21.12.2009 and is filed under Статті, Дослідження. You can follow any responses to this entry through the RSS 2.0 feed.