鬼仔's Blog

作者：小金
来源：网络技术论坛

一. 不安分的网页
职员李小姐这两个月来都觉得比较纳闷，为什么最近开很多网页都会跳出RealPlayer播放器，难道网络又开始了一轮视频播放形式新潮流？但是每次她都是等了很久也没看到有音乐或电影开始播放，久而久之，她已经习惯这个现象了，直到那一天，她保存在硬盘上的重要客户文档无缘无故被加了密，并且目录下多了个名为“要想恢复文档请将500元汇入帐号xxxxxxx”的文件……
当公司网络部的同事询问李小姐最近有没有发现什么异常现象时，李小姐才如梦方醒：打开网页怎么会跳出RealPlayer？RealPlayer一般不是都在网页里面播放的吗？

二. 你的地盘我做主：来自第三方工具的危害
随着安全危机的影响力逐渐扩大，许多网民的机器里都开始出现各类安全防护工具的身影，像各种反病毒产品、360安全卫士、超级巡警等，正是由于这些工具的存在，中国网民的机器上原本四处洞开的窗口终于得以关闭，然而网民们很快发现，虽然自己的“瘟到死”系统已经安装所有补丁更新，但是仍然逃脱不了被病毒侵袭的事件，最终只能寄希望于反病毒产品的庇护，结果，就在反病毒产品的监控下，恶意流氓和未知木马照旧可以大模大样的在系统里招摇过市，普通网民们只能望“马”兴叹——也不对，在很多情况下，广大网民们根本就不知道自己的系统已经被木马驻扎！
许多人接受不了这样的事实，高手说，系统要勤打补丁，好，我们照做了；高手又说，系统要装几个防御工具，好，我们装上了各种反病毒产品和超级巡警、360安全卫士等安全检测工具，结果到了最后，每次在新病毒来袭的时候，我们仍然是首当其冲的受害者，而什么工具都没装的高手却偏偏不会中招？安全工具，真的有效吗？
这种质疑论点其实是不必要的，系统补丁必然要打，一些必须的系统加固工作也是必须要做的，但是这些措施只是为了防御各种蠕虫病毒、系统漏洞入侵等，并不代表从此就可以百毒不侵，更何况，每个人的系统中，都存在有一个时时敞开的大门，正是它，让木马防不胜防，除非你决定更换另一个系统平台，否则你永远也摆脱不了它的影响。
这扇大门，就是我们每个人都熟知的Internet Explorer，IE浏览器。
不知道会不会有人立即怒发冲冠要去把浏览器卸载或者计划好投诉浏览器厂商不做安全工作了，但是作为我们与互联网世界接触的一大窗口，浏览器是不可或缺的重要工具，像IE、FireFox、Opera等，正是浏览器为我们搭建了这个交互平台，将各种交互应用呈现在我们面前，在这里，浏览器的主要功能就是“交互”，而就是这个特性，让入侵变得难以彻底根除。
因为浏览器面对的是互联网众多的交互功能，以单独一家公司自身的处理能力，要让浏览器能识别处理世界上尽多数的交互功能是不现实的，因此任何浏览器厂商都要为程序设计一个公开的接口规范让其能调用扩展或第三方接口程序，以便把它自身并不认识的交互任务交给某些有特定处理能力的接口程序来处理，所以浏览器并非是一个独立的程序，而是一个可以调用多个扩展组件运行的结合体，这些扩展组件通常也被称为“插件”（Plugin）。浏览器通过读取页面特定标记来决定自己需要加载什么组件执行，例如读取到脚本标记就自动加载脚本扩展组件执行、读取到XML标记就交给XML处理扩展执行，如果这些众多的扩展组件被取消，你将会发现浏览器大概只能显示最基本的文字和图片了。一个最简单的例子，现在网络购物和网络银行已经走入了千家万户，大家都知道“登录”步骤的操作过程——输入用户名和密码，然后点击“登录”按钮。但是并非所有用户都能平稳的享受到这个过程，有些用户会发现，自己的浏览器里，那个用于输入密码的框框成了一个类似于图片显示不出来时报错的大红叉，这就是浏览器交互功能组件缺失时最显著的表现。由于网络银行和网络购物必须在用户平台中实现相对安全的防御手段，所以要求用户输入的敏感数据是不可被轻易捕获和拦截的，这种要求，浏览器厂商自身是无法为其解决的，否则我们每次要用一个新的网络银行就必须等待厂商升级他们的浏览器产品了，这显然很不现实，所以为了兼顾这个问题，浏览器厂商在设计初期就必须加入一套可以被第三方厂商调用的接口规范，利用这个接口，任何人都能自己编写符合规范的程序来实现与浏览器的数据交互，它的工作原理请看前面的描述。
因此，网络银行的设计者必须开发一套浏览器组件，并通过特定的页面标记来激活运行，最终将一个“密码输入框”显示在网页（浏览器的容器对象）中，并接受用户的输入，当用户点击提交按钮时，它将加密处理后的输入数据附加在浏览器的交互流程中通过“安全套接字协议”（HTTPS/SSL）返回到服务器端，这样才完成了数据交互，我们才得以登录淘宝、支付宝、拍拍、各种网络银行。在国内，这些组件是以ActiveX控件的形式加载的，它们使用的是IE提供的接口标准，而另外两大浏览器阵营FireFox和Opera则不支持这种交互方式，于是，在中国，大部分网民们知道的只有两种浏览器，一种是支持中国网银的，一种是不支持中国网银的。
实际上，不仅是网络银行等交互需要第三方组件，当我们使用浏览器在各种小游戏网站上消磨时间时，是Flash插件被载入浏览器为我们提供交互功能，而我们在百度MP3里试听音乐时，是因为微软自家的Media Player插件和RealNetworks的RealPlayer插件正在浏览器中工作……诸如此类，浏览器结合各种扩展组件最终构成了我们的网络生活。
但是，事情并非始终都是美好的，天使和恶魔，就在于一念之差。
当浏览器将一个组件加载后，这个组件就成为它的一部分，浏览器被称为“宿主”，根据设计的标准，组件能拥有宿主所拥有的所有权限，也能控制宿主的行为，而且，它更能执行普通程序所拥有的所有功能，简单的说，一个被浏览器加载的组件，除了它的生命周期取决于宿主以外，其他特性与一般应用程序无异，而且，它比一般应用程序还多了一个可以传递参数的交互接口，这样的设计初衷是为了方便浏览器宿主将其加载时进行一些必要的初始化工作，但是，这一部分的数据是通过网页HTML代码以明文的形式写入的，任何人都可以对其进行修改和控制。
并且，由于微软自身浏览器的接口标准可以响应ActiveX控件交互，那就意味着，大部分ActiveX控件都可以通过组件的形式载入浏览器，并对其参数进行控制，虽然它可能会由于不符合接口数据返回的规范而不会造成浏览器有任何行为，但是，它已经被加载运行了，数据也已经传递了。
//文章出处:网络技术论坛(http://bbs.nettf.net) 作者:小金
正是这个特性，引发了新的一轮网页木马狂潮。
早在好几年前，网页木马（WebPage Trojan）的雏形——浏览器MIME解析漏洞结合电子邮件文档EML载体以浏览器子框架IFRAME的形式汹涌来袭，想必经历过那个年代的人都不会忘记“求职信”、“大无极”这些著名的“邮件木马”的可怕吧，实际上它们的本质都是网页木马，只不过是因为Outlook Express等邮件客户端很不幸的支持网页形式浏览罢了，最终导致它们被触发的因素仍然是那幕后为网页显示而工作的IE浏览器控件，我们可以将开启了网页视图的邮件客户端视为一种特殊的网页浏览器，EML就是在浏览器里被解释执行最终将病毒释放出来并执行的。
这个入侵狂潮随着IE6的出现而逐渐被历史埋没，但是，有人接过了它们手中的接力棒。
当第一个安全研究员发现通过浏览器加载的扩展组件会由于传入的参数检查不严而引发“缓冲区溢出”的现象时，新一代的网页木马正式拉开了序幕，不少安全团体都开始对各种主流的浏览器插件进行调试，然后，他们开始扩大“浏览器插件”的理解范围，最终，许多网页成了一个又一个树桩，长年累月的等待着倒霉的网民往上面“撞”，而这些问题的根源并非来自操作系统和浏览器本身，所以，即使网民们补上了所有系统补丁也无济于事。
2007年10月26日，国内安全团队报道了一个由RealPlayer引发的高危漏洞“RealPlayer ActiveX播放列表名称栈溢出”，该漏洞的真正问题文件是MPAMedia.dll，该文件用于处理播放列表的函数传参存在栈溢出漏洞，但是入侵者是通过对RealPlayer用于与浏览器交互的ActiveX组件“IERPCtl”（RealPlayer Control for Internet Explorer）来触发的，它位于RealPlayer目录里的rpplugins文件夹下，对应文件名为“ierpplug.dll”，它平时被用得最多的作用就是在浏览器中显示内嵌的媒体播放器和传递相关内容参数，然而这一次，它被作为一条直达要害的桥梁，以至于浏览器成功下载木马并执行，它也背上了黑锅，而实际上，它只是作为一个数据转接的通道存在而已，真正的元凶是MPAMedia.dll。
当RealPlayer ActiveX被载入浏览器后，它的所有参数便能通过HTML代码的形式传递，最常见的就是内嵌于浏览器的播放器，它至少需要一个待播放的媒体文件位置参数，在此基础上，网页设计者还能通过另一个参数来决定它能否自动播放媒体文件，这是大众最经常涉及的交互功能，大家都不会陌生，然而实际上，除了这些大众参数，还有个别极少被使用的参数存在，也许是因为它们“非主流”，RealNetworks没有将它们的安全盘查放在心上，但是，它们毕竟是存在的……
于是，漏洞就此出笼。一些安全研究者发现，RealPlayer ActiveX导出的“Import”功能函数中的第二个参数“playlist”是直接提交给内部文件MPAMedia.dll与之对应的函数中的，但不幸的是，该函数存在边界检查不严问题，可引发控件的“缓冲区溢出”，从而导致宿主（ierpplug.dll作为传参者，成为了MPAMedia.dll的宿主，而IE内核的浏览器加载了ierpplug.dll……于是多米诺骨牌效应发生了，一浪推一浪，后浪IE冤大头死在沙滩上……）发生千篇一律的结果：允许执行任何代码，如下载一个恶意程序运行、或直接删除用户数据等，而现在的主流手法自然是前者，也就是所谓的“网页挂马”，入侵者通过各种组件存在的缓冲区溢出漏洞，精心构造指令代码使得一个网页成为“潘多拉魔盒”，只要你打开它，你的世界将永无宁日。
为了不让网页的显示出现异常，入侵者通常沿用早期网页木马的隐秘加载形式——浏览器子框架IFRAME实现木马页面的读取，入侵者首先通过各种手段入侵一个网站（如社会工程学、SQL注入、服务器漏洞等），然后修改这个网站中访问量相对较多的网页文件（例如首页或各个网页必须调用的网页头部框架等），在里面加入一个高和宽均为“0”的IFRAME元素代码，内容指向入侵者在自己拥有的网络空间里放置的带毒网页文件，这个步骤就是“挂马”（为了确保自己的木马文件和带毒页面不被删除或供人随便就能研究，入侵者很少会直接将这两个文件一起放入受害网站的服务器上），在这以后，当用户访问这个被入侵者做过手脚的网页时，他实际已经访问了两个网页：原本浏览的网页、以及入侵者放置的带毒页面。带毒页面一经加载则启动相应的浏览器ActiveX组件，并将入侵者构造的参数读取执行，最终，用户会面临两种结局，一种是由于用户没有安装相应功能程序导致组件不存在或组件版本已经经过漏洞更新，从而导致浏览器无任何异常或者发生崩溃（溢出失败最常见的后果：组件崩溃导致浏览器异常退出的“拒绝服务”），在这时候用户是丝毫不知道自己刚躲过一劫的；而另一种则是比较符合国情的后果，即所有可令用户遭遇入侵的漏洞条件均存在，漏洞代码得以执行，导致用户浏览器下载执行了一个恶魔程序，最后恶魔可能被用户系统中的安全工具检测并消灭，也可能就此安居并将安全工具设为傀儡，从此用户上网将毫无防范——当然，这一切，用户都是毫不知情的。
其实，早在RealPlayer引发大面积的木马事件之前，国内就有好几个程序出了类似漏洞，例如国内下载新秀“迅雷”以及它的附属产品“迅雷看看”，都分别出现过参数检查不严导致溢出而带来的任意代码执行漏洞，但是随着RealPlayer漏洞创下的一次大面积撒网事件，第三方厂商的插件漏洞才开始被更多人注意并研究，到目前为止，国内已知的第三方插件漏洞几乎覆盖了大部分厂商，分别是PPStream PowerPlayer.DLL ActiveX 控件栈溢出漏洞、联众ConnectAndEnterRoom ActiveX控件栈溢出漏洞、超星阅览器Pdg2 ActiveX控件栈溢出漏洞、迅雷ActiveX控件DownURL2方式远程缓冲区溢出漏洞、Web迅雷ThunderServer.webThunder.1控件任意文件下载漏洞、百度超级搜霸BaiduBar.dll ActiveX控件远程代码执行漏洞、Qvod Player 2.0控件任意文件下载漏洞等，这一切，都让用户防不胜防。
这些漏洞的共同点都是依赖于用户机器的浏览器加载存在漏洞的组件来实现下载木马本体执行的功能，在相关厂商未出有效的安全更新之前，我们能做的只有通过某种手段预防漏洞危害，那就是利用浏览器自身提供的一个小功能将发生问题的控件暂时屏蔽。细心的用户在阅读一些安全小组的漏洞分析报告时，经常会看到这么一句：“在软件厂商未发布安全补丁之前，我们建议用户对该控件设置Killbit”。那么，什么是“Killbit”？微软编号Q240797的知识库文章《如何禁止 ActiveX 控件在 Internet Explorer 中运行》一文对此做出了诠释：Internet Explorer 有一项安全功能，可用于禁止 Internet Explorer HTML 呈现引擎加载某个 ActiveX 控件。此功能可通过进行注册表设置来完成，这种设置叫做设置“killbit”。一旦设置了“killbit”，该控件即永远不可加载，即使将其完全安装也是如此。此设置可以确保，即使有漏洞的组件被引入或重新引入系统中，它也不具活性，没有破坏力。
实际上，这一设置的本质是将存在漏洞的控件在浏览器里的兼容性标识设置为“不安全”，于是在预先设定的浏览器加载逻辑里，这一“不安全”的控件就不会被加载，从而保证浏览器不会携带着这个问题控件运行，其相关漏洞自然也就没有了入口。
兼容性标识位于系统注册表的HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\下，其子键为各个ActiveX控件的CLSID（有关CLSID概念请参见本文上半部分），每个CLSID项里都有一个名为“Compatibility Flags”的DWORD类型值，当它的值为“0x00000400”即十六进制400或十进制1024时，浏览器就会认为这个控件不安全而将其忽略，同时微软还提供了“兼容的安全CLSID替代”功能，用于在对某个问题控件使用Killbit后指定的另一个功能替代控件，它是通过用户建立一个名为“AlternateCLSID”的字符串实现的，其内容为功能替代控件的CLSID。
只是，要让一般用户来操作这些东西，实在有种赶鸭子上架的感觉，你不能指望一个对Word操作都有点陌生的用户立即去理解注册表，去理解漏洞原因，所以，这是一种无奈的避难手段。
2008年，或许将会是个“浏览器插件漏洞年”。

三. 系统漏洞凑热闹：挂马王“MS06-014”与“MS07-017”
当MIME头部解析漏洞基本销声匿迹后，入侵者除了通过第三方插件引发浏览器漏洞以外，还能利用系统漏洞进行入侵吗？答案是肯定的，虽然系统漏洞大家都“补”上了，但是总会有一些意外特例存在，例如真正存在漏洞的文件并未被更新或者在某种条件下被旧版本恢复，这时候即使所有的安全报告都显示它是“打过补丁”的，但是它仍然引发了理应已经补上的漏洞，如大名鼎鼎的系统漏洞“MS06-014”，虽然微软早已发布安全更新，可是仍然有一部分用户遭其毒手，所以在国内，它又被称为“挂马王”。
2006年4月11日，微软发布了一个等级标记为“严重”的安全更新，代号为“MS06-014”，它的描述为“MS06-014：MDAC功能存在可能允许执行代码的漏洞”，这个漏洞实际上由至少3种系统组件配合引发，首先是被大量应用于Web2.0交互的核心AJAX技术所需的HTTP数据请求组件“Microsoft.XMLHTTP”，它被入侵者设置为获取一个网络空间上放置的恶意木马程序；接下来，本次漏洞的主角“Adodb.Stream”出场，它将XMLHTTP组件获取的数据写入用户的系统中，这两个组件的搭配完成了一次恶意程序的下载过程；最终，入侵者构造一个“Shell.Application”组件将下载完成的恶意程序执行，就完成了这个漏洞的所有步骤。
虽然厂商及时发布了补丁，但是或许是因为MDAC这个数据库操作组件的环境依赖性质，一部分用户的组件实际上并未成功修补，从而埋下了一个隐患，当用户浏览到某个被植入这个漏洞触发代码的网站时，邪恶的代码就在后台悄悄下载执行了。
//文章出处:网络技术论坛(http://bbs.nettf.net) 作者:小金
而另一个，则是相对出名的“MS07-017”漏洞，官方定义名称为“Microsoft Windows动画光标畸形ANI头结构远程栈溢出漏洞”，也就是俗称的“ANI漏洞”，它刚问世的时候就引发了一场轰动，因为它是以“0day”的方式出现的。
许多用户对“动画光标”的概念不太清晰，其实你可以简单的将它理解为动画形式的鼠标指针——点击“开始”、“运行”，输入“cursors”回车，如果你在配置Windows组件时选择了“动画光标”，那么这里就会看到一些类似图标的文件，在任意一个文件上单击右键查看属性，你会发现它的文件类型描述为“动态光标”，后缀名是“.ani”——这就是“ANI漏洞”称呼的由来。
这次的漏洞根源是由于厂商考虑不周，导致系统在渲染畸形的光标、动画光标文件或图标时没有正确验证文件头部中所指定的文件大小，从而导致数据缓冲区溢出导致执行任意指令，入侵者最常见的手段就是构造一个特殊的动态光标格式文件，并在它的相应位置放置执行代码，然后编写一个用于加载这个光标文件的网页，当用户访问到这样的页面时，加载光标的CSS样式表行为CURSOR被触发，从而导致恶意代码被执行，这可以被称为“类似一句话木马”，因为它只需要一个漏洞文件和相应样式表代码便能执行入侵者的指令，如下载远程文件执行等。

四. 逃避查杀的技术：加密加密再加密
毫无疑问，在现在各大反病毒产品和安全工具围堵拦截的形势下，直接傻乎乎的将自己的恶意代码以原本的明文形式呈现出来是初学者的做法，这样的后果通常只有一个：被安全工具检测并查杀。
于是现在流行的恶意代码大都经过了一种被称为“加密”的手段进行处理，由于浏览器交互脚本的“弱语言”特征，入侵者可以将一句指令代码任意书写，而最终它依然能被脚本解释器正常执行，例如“clsid:BD96C556-65A3-11D0-983A-00C04FC29E36”可以拆开写为“clsid:BD”+“96C556-”+“65A3-11D0-983A-00”+“C04FC29E36”，最终结合起来，它仍然能被脚本解释器所理解，但是安全厂商载入浏览器中用于监视文件中敏感字符的恶意代码检测组件就叫苦了，它可不认识这种拆来拆去的东西最终表达了什么东西，而且它的功能也不包含有类似脚本解释器一样的执行功能，最终它就将这段恶意代码视为无物而放行了。
后来随着技术发展，检测组件开始具备敏感字符检测与代码组合分析的功能，于是新的加密手法再次出现，通过一种特殊的脚本指令“eval”，入侵者可以将一段代码改头换面写成风牛马不相及的内容，最终在多次奇妙的eval指令配合解密代码的工作后，它又神奇的被解释执行了，依旧留下那摸不着头脑的检测组件在一旁晾鱼干，即使有安全厂商专门编写了一套用于中介性质的脚本解释接口也无济于事。
但是我们没法去责怪安全厂商，如果要彻底杜绝这些问题，那还不如让安全厂商自己写一套完整的脚本解释器算了，但这样是非常不现实的。
我们只能祈祷，系统漏洞越少越好、工具漏洞越少越好……

五. 结语：防御——难以言说的话题
面对如此浩瀚网海，普通网民根本无法得知下一次漏洞将会出现在哪个组件身上，所以，它是防不胜防的，我们只能寄希望于一些相对强大的安全工具，如360安全卫士、安全巡警等，它们都提供了较齐全的系统漏洞更新检测与第三方工具漏洞更新功能，高级用户可通过使用微点主动安全防御、SSM等HIPS工具加以抵挡，结合反病毒产品的运作，力求将漏洞危害降到最低限度。
在这样的网络中，我们别无选择。