一个EXE引发的危机
——浏览器劫持实战篇
作者:小金
转载请注明出处和作者
网络程序员小李最近有点忙,公司要做的网页工程项目已经快到尾期了,可是开发小组的进度仍然迟迟跟不上来,为了赶进度,小李去国外下了一些代码回来参考,但那些代码的关键部分都是用了字符编码的形式加密的,小李不想手工一段段的解码,就上网搜索了一个号称能解码脚本字符编码的工具,下载回来的是一个安装包,文件名为“downsoft226.exe”,小李要急着用,看也没看就双击执行了,但是他等了好一会儿也没见安装界面出现,反而感觉到硬盘在狂转,机器奇慢,小李有些不安的打开了任务管理器——列表里赫然有至少超过50个进程在后台执行!
小李赶快手忙脚乱的停止进程,可是仍然有新的进程不断的出现,在他停掉downsoft226.exe这个进程后,系统蓝屏了,计算机重启后跳出好几个IE窗口,每个窗口上都多了一些工具栏,而且更严重的是,IE的空白页也不再空白了。小李只觉得天昏地暗:完了,恶狼又找上门来了……
以上的经历大概许多用户都会遇到,在网络上看到个工具的说明很好,就下载了运行,结果运气好的在得到工具的同时还“获赠”了一堆所谓的“IE助手”(BHO),运气差的不但工具没得到,还引狼入室给自己惹来一身臊。在这个信任危机的网络时代,你的浏览器随时会被“劫匪”给绑了去。
由于“浏览器劫持”的攻击手段是可以通过被系统认可的“合法途径”来进行的,以目前的软件行为检测技术来说,“浏览器劫持”是防不胜防的,即使你每天都很小心的设置安全级别、对浏览器弹出的安装插件提示看了又看,你仍然不可避免会因为下载安装了一些工具而让“劫持者”登堂入室。如果我们不小心让这头恶狼驻扎了进来,该用什么方法驱逐它呢?
除了BHO劫持以外,如今的劫持方式更有通过DLL插件、Hook技术和Winsock LSP进行的,而这些矛头纷纷指向浏览器的小坏蛋们,都会被传统的反病毒软件视为正常的,因为除了恶意软件,还有许多正常软件需要采用这些技术来为IE提供许多功能,因此出现了“鱼与熊掌”的尴尬局面,要更改这个已经定型的环境固然不现实,那么,要想在这个危机重重的环境下保全自己,我们就必须掌握一套“除狼”的技术了。
虽然一部分BHO是衷心为IE效力的,可是也总有那么一小嘬捣乱分子以简单的理由(增强浏览器特性、保护浏览器安全、上网记录清理等等等等……)让用户放心的执行了安装程序,然后再以复杂的理由(卸载不彻底、不提供卸载、表面上“卸载”等等等等……)死活赶不走了,如果遇到这样的无赖,用户该怎么办呢?
首先,要确认一下它的驻留地,一般情况下,BHO文件都在Windows目录下的“Downloaded Program Files”目录下,记住永远不要用资源管理器进去,它们会骗人的,我们必须用最原始的命令提示符(CMD.EXE)进去,只需要这几个命令:
你就会发现命令提示符和Windows资源管理器的巨大差异,如果实在用不惯命令提示符也没关系,有很多工具可以不偏袒任何一方的显示出最真实的情况,例如Total Commander这款强大的文件管理工具。但是这里并不是唯一的BHO目录,一些BHO会把自己放在系统根目录下的“Program Files”目录里,并且建立有自身所属的文件管理目录。
既 然看到这么多BHO的文件实体了,那么哪个才是赶不走的“助手”呢?既然它一开始就不打算让你卸载的,那么自然不会告诉你它一共有多少个文件、文件名是什 么、分布的目录等关系到自身生死大事的敏感信息,这就意味着对于计算机不熟练的用户来说,要驱逐它们并非那么容易,但是大部分设计者都会被一种“自我”的 心理暗示,因此设计出的程序文件一般都会注明版权信息,文件名也会包含有厂商的缩写或者该工具的英文缩写等特征字符,有了这些因素存在,用户要自己寻找这些不受欢迎的客人就好办多了,一个典型的例子是“中文实名网址”这款工具, 它的大部分文件均包含有产品英文缩写“CDN”,而且每个程序文件都在版权信息里清楚的写着“中文实名”,因此用户只要查找包含有“CDN”字符的文件名 就能发现个大概了,不过由于系统自身也可能会有几个文件名带有“CDN”字符,所以删除之前请先确认该文件的版权并非Microsoft所属。
一些用户也许会疑惑,为什么有些文件要删除的时候总会提示“文件正在被使用,无法删除”,这是因为BHO有一定的特殊性:它是可以被Windows的 外壳进程加载的,也就是那个Explorer,只要你进了系统,只要你的桌面和窗口还在,那么你就别想删除它了。要解决这个问题,我们先要尝试用 REGSVR32.EXE程序来去除它的组件注册信息,例如反注册HBClient.dll,只需要用命令提示符进入文件的目录里,执行 REGSVR32.EXE /U HBClient.dll即可,然后打开任务管理器taskmgr.exe,找到Explorer.exe进程停掉,最后直接在任务管理器里执行 CMD.EXE,进入文件目录后输入DEL HBClient.dll就完成了该文件的清理工作。如果这个BHO组件位于Program Files目录下的某一子目录里,你还可以放心的直接执行DEL *.*命令一窝端掉。
随着时间的流逝和技术的进步,许多BHO已经不再简单,有的BHO不仅使用BHO技术劫持浏览器,还加上了Hook技术、LSP劫持甚至采用了类似于Rootkit后门的保护技术最大限度的保全自己,要对付这些越来越狡猾的劫持者,仅仅用上面的方法大概是远远不够的。
幸运的是,现在已经出现了一批针对“浏览器劫持”的优秀工具,如列出所有浏览器环境组件的HijackThis、直接清理大部分常见恶意软件的RogueCleaner和直接屏蔽IE安装恶意软件功能的Upiea等,许多需要手工清理的恶意软件都可以通过它们配合完成,事半功倍。
“浏 览器劫持”的另一个显著特征就是篡改IE首页,首先,恶意软件把IE首页改为它要带用户去浏览的网址,如某个广告页、带毒页等,即使用户自己把首页设置为 “about:blank”(空白页),再打开IE仍然会发现浏览器在地址为“about:blank”的情况下自己跳转到了那个恶意页面,这就是经常搞 得一批用户人心惶惶最后不得不重装系统的“IE空白页劫持”事件,如果不慎被这种恶意软件纠缠上了该怎么办呢?
首先,我们要理解“空白页劫持”的机制,它一般通过两种方法进行,第一种是利用BHO技术进行劫持的,恶意程序员编写了一个能检测当 前IE地址的BHO组件,如果该组件截获到地址为“about:blank”,则触发跳转代码,控制浏览器访问该组件内置的地址去;另一种是利用了 IURLSearchHook技术实现的内部跳转,IURLSearchHook被浏览器用来转换一个未知的URL协议地址,当浏览器企图去打开一个未知 协议的URL地址时,浏览器首先尝试从这个地址得到当前的协议,如果不成功,浏览器将寻找系统里所有注册为“URL Search Hook”(资源搜索钩子,USH)的对象并把这个IE不能理解的地址发送过去,如果某个USH对象“认识”这个地址,它就返回一个特定的标识告诉IE它 知道怎么打开这个地址,然后IE就根据约定的方法调用它,最终打开这个地址。
这样描述也许很模糊,举个例子就好理解了,例如,当用户输入一个不带 协议标记的资源地址时(资源定位协议规定标准格式为协议标记://资源所在地址/目录/文件名),浏览器自身并不认识它的,所以它会枚举所有在系统注册的 USH对象,并把资源请求逐条传递过去,如果某一个USH“认识”该资源特征,则告诉浏览器它认识这个请求,浏览器就会加载它最终打开目标连接。通常,默 认的协议标记被指定为“http”,它是属于urlmon.dll负责的,而“about”协议被用于本地信息输出调试和扩展功能的实现(大家可以尝试在 浏览器里输入about:小金@网络技术论坛 看看效果),如果有个恶意的USH对象把“about”协议的解释权抢了过来,用户指定的空白页自然就会被带到某个不知名的地方去了。
对 于BHO造成的页面劫持,只要用清理BHO的方法去查找就可以了,而如果是被USH劫持,那么找起来会有点困难,由于USH对象并不像BHO组件会在前台 出现蛛丝马迹,对一般用户而言会造成搜索困难,其实只要你理解了我在上文对USH机制的解释,要找到它们就不困难了,一些USH对象实施的是本地跳转,所 以产生的页面会带有到自身文件的连接,用户只需查看页面源代码,然后搜索到“res://”开头的那个HTML元素,后面那一连串百分号和字符就是该 USH的完整文件地址,它们是用Unicode编码过的,不要看到那一堆类似加密的字符串就退却了,既然浏览器能认识,那么我们也就能让它显示出来,只需 要在IE浏览器的地址栏里输入这么一句脚本代码:“javascript:document.write(unescape('被Unicode编码的字 符串'));”,浏览器就把它还原回可读字符串了,记下这个文件名去查找删除掉,“空白页劫持”就不复存在了,例如一个字符串为“'%62%62%73% 2E%6E%65%74%74%66%2E%6E%65%74”,只需要在浏览器地址栏里输入“javascript:document.write (unescape('%62%62%73%2E%6E%65%74%74%66%2E%6E%65%74'));”,就可以知道它表示什么了,各位可以 去试验一下亲自看看效果。
如果是另一种稍微狡猾点的没有使用本地跳转代码的USH对象,以上方法就行不通了,但是我们也不用怕,由于Windows的 注册表管理机制,任何USH对象都必须通过注册表项目来加载,因此只要运行REGEDIT,定位到以下注册表键:HKEY_CURRENT_USER/ Software/Microsoft/Internet Explorer/URLSearchHooks,里面列出的项目就是可能被添加的USH入口,只要删除掉即可解除“空白页劫持”危机。
有 时候,即使我们清理了恶意劫持,一重启机器,却发现它又回来了,或者由劫持带来的开机自弹广告恶意页面还是依旧出现,这是为什么呢?因为在注册表中,并不 是只有与IE有关的地方才会被流氓软件改写的,另一处最常见的加载入口——启动项也常常被它们光临,恶意软件还会篡改这三个启动项目 “HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/Run”、“HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/Run”和“HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/RunServices”,更高级的方法是建立“HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/policies/Explorer/Run”项,然后从这里启动自身,由于系统配置实用程序并不会检测这个地方,所以常被一些新型后门钻了空子。
如何快速筛选正常启动项和恶意启动项一直是普通用户最头痛的问题,俗话说“不打没有准备的仗”,平时我们必须记住系统常有的启动项,到时候就能迅速发现新增加的项目列表了,一般来说,最干净的系统启动项只有两个,甚至只有一个:
对于XP/2003,默认情况下可能会有一些IME开头的启动项,但是这些项目完全可以删除掉。除了这几个项目,剩下的就是根据各人安装程序和设备时产生的相应管理启动项了,所以只能靠各用户平时的观察和记录来判断了,但是通常情况下,莫名其妙出现在Windows系统目录或者以一些Windows系 统文件来命名的启动项90%不是什么好东西(如果你安装了涉及系统管理的程序组件除外)!例如svchost.exe、C:/WINDOWS/ SYSTEM32/CApp.exe等,还有一些DLL类型的Hook组件靠Rundll32.exe进行自启动,例如某著名厂商的某某BHO就是这么做 的,如果这里没能清理干净,那么下次启动的时候,你刚才辛苦清理的流氓们就又复活了。
LSP全称为“Windows Socket Layered Service Provider”(分层服务提供商),这是Winsock 2.0才有的功能,它需要Winsock支持服务提供商接口(Service Provider Interface,SPI)才能实现,SPI是一种不能独立工作的技术,它依赖于系统商已经存在的基本协议提供商,如TCP/IP协议等,在这些协议上 派分出的子协议即为“分层协议”,如SSL等,它们必须通过一定的接口函数调用,LSP就是这些协议的接口。
近年来采用LSP技术进行浏览器劫持 的恶意软件也慢慢浮出水面了,使用LSP的好处在于,这类浏览器劫持方案可以不分浏览器“种族”的进行,即使你不用IE,你的Opera、NC、 Firefox等非IE内核的浏览器也难逃厄运,因为LSP是直接从Winsock获取信息的,而所有浏览器最终的数据传输都必须建立在Winsock接口上,所以一旦LSP层被恶意劫持,用户的所有请求都有可能被控制了。
LSP 服务接口位于注册表的“HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/WinSock2 /Parameters/NameSpace_Catalog5/Catalog_Entries”项目内,所有接口都通过一串长数字项表示。普通情况 下,系统就已经带有了两个LSP接口分别负责TCP/IP组件(rnr20.dll)和NTDS组件(winrnr.dll)的正常工作,而LSP劫持则 是把自己加入该项目内,并把优先权提高(用长数字项表示),例如默认情况下TCP/IP组件的优先权为000000000001,如果发生了LSP劫持, 恶意LSP可能会把自身改为000000000001,而系统原有的LSP项目就被往后推为000000000002等,以便数据包轮寻的时候能优先被恶意LSP处理。
要清理LSP劫持不能简简单单的直接把鼠标往“NameSpace_Catalog5”项目上点“删除”完事,这样做以后你就会发现系统也不能使用任何网络功能了,因为系统自身也必须依赖两个内置的LSP进行工作,这种架构看起来的确很麻烦,但是如果微软连自己提出的技术自己都不去使用的话,还指望别人会用?
所以,正确的清理步骤必须这样进行:
确认LSP劫持已经发生,可以通过手工检查上文提到的注册表键值判断,或者使用HijackThis做一次全面扫描。
查找并删除LSP驱动文件,可直接通过相应LSP项目的“LibraryPath”子项得到。
删除相应的LSP组件项目,它是用一长串数字表示的。
重命名正常的LSP组件项目,TCP/IP为000000000001,NTDS为000000000002,如果还有其他的话,依次排序。
重启计算机,再用HijackThis扫描一下恶意LSP是否已经彻底清理掉。
本 来已经不想说这个恶心的东西了,看看“驱动”两个字,你想起了什么?没错,这是Rootkit的代名词!这个东西原本就不属于浏览器劫持范畴的,可是自从 一些厂商和个人首次采用并尝到“甜头”后,这股风气逐渐蔓延开来,我不得不暗自庆幸如今能真正写出好用的Rootkit的人还没那么多,否则以后一般用户 的日子更不好过了,这类劫持通常不做主要工作,它只负责隐藏恶意BHO文件、启动项和进程信息等,这样即使我们用上面的几个方法清理了流氓软件,几秒钟后 它就又回来了,或者直接就不给你删除文件!既然为了损害用户利益把劫持技术研究到这种地步了,为何不去做正事呢?
要清理这类劫持并非HijackThis和其他同类软件 能做到的了,手工查找也比较困难,这时候我们必须请出IceSword了,主要关心的位置是“进程”和“SSDT”(顺便提一下,IceSword也能看 系统当前注册的BHO信息),注意找被IceSword标注为红色的项目,它们就是罪魁祸首,对于进程列表里的红色进程,先尝试用“结束进程”停止掉该进 程运行,然后看看它还会不会“复活”,我不推荐用户直接删除红色进程的文件,因为它们有可能是被Rootkit借来驻留的进程载体,随便删除容易导致系统 出错。
确认没有红色进程后,我们来看“SSDT”,SSDT意为“系统服务描述表”,里面存放着最底层的接口函数,Rootkit要实现各种隐藏 都要修改这个地方实现对系统底层函数的控制和转移,正常情况下SSDT的函数都是从ntoskrnl.exe导出的,如果有Rootkit控制了部分函 数,在IceSword里就会表示为红色的,并且指出该函数被哪个文件掳走了(一些杀毒软件为了查杀Rootkit,也会在这里留下自己的痕迹,如卡巴斯 基的klif.sys等,检查的时候要注意看文件版权信息以免误杀),我们先要记下该文件名,然后进入注册表的“HKEY_LOCAL_MACHINE/ SYSTEM/CurrentControlSet/Services”里查找该文件并删除对应的子项名称,重新启动计算机后再用IceSword检查, 如果没有再出现红色,那么恭喜一下,这场反劫持战争我们终于胜利了!
也许是因为浏览器的访问直接代表着利益关系,所以越来越多人把眼光投向浏览器,使用户替代他们完成诸如访问流量、广告点击等工作,不知道继“网络钓鱼”、“浏览器劫持”以后,广大的网络用户明天又该会面对什么样的危机?
浏览器的战争,会有休止的那一天吗?