星期一, 十月 13, 2008

Flash Player Clickjacking漏洞防范解决

Flash Player被Clickjacking漏洞利用的问题

发布日期:2008年10月7日
  漏洞标示符:APSA08-08

  平台:所有平台

  受影响的软件版本:AdobeFlashPlayer9.0.124.0及更老的版本

  摘要

  Adobe注意到,最近发布的Clickjacking漏洞,使得攻击者有可能诱导使用浏览器的用户在其不知情的情况下点击其他的一个链接或对话框,这类潜在的“Clickjacking”问题已经影响到AdobeFlashPlayer的正常工作。Adobe正努力在即将更新的FlashPlayer中解决这一问题。

  解决方案

  客户:

  用户可按如下方式修改FlashPlayer的设置,以防止Clickjacking问题:

  点击如下链接进入AdobeFlashPlayer设置中的全局隐私设置页面http://www.adobe.com/support/documentation/en/flashplayer/help/settings_manager02.html

  1、选择“始终拒绝”按钮。



  2、在结果对话框中选择“确认”。



  注意:改变此设置后,用户将不会接收到“允许或拒绝相机和/或麦克风的访问”这一类的提示。用户可通过如下链接选择性的允许某些网站访问相机和/或麦克风:http://www.adobe.com/support/documentation/en/flashplayer/help/settings_manager06.html

  IT管理员:

  IT管理员可以在客户机的文件mms.cfg中,将AVHardwareDisable的值从0改为1,以禁用客户机中FlashPlayer的相机和麦克风的互动。想了解更多关于mms.cfg文件和AVHardwareDisable,请参阅AdobeFlashPlayer的管理指南的第57页:http://www.adobe.com/devnet/flashplayer/articles/flash_player_admin_guide/flash_player_admin_guide.pdf#page=57.

  Adobe计划于10月底前发布的FlashPlayer更新中解决这一问题。更多细节将发表的Adobe安全公告网页中,地址为http://www.adobe.com/support/security.

  此外,所有记录的的安全漏洞及其解决方案是通过Adobe的安全通知服务发布的。您可以在以下地址注册以获取服务:http://www.adobe.com/cfusion/entitlement/index.cfm?e=szalert。

  用户也可在Adobe产品安全事件反应小组博客中获取最新信息:http://blogs.adobe.com/psirt

  严重程度等级

  Adobe将其归类为关键问题。

  致谢

  Adobe衷心感谢SecTheory的RobertHansen,WhiteHatSecurity的JeremiahGrossman,DotSpots的EduardoVelaheMatthewMastracci以及LiuDieYu,感谢他们报告此漏洞并与Adobe一起帮助保护我们客户的安全。

Adobe公布跨浏览器攻击漏洞临时解决方案

前段时间安全人员透露了一个严重的“clickjacking”跨浏览器攻击漏洞,该漏洞影响很多主流浏览器,包括IE、Firefox、Safari、Opera等,还有AdobeFlashPlayer。

  这个被称为“Clickjacking”的安全威胁,原本要在OWASPNYCAppSec2008大会上公布,但厂商请求在开发出安全补丁之前暂时不要公开这个漏洞。近日Adobe在安全公告栏上第一次提及此事,发表了暂时的解决方案。本次漏洞影响FlashPlayer9.0.124.0之前的所有版本,希望各位注意。

日前,一个非常可怕的跨浏览器攻击漏洞Clickjacking正在逐渐显露在人们面前。通过这个Clickjacking漏洞你会在毫不知情的情况下“帮助”黑客“控制”你计算机上的摄像头和麦克风。

这个Clickjacking漏洞具有及其良好的跨平台性,能够影响所有主流桌面平台包括IE、Firefox、Safari、Opera 以及 Adobe Flash。

这个被称为 发现这个Clickjacking漏洞的是Robert Hansen与Jeremiah Grossman两名安全研究专家,从他们已经透露的一点相关信息来看,这个安全危险相当严重。

考虑到这个漏洞的高度危害性,经Adobe等厂商请求,OWASP NYC AppSec 2008大会将暂不对其进行公布。

什么是Clickjacking?

在中文里,Clickjacking可以翻译为“点击劫持”,而国外资料里对其的解释是“UI redress vulnerabilities(界面伪装漏洞 )”。

据参加OWASP半公开演示的人士介绍,这个漏洞与JavaScript无关,却能影响所有浏览器。

简单的说Clickjacking是一种攻击,是一种新型的WEB方式攻击。其中所涉及到的“Flash Player漏洞”,其实只是Clickjacking安全漏洞的一种表现形式,黑客可以通过一个简单的Flash游戏控制用户的摄像头或麦克风。

Clickjacking漏洞原理解析

在一个已经公布的Clickjacking Demo演示程序中我们不难发现Clickjacking的内涵。

在你可控制的页面A内有一个iframe,iframe的src链接到另一个域的页面B。设置这个iframe的CSS样式的透明度为0,并设置其CSS样式的z-index比页面A的其他元素的z-index大。这个iframe的Width与Height值都设置为足以保证用户可以点击到其中内容(页面B的内容)的大小。然后在页面A上放置一些按钮、链接等可以欺骗用户点击的元素,这些元素在iframe之下(z-index值决定),并恰好与 iframe的页面B内的关键元素在同一个位置。于是当用户被欺骗去点击页面A内的这些元素时,实际上点击了页面B内的关键元素,这些元素可以是:删除按钮、添加按钮、单选框、请求链接等等。再加上一些社会工程学技巧,这类攻击方式可以进行得非常巧妙。

这种Clickjacking漏洞攻击基于DHTML技术,用到了iframe,而且这样的攻击方式不一定需要JavaScript。虽然使用防iframe代码可以保护你不受跨站点攻击,但攻击者仍可以迫使你点击任何其指定的链接。

类似的欺骗还有——onMouseUpJacking、FormJacking、SubmitJacking——点击劫持。

如果黑客精心设计Clickjacking攻击页面,那么无论网页访问者进行正常鼠标点击还是无意间的鼠标点击动作,都可能会点击激发背后的隐形身影,而这个隐形身影则可以包括下载木马、打开摄像头等各类恶意行为。

据Hansen讲,他们已经同微软以及Mozilla谈论过这个问题,然而他们均表示这个问题非常棘手,目前没有简单的解决办法。Grossman更确切表示,微软最新的IE 8和Mozilla最新的Firefox 3均不能幸免。

那么除非你使用lynx一类的字符浏览器,同时不要任何动态的东西,这样才能保护自己。由于这个漏洞与JavaScript无关,所以即便你关闭浏览器的JavaScript功能也无能为力。事实上这是浏览器工作原理中的一个缺陷,无法通过简单的补丁解决。

解决方案

Adobe解决方案

Adobe对于Flash Player引起的Clickjacking漏洞作出回应,给出了临时解决方案,可以避免被黑客控制你的摄像头或者是麦克风。(Clickjacking漏洞影响AdobeFlash9.0.124.0之前的所有版本。)


To prevent this potential issue, customers can change their Flash Player settings as
follows:
1.Access the Global Privacy Settings panel of the Adobe Flash Player Settings Manager at
the following URL:
http://www.adobe.com/support/documentation/en/flashplayer/help/settings_manager02.html
2.Select the "Always deny" button.
3.Select ‘Confirm’ in the resulting dialog.
4.Note that you will no longer be asked to allow or deny camera and / or microphone
access after changing this setting.
Customers who wish to allow certain sites access to their camera and / or microphone can
selectively allow access to certain sites via the Website Privacy Settings panel of the
Settings Manager at the following URL:
http://www.adobe.com/support/documentation/en/flashplayer/help/settings_manager06.html.


用户可以通过改变Flash Player设置来避免Clickjacking漏洞带来的安全威胁:

1.下面的网址是一个全球个人Adobe Flash Player设置管理模板,在这里可以对不同版本的Flash Player进行针对Clickjacking漏洞的安全设置:


http://www.adobe.com/support/documentation/en/flashplayer/help/settings_manager02.html




2.打开上面的设置模板页面后,页面会判断你的Flash Player版本,并给出设置页面,选择里面的“始终拒绝”按钮。



3.在弹出的窗口里选择“确定”按钮。



4.注意:进行这个设置后,就无法允许或者拒绝对摄像机、麦克风的访问。

如果想允许某个特定站点上的内容访问摄像机或麦克风,请访问下面的网址,进入全球个人Adobe Flash Player设置管理模板:


http://www.adobe.com/support/documentation/en/flashplayer/help/settings_manager06.html




浏览器解决方案

Firefox 3的NoScript(1.8.2以上版本)插件可以防御Clickjacking漏洞攻击。NosSript也给出了ClearClick保护来防御Clickjacking漏洞可能造成的危害。

黑客攻击演示视屏

下面的视频演示了黑客利用Clickjacking漏洞发起攻击的实现过程:


(部分资料来源:金山毒霸官方博客、Adobe官方网站)

Clickjacking的一些细节

昨天晚上Rsnake放出了clickjacking的Detail,今天大致看了下,这种攻击对于Flash来说,危险性是加倍的。想你不经意间的鼠标点击,你的摄像头就被控制了或者你的麦克风就被录音了,这是不是很恐怖?

的确如此,所以adobe才会发狂。看到里面有个有趣的事情,Firefox由于有一个noscript插件,所以可以屏蔽掉iframe抑或object;但有个问题是ie没有的,就是object的调用在IE中是个叉叉而不ff中的iframe方式。

譬如此语句:<object data="http://www.baidu.com" width="200" height="200"></object>

也因此攻击方向分成了两种,一种是对目标网站的用户行为控制,一种是通过flash或相关控件对本地资源的非授权调用。而前一种是需要用户登陆的 (对于会员权限控制型的需要,其他用意的可能甚至不需要)(对于多标签浏览器的用户来说,登陆状态的概率很大),后一种则不需要。

余弦兄弟昨天也放出demo来,同样是flash的利用,虽然还不够完美,但是你已经可以看到你无意间的留言已经跑到百度空间这里来了,假如干点别的呢?

因此在一段时间内广大用户还是少点鼠标为好,尤其是陌生的站点,呵呵。个人估计maxthon很快也会放出插件来。

Clickjacking Details

Today is the day we can finally start talking about clickjacking. This is just meant to be a quick post that you can use as a reference sheet. It is not a thorough advisory of every site/vendor/plugin that is vulnerable - there are far too many to count. Jeremiah and I got the final word today that it was fine to start talking about this due to the click jacking PoC against Flash that was released today (watch the video for a good demonstration) that essentially spilled the beans regarding several of the findings that were most concerning. Thankfully, Adobe has been working on this since we let them know, so despite the careless disclosure, much of the work to mitigate this on their end is already complete.

First of all let me start by saying there are multiple variants of clickjacking. Some of it requires cross domain access, some doesn’t. Some overlays entire pages over a page, some uses iframes to get you to click on one spot. Some require JavaScript, some don’t. Some variants use CSRF to pre-load data in forms, some don’t. Clickjacking does not cover any one of these use cases, but rather all of them. That’s why we had to come up with a new term for it - like the term or not. As CSRF didn’t fit the requirements for clickjacking, we had to come up with a new term to avoid confusion. If you like Michael Zalewski’s term “UI redress attack” better use that one, it’s just not CSRF and shouldn’t be mistaken for any other attack, since it really is different. Here is the technical detail:

Issue #1 STATUS: Unresolved. Clickjacking allows attackers to subvert clicks and send the victim’s clicks to web-pages that allow themselves to be framed with or without JavaScript. One-click submission buttons or links are the most vulnerable. It has been known since at least 2002 and has seen at least three different PoC exploits (Google Desktop MITM attack, Google Gadgets auto-add and click fraud). All major browsers appear to be affected.

Issue #1a STATUS: Unresolved. JavaScript is not required to initiate the attack as CSS can place invisible iframes over any known target (EG: the only link on the red herring page). Turning off JavaScript also neuters one of the only practical web based defenses against the attack which is the use of frame busting code.

Issue #2 STATUS: Unresolved. ActiveX controls are potentially susceptible to clickjacking if they don’t use traditional modal dialogs, but rather rely on on-page prompting. This requires no cross domain access, necessarily, which means iframes/frames are not a prerequisite on an attacker controlled page.

Issue #2a STATUS: To be fixed in Flash 10 release. All prior versions of Flash on Firefox on MacOS are particularly vulnerable to camera and microphone monitoring due to security issues allowing the object to be turned opaque or covered up. This fix relies on all users upgrading, and since Flash users are notoriously slow at upgrading, this exploit is expected to persist. Turning off microphone access in the BIOS and unplugging/removing controls to the camera are an alternative. Here is the information directly from Adobe.

Issue #2b STATUS: Unresolved. Flash security settings manager is also particularly vulnerable, allowing the attacker to turn off the security of Flash completely. This includes camera/microphone access as well as cross domain access. Resolved using frame busting code, bug #4 below notwithstanding. However, as pointed out elsewhere, it is possible to directly frame the SWF file example here and here.

Issue #2c STATUS: To be fixed in Flash 10 release. All versions of Flash on IE7.0 and IE8.0 can be overlayed by opaque div tags. Using an onmousedown event handler the object click registers as long as the divs are removed by the onmousdown event handler function. Demo here of stealing access to the microphone.

Issue #3 STATUS: To be fixed in the final release candidate. Flash on IE8.0 Beta is persistent across domains (think “ghost in the browser”). This would be a much worse vulnerability except for the fact that it is beta and almost no one is using it.

Issue #4 STATUS: To be fixed in the final release candidate. Framebusting code does not appear to work well on some sites on IE8.0 Beta. Instead it is marked as a popup which is blocked by the browser - disallowing the frame busting code from executing.

Issue #5 STATUS: Unresolved. State of clicks on other domains can be monitored with JavaScript (works best in Internet Explorer but other browsers are vulnerable too) which is cross domain leakage and can allow for more complex multi-click attacks. For example a page that has a check box and a submit button could be subverted upon two successful clickjacks. Additionally, this can make the attack completely seemless to a user by surrendering control of the mouse back to the user once the attack has completed.

Issue #6 STATUS: Unresolved. “Unlikely” XSS vulnerabilities that require onmouseover or onmousedown events on other parts of pages on other domains are suddenly more likely. For example if a webpage has a XSS vulnerability where the only successful attacks are things like onmouseover or onmousedown, etc… on unlikely parts of the page, an attacker can promote those exploits by framing them and placing the mouse cursor directly above the target XSS area. Therefore, otherwise typically uninteresting or unlikely XSS exploits can be made more dangerous.

Issue #7 STATUS: Fixed in current releases post 1.8.1.9. Firefox’s Noscript plugin’s functionality to forbid iframe’s can be subverted by iframing a page that contains a cross domain frame or as Ronald found by using object tags. Giorgio Maone validated the issues and issued patches in future releases of the code as well as other potential clickjacking mitigation. 1.8.1.6, 1.8.1.7, 1.8.1.8, 1.8.1.9, 1.8.2 and 1.8.2.1 all contain anti-clickjacking code. All prior versions to 1.8.1.9 were vulnerable to cross domain clickjacking.

Issue #8 STATUS: Unresolved. Attempts to protect against CSRF using nonces can often be overcome by clickjacking as long as the URL of the page that contains the link that includes the nonce is known. Eg: Google Gadgets exploit discussed in Blackhat “Xploiting Google Gadgets” speech. The only semi-decent defenses against this are to omit the nonces in JavaScript space and also include the frame busting code in the same JavaScript. This will break for users who do not use JavaScript though, so it is not an ideal solution.

From an attacker’s perspective the most important thing is that a) they know where to click and b) they know the URL of the page they want you to click, in the case of cross domain access. So if either one of these two requirements aren’t met, the attack falls down. Frame busting code is the best defense if you run web-servers, if it works (and in our tests it doesn’t always work). I should note some people have mentioned security=restricted as a way to break frame busting code, and that is true, although it also fails to send cookies, which might break any significant attacks against most sites that check credentials.

Thanks to Adobe, Microsoft, Firefox, Apple and the various other vendors and people who have been helpful/supportive and care to fix the issue. Also thanks to the researchers who found these issues independently after Jeremiah and I were unable to do our speech, but kept it to themselves (Arshan Dabirsiaghi, Jerry Hoff, Eduardo Vela, Matthew Matracci, and Liu Die Yu). I will release a whitepaper to the informer via hackers for charity sometime today or tomorrow. I’ll also make that whitepaper available publicly sometime next week and information forthcoming when I have some time to put it up. Source to generic clickjacking code available here. I will keep this post up to date with additional issues and updates as I am aware of them.

手动解决方案

当前,最简单的办法是禁用浏览器的脚本和插件功能。
1、通过如下路径找到mms.cfg文件:C:\WINDOWS\system32\Macromed\Flash;
2、用记事本打开该文件;
3、将AVHardwareDisable的值从0改为1,保存退出即可。有些用户系统内无此文件,则可通过金山软件提供的Clickjacking漏洞修复工具自动进行修复

推广链接