[Flash!attack简介]
本文我们将描述一个安全漏洞,这个漏洞存在于很多嵌有Flash,或者是上传有Flash的网站中.本文是建立在一个事实之上的,那就是大量的web浏览器都安装了Macromedia Flash plugin/ActiveX control.这可能使攻击者发动跨站脚本攻击.我们将不讨论跨站脚本攻击的细节,而是解释Flash是如何被用于注射javascript脚本到一个充分过滤了的web程序中去的.
[现有的web程序和跨站脚本]
web程序构成了动态站点,允许用户和站点本身交互,这种站点包括Hotmail,Yahoo,MSN和其他许许多多站点,为了支持多用户登陆,通常都需要验证用户的身份.
在线交流站点,如deviantART,每个用户都有自己的页面和web空间,他们可以上传一些艺术作品如诗,画,照片,当然还有Flash动画.登陆后的用户(当然也包括匿名用户)可以看到别人上传的东西,这表示文件和目录在不同的用户之间共享.从安全角度来看,被浏览的文件受到文件的拥有者和浏览它的人的信任.
跨站脚本攻击,就是现在常说的XSS,是一种标准的,利用文件所有者和浏览者的的信任来进行攻击的方式.当一个前来浏览文件的用户,浏览一个恶意页面(另外一个不怀好意的用户构造的)时,这个含有代码(如Javascript)的页面就会盗取密码,或者用户的隐私.
[防止跨站脚本攻击]---目前的办法
大多数的有安全意识的web程序通常采用如下3种手段来防止XSS攻击
1.在用户输入的字符中禁止Html语句
2.只允许特殊的标记,用这种标记来代替html标签产生的效果
3.从html代码中过滤掉动态脚本
这些办法通常被确信能够防止恶意用户注入自定义的html或者动态脚本.web站点,如Hptmail,yahoo Mail 尝试利用文件过滤来根除所有注射javacsript的可能性.一些权威,
如CERT和Microsoft已经详细描述了过滤的方法,以及XSS带来的危害.
一些网站允许Flash文件被上传并显示,别的仅仅允许上传flash文件以便下载,就像FTP站点一样.
由于网站设计时的不足,加上没有把Flash看作一种动态的脚本,网站的过滤可以被轻易地绕过.下面我们就将描述如何做到这点.
[Flash! attack]
Macromedia Flash有它自己内置的脚本语言---ActionScript;ActionScript在熟练的javascript编程者看来是非常简单的,因为它有着和javascript,c,perl相近的语法.但是这个简单的语言可以被用于复杂的动画,模拟,游戏的创建....我歉行巳氖撬膅etURL()函数.这个函数允许我们把用户重定向到另一个页面上去.这个函数的参数通常就是一个URL,例如"_blank>http://www.itaq.org",所以这个脚本看上去就是这样:
getURL("_blank>http://www,itaq.org")
假设我们用一个javascript语句代替URL:
getURL("javascript :alert(document.cookie)")
上面这个例子弹出一个javascript警告筐,里面包含有用户的cookie信息.这表明我们成功利用了Internet EXPlorer 和 Flash的特性,向网页上注入了javascript脚本.示例Flash文件类似于截图所示
[1] [2] [3]
(图1)
[脆弱的展点和软件例子]
Ezboard(_blank>http://www.ezboard.com/)可能是最著名的免费在线电子公告系统之一,这个BBS是基于HTTP的,允许用户用Flash作为签名,通过使用EMBED标签.因此在我们的测试中,我们按照如下所示构造我们的签名:
<embed src="_blank>http://eyeonsecurity.net/download/example.swf" pluginspage”_Prod_Version" target=_blank>http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version ShockwaveFlash” type="application/x-shockwave-flash" width="0" height="0" > </embed>
看图可能会更清楚些:
(图2)
这段代码将被添加在攻击者提交的任何文章后面,使之能够盗取用户的cookie.
DeviantART是一个非常流行的站点,它鼓励用户提交flash动画,并且允许别人浏览.当然一个恶意的用户也可能提交一个恶意的flash去透取其他用户的密码(包括管理员的),他会创建一个新的帐号然后上传一个特殊的flash,之后就只需要等待别人浏览就行了.
MSN Communities----这个站点允许用户上传他们自己的文件.....我们上传的是SWF文件,它可以执行一段javascript代码.这明显是一个网站的安全漏洞.在EyeonSecurity的一份名为“Microsoft Passport Account Hijack Attack”的文章中,还概括了了一个MSN创建证书的安全漏洞
匿名服务站点如Anonymizer 和 The-Cloak,也容易受到这种攻击,它们尝试从html中过滤出javascript脚本,但是对此种攻击毫无办法,试着想想一下,访问一个特殊的flash便可使所有的过滤都不起作用
2个专门的论坛(BBS)ikonboard和YaBB,他们软件中的一部分代码可能导致遭受这种攻击.这2个bbs都只允许使用专门的标记来产生最终的页面,然而他们允许通过
上面这句将被脚本转换成如下语句:
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width=200 height=200>
<param name=movie value=http://www.itaq.org/download/example.swf>
<param name=play value=true> <param name=loop value=true>
<param name=quality value=high>
<embed src=http://www.itaq.org/download/example.swf width=200 height=200 play=true loop=true quality=high> </embed>
</object>
当然,上面的这些例子仅仅是举些例子而已,事实上,任何允许flash被插入的站点都可能受到XSS攻击.本文提到的所有站点在本文被公开之前都受到了通知,因此当你读这篇文章的时候,他们已经补上了相应的漏洞.
[修复问题]
简而言之:在你的网站上禁止flash文件.
然而,在大多数情况下,解决办法并不是那么简单,考虑deviantART的例子,flash文件是构成站点的一部分[......]
可能的解决办法:
Macromedia (Flash player developer)
Macromedia和EyesOnSecurity一起提供了一个解决办法.建议允许web设计者改变嵌在html页面中的flash的行为,这个办法对论坛和相似的站点有效,但是不能修改已经存在的flash动画
然而这个办法不适合用于像MSN Communities和deviantART这样的站点.这种站点允许用户上传SWF文件,而不是链接它们.Macromedia不鼓励站点允许用户上传未检查的flash文件.
必须提到的一点就是flash与html页面的交互是通过不同的功能来支持的,本文描述的方法是"hack"而不是"支持"功能.有一个著名的程序能够产生flash动画---Swish,它使用Javascript方式去支持web设计者插入他们自己的javacript代码.Macromedia已对此发布了一个公告:
_blank>http://www.macromedia.com/v1/handlers/inde...ex.cfm?ID=23051
web设计者和web维护人员
一个好的解决办法就是在getURL这个函数中过滤掉有害的参数,当web站点允许SWF被上传到服务器上时,网管们应该解析并过滤flash的内容,然后才允许用户上传.网管应该禁止任何包含有getURL(),但是不指向http站点的flash文件.另一个的解决办法是把getURL()函数指向一个新的窗口,这个新窗口指向"About_blank"通过使用以上这些办法,javascript URLS将不会在浏览者的机器上以浏览者的权限执行.但是,就像Bertrand Saint-Guillain
[1] [2] [3]
指出的那样,上面的这些解决办法并不完全可靠,由于事实上,ActionScript是一个复杂的脚本语言,它还提供了eval这个函数,这个函数甚至允许更加狡猾的黑客穿透对ActionScript脚本的过滤
例子:
a="get";
b="URL";
c="javascript :";
d="alert('bypassed');
void(0);";
eval(a+(c+d);
上面的这个例子将传透任何之前所提的防范办法,因为它没有直接使用getURL函数
因此另外的一个更加可行的办法是使用一个独立的域来存放和显示Flash动画,这个办法也可以用在其他的文档上面,如html文件,这样可以使用动态页面,并且防止黑客窃取cookie.例如假设你的域是一个"securewebapplication.com",你就可以把可能怀有恶意的内容保存到“securewebapplication.net”.当然这意味着“securewebapplication.net”上的内容不需要权限验证,所以是共享给匿名用户的,值得注意的是那些恶意的内容应该只能从一个“sanitized”域显示,就是说如果一个flash
文件被包含在一个HTML文件中,那么这个HTML文件也必须从一个“sanitized”域显示.
Web开发人员也可以利用一个指向放在第三方服务器上的flash动画的IFRAME标签来代替EMBED或者OBJECT标签,这样我们就仍能在HTML文件中包含所需的flash动画,但它却是从一个子框架中读取的,如此就排除了某些人通过使用JavaScript来盗取cookies以及实施跨站脚本攻击的可能性.这种方法在NeWorder的消息板块被首次描述,然后被添加到Macromedia出版的Bulletin中.虽然这种解决方案很consistent,但它不兼容那些不支持IFRAME的浏览器.
[对使用特定产品/服务的用户的建议]
Ezboard:
Ezboard针对它的产品给出的答复如下:
不幸的是,要做到cookies不被盗取非常非常难,如果我们做到了,ezboard就不会像现在这样有那么多的定制选项.幸运的是,我们通过检测用户的IP地址来保证登陆的高安全性,当真实的用户登陆后,其他人就不能再用cookie来登陆,这是个很好的解决方案.然而IP检测对于那些使用代理的internat用户并不起作用.
YaBB:
Corey Chapman给出的解决方案如下:
我们并不把它作为一个选项,但我们已经通知人们把yabbc.pl文件中关于flash引用的行注释或者删除掉,如果这个版本将有一个选项,我们有可能在下一次升级中给它做一个disable的属性.
这是个非常直接了当的解决方案,当然我们还建议在编辑消息的时候去掉flash图标的显示.
Ikonboard:
依照Andrew(Ikonboard),这个产品允许管理员禁用flash支持.
问题是我们不能就这样去掉那个选项,因为那样做后很多用户可能对我们不满,所以我们现在只是允许你禁用那个选项,同时不允许flash出现在你的板块上.
这听起来像一个灵活的解决方法---但我们不测试这个属性
（出处：http://www.sheup.com）
[1] [2] [3]
YaBB:
Corey Chapman给出的解决方案如下:
我们并不把它作为一个选项,但我们已经通知人们把yabbc.pl文件中关于flash引用的行注释或者删除掉,如果这个版本将有一个选项,我们有可能在下一次升级中给它做一个disable的属性.
这是个非常直接了当的解决方案,当然我们还建议在编辑消息的时候去掉flash图标的显示.
Ikonboard:
依照Andrew(Ikonboard),这个产品允许管理员禁用flash支持.
问题是我们不能就这样去掉那个选项,因为那样做后很多用户可能对我们不满,所以我们现在只是允许你禁用那个选项,同时不允许flash出现在你的板块上.
这听起来像一个灵活的解决方法---但我们不测试这个属性
（出处：http://www.sheup.com）
[1] [2] [3] [4]
问题是我们不能就这样去掉那个选项,因为那样做后很多用户可能对我们不满,所以我们现在只是允许你禁用那个选项,同时不允许flash出现在你的板块上.
这听起来像一个灵活的解决方法---但我们不测试这个属性
（出处：http://www.sheup.com）
[1] [2] [3] [4] [5]