收复失地
刚刚准备在浏览器上输入他网站的地址，结果却停了下来：如果入侵者在首页挂了马，我岂不是也要遭殃？所以我先用查看挂马的工具检查了一下。没有不可见窗 体、没有JS调用、没有Object，OK。进了首页看到上面只有入侵者的名字和一些图片，网站里边的具体情况待会再看吧。向朋友要了管理员的密码，用 3389登录上去一探究竟。
先看看服务器用户的情况，输入“net user”后发现“tsinternetuser”这个用户比较显眼。
依稀记得tsinternetuser是Windows2000的终端用户，但在Windows2003中并不存在。怕不肯定，我去百度查询了一下，又问 了问朋友，都说不应该有这个用户。看来这次入侵者弄巧成拙了，当我检查管理员组后，发现并不存在此用户，初步猜测它应该是克隆出来的。先打开 Regedt32将自己的权限提上去：打开Regedit，来到“HKEY_LOCAL_MACHINE\SAM\SAM\Domains\ account\”，对比管理员和“tsinternetuser”中二进制键F的数值，结果发现是一样的。由此断定用户 “tsinternetuser”被克隆成管理员。接着检查其他用户，没有发现被克隆的痕迹。删除“tsinternetuser”，不过事情到这里并没 完。
检查后门
祭出“冰刃”，它可是后门的克星，大部分的妖魔鬼怪在它面前都会无所遁形。
先用冰刃查看进程，发现并没有隐藏进程（红色标示）。再查看端口，发现1066端口在监听。
此端口不是常用端口且启动它的程序也不常见。
在进程选项中查看“systemram.exe”，发现此进程还有个芯片图标，
难怪刚才没注意到。先把他结束掉，但别着急删除。我们先看看启动组是否正常，看了一下没什么问题。
但在查看服务时发现了一个熟悉的身影：Radmin。
程序本身也正好是监听1066端口的程序。这下好办了，删除程序、卸载服务。
Radmin还是很好清除的（在网上搜索，发现这是百世经纶修改版 Radmin，难怪没有发现admdll.exe和raddrv.dll。
但它在服务方面就做得太差了，让人一看就能知道是后门服务）。
重整河山
检查了半天没有发现别的后门，这个入侵者一点技术含量都没有。接下来该恢复网站了。
浏览了一下网站，发现许多页面被改的面目全非。我从备份文件中把网站恢复了一下，这样总算能正常访问了。
接下来的任务就是把网站的漏洞补上，因为不知道入侵者是怎么进来的，还要全面的检查一次。
翻出N多工具狂轰滥炸一番，没有明显的漏洞，又手工检查了一些“偏僻”的地方，也没找到漏洞。
入侵者到底是怎么进来的呢？旁注？不可能，网站采用的是独立服务器。
突然想到可以检查入侵者留下的WebShell位置，以判断他的入侵位置。将lake2写的查找ASP木马的工具传上去。
此工具很好用，他查找的特征码是那些危险组件和函数。
WebShell的位置在动网论坛目录里，基本上确定它是从这里进来的。可是我刚才测试时发现提权漏洞已经补上了。
再检查一下论坛也没发现跨站的代码，到底他是怎么进来的呢？难道是故意把WebShell放在论坛目录下？
向朋友询问了论坛管理员的密码……很弱智，并且前后台还都一样。有心的人猜几次就知道了，
看来安全问题大多数都是人本身的问题，最后我让朋友把密码改得强壮些。基本上“失地”已经收回了，现在该追击敌人了。
日志寻踪
做坏事就要付出代价，现在我就来捉住你。打开“事件查看器”，很不幸地发现所有日志都被清空，
IIS日志里只有我朋友和我的访问记录。我早就提醒过朋友要把日志的保存路径改一下，最好是安装专门的软件监控，可惜他就是不听。
小知识：修改日志存放位置的方法：
Windows的系统日志文件有应用程序日志，安全日志、系统日志、DNS服务器日志。应用程序日志、安全日志、系统日志、DNS日志默认位置：
%systemroot%\system32\config，默认文件大小512KB。
安全日志文件：%systemroot%\system32\config\SecEvent.EVT
系统日志文件：%systemroot%\system32\config\SysEvent.EVT
应用程序日志文件：%systemroot%\system32\config\AppEvent.EVT
DNS日志：%SystemRoot%\system32\config\DnsEvent.EVT
修改Windows系统日志的存放位置要在注册表中修改。打开注册表，
找到“HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\Eventlog”，
此目录下的分支分别对应不同的日志，每个目录中的“file“键是日志的存放位置，修改它就可以了。
修改IIS日志保存位置：打开Internet信息服务（IIS）管理器，找到你的网站查看它的属性，选择日志旁边的属性，在这里就可以更改.“高级”选项还可以选择日志记录的信息种类。IIS日志也可以保存到数据库中。
看来入侵者还是有点“安全”意识的，这可让我犯难了，上哪去找他呀？就在我快要放弃的时候，
看到了入侵者留下的WebShell。查看他的密码（有人喜欢用自己的QQ号作为WebShell密码，我就遇到过几个这样的），
可惜没有得到我想要的资料。不过这倒让我想起了他是从动网入侵的，那么在动网的数据库里应该有记录才是。打开动网数据库，
翻看DV_LOG表，里面的记录入侵者可能忘记删除了。从这里确定了他的入侵方法：上传文件再备份成ASP，更令人高兴的是得到了他的IP。
韩城攻略
搜索了一下这个IP，发现竟然是韩国的主机。
先用端口扫描，发现主机开了21、1433、3389这几个端口。
没有开80端口，看来通过网站渗透进去是不可能了，重点放在1433端口。用MSSQL溢出测试，结果没有成功。
只能寄希望于弱口令上了。我比较喜欢用HSCAN。命令格式：“HSCAN -h ip -mssql –ftp”。
果然有一个SA空口令。用SQLTools连接成功，执行命令时发现xplog70.dll被删除了。
翻了半天硬盘也没找到xplog70.dll，问了几个朋友也说没有。看来只能用别的扩展组件执行命令了。
用SQL查询分析器连接目标主机时出现了奇怪的现象，连接成功后程序自动关闭，从网上又下载了一个也是这样，
输入错误的密码还会提示密码错误，真搞不懂是怎么回事。正当我不知所措的时候，朋友扔过来一个 SQLRootkit 。
在程序界面里添上IP，用户名和密码，点击登录后就连接成功。SqlRootkit利用四种组件来执行系统命令，
在执行前还可以先检测一下组件，并且它还具有恢复的功能。当然前提是支持组件的文件要存在，
如xplog70.dll、odsole70.dll和xpstar.dll。我们先看看组件是否存在。
xp_cmdshell缺少文件不能用、sp_oraceate显示执行成功但主机没有执行命令、xp_regwrite执行命令超时、
xp_servicecontrol执行命令虽然没有回显，但却是唯一能执行成功的。
远程登录主机，打开事件查看器，发现日志没有被删除。用动网数据库中记录的入侵时间比对了一下安全中的用户登录日志，
找到了入侵者的IP。从“C:\ Documents and Settings”目录下找到了入侵者浏览网站的历史记录，这下证据确凿，
他跑不了了（日志的图片就不给大家看了，见谅）。查看入侵者的IP得知是上海的 ADSL。临走时在CMD下执行了：“quser”，
看到管理员也在线，并且发现了这台主机已经在线三百天了。
我还没见过在线时间这么长的Windows主机，难怪入侵者那么嚣张。把入侵者的IP和相关的证据交给了朋友把并过程告诉了他，
后面的事情就随他了。
总结这次反入侵过程，基本上没碰到难处，可以说一气呵成。也没有什么新技术，都是大家知道的，就是把它们都组合起来而已。
感觉防护比入侵难多了，要从各个方面做好防护。在这里奉劝那些“黑客”，我们去入侵是印证自己的技术，不是用来搞破坏的。
追根溯源 DLL木马进程内幕大揭密
如果是位经常玩木马的朋友，那么一般情况下都会或多或少掌握一些木马的特性，然而，很多朋友还是不知道“DLL木马”是什么东东。那到底什么是“DLL木马”呢?它与一般的木马又有什么不同?带着这些疑问，一起开始这次揭密之旅吧!
一、追根溯源从DLL说起
要了解什么是“DLL木马”，就必须知道“DLL”是什么意思!说起DLL，就不能不涉及到久远的DOS时代。在DOS大行其道的时代，写程序 是一件繁琐的事情，因为每个程序的代码都是需要独立的，这时为了实现一个普通的功能，甚至都要为此编写很多代码。后来随着编程技术发展与进步，程序员们开 始把很多常用的代码集合(也就是通用代码)放进一个独立的文件里，并把这个文件称为“库”(Library)。在写程序的时候，把这个库文件加入编译器， 就能使用这个库包含的所有功能而不必自己再去写一大堆代码，这个技术被称为“静态链接”(Static Link)。静态链接技术让劳累的程序员松了口气，一切似乎都很美好。然而静态链接技术的最大缺陷就是极度消耗和浪费资源，当一个程序只想用到一个库文件 包含的某个图形效果时，系统将把这个库文件携带的所有的图形效果都加入程序，这样就使得程序非常臃肿。虽然这并不重要，可是这些臃肿的程序却把道路都阻塞 了——静态链接技术让最终的程序成了大块头，因为编译器把整个库文件都加载进去了。
技术永远是在发展的，静态链接技术由于无法避免的弊端，不能满足程序员和编程的需要，人们开始寻找一种更好的方法来解决代码重复的难题。随着 Windows系统的出现， Windows系统使用一种被称为“动态链接库”(Dynamic Link Library)的新技术，它同样也是使用库文件，DLL的名字就是这样来的。动态链接本身和静态链接没什么区别，也是把通用代码写进一些独立文件里，但 是在编译方面，微软把库文件做成已经编译好的程序文件，给它们开发一个交换数据的接口。程序员编写程序的时候，一旦要使用某个库文件的一个功能函数，系统 就把这个库文件调入内存，连接上这个程序占有的任务进程，然后执行程序要用的功能函数，并把结果返回给程序显示出来。完成需要的功能后，这个DLL停止运 行，整个调用过程结束。微软让这些库文件能被多个程序调用，实现了比较完美的共享，程序员无论要写什么程序，只要在代码里加入对相关DLL的调用声明就能 使用它的全部功能。这样，写出来的程序就不能再携带一大堆无用的垃圾了。
DLL技术的诞生，使编写程序变成一件简单的事情，Windows为我们提供了几千个函数接口，足以满足大多数程序员的需要。而 且，Windows系统自身就是由几千个DLL文件组成，这些DLL相互扶持，组成了庞大的Windows系统。如果Windows依然使用静态链接技 术，那将是不可想象的。
二、什么是API
在前面提到的“接口”又是什么呢?因为DLL不能像静态库文件那样塞进程序里，如何让程序知道实现功能的代码和文件成了问题，微软就为DLL技 术做了标准规范，为每个DLL文件都明确地标注好它的功能名称，程序只要根据标准规范找到相关的名称进行调用就行了，这就是 API(Application Programming Interface)应用程序接口，每个DLL带的接口都不尽相同，最大限度地减少了程序代码的重复。在Windows里，最基本的3个DLL文件是 kernel32.dll、user32.dll、gdi32.dll。它们共同构成了基本的系统框架。
三、DLL与木马
DLL是编译好的代码，与一般程序没什么大差别，只是它不能独立运行，需要程序调用。那么，DLL与木马能扯上什么关系呢?如果你学过编程并且 写过DLL，就会发现，其实DLL的代码和其他程序几乎没什么两样，仅仅是接口和启动模式不同，只要改动一下代码入口，DLL就变成一个独立的程序了。
当然，DLL文件是没有程序逻辑的，其实DLL并不等于EXE。不过，依然可以把DLL看做缺少了main入口的程序，DLL带的各个功能函数 可以看作一个程序的几个函数模块。DLL木马就是把一个实现了木马功能的代码，加上一些特殊代码写成DLL文件，导出相关的API，在别人看来，这只是一 个普通的DLL，但是这个DLL却携带了完整的木马功能，这就是DLL木马的概念。也许有人会问，既然同样的代码就可以实现木马功能，那么直接做程序就可 以，为什么还要多此一举写成DLL呢?这是为了隐藏，因为DLL运行时是直接挂在调用它的程序的进程里的，并不会另外产生进程，所以相对于传统EXE木马 来说，它很难被查到。
四、DLL的运行
虽然DLL不能自己运行，可是Windows在加载DLL的时候，需要一个入口函数，就如同EXE的main一样，否则系统无法引用DLL。所 以根据编写规范，Windows必须查找并执行DLL里的一个函数DllMain作为加载DLL的依据，这个函数不作为API导出，而是内部函数。 DllMain函数使DLL得以保留在内存里，有的DLL里面没有DllMain函数，可是依然能使用，这是因为Windows在找不到DllMain的 时候，会从其它运行库中找一个不做任何操作的缺省DllMain函数启动这个DLL使它能被载入，并不是说DLL可以放弃DllMain函数。
五、DLL木马技术分析
到了这里，大家也许会想，既然DLL木马有那么多好处，以后写木马都采用DLL方式不就好了吗?话虽然是这么说没错，但是编写DLL木马并不是一些人想象的那么容易写的。要写一个能用的DLL木马，需要了解更多关于操作系统底层的知识。
1.木马的主体
千万别把木马模块写得真的像个API库一样，这不是开发WINAPI。DLL木马可以导出几个辅助函数，但是必须有一个过程负责主要执行代码， 否则这个DLL只能是一堆零碎API函数，别提工作了。如果涉及一些通用代码，可以在DLL里写一些内部函数，供自己的代码使用，而不是把所有代码都开放 成接口，这样它自己本身都难调用了，更不可能发挥作用。
DLL木马的标准执行入口为DllMain，所以必须在DllMain里写好DLL木马运行的代码，或者指向DLL木马的执行模块。
2.动态嵌入技术
Windows中，每个进程都有自己的私有内存空间，别的进程是不允许对这个私人领地进行操作的，但是，实际上我们仍然可以利用种种方法进入并 操作进程的私有内存，这就是动态嵌入，它是将自己的代码嵌入正在运行的进程中的技术。动态嵌入有很多种，最常见的是钩子、API以及远程线程技术，现在的 大多数DLL木马都采用远程线程技术把自己挂在一个正常系统进程中。其实动态嵌入并不少见，罗技的MouseWare驱动就挂着每一个系统进程。远程线程 技术就是通过在另一个进程中创建远程线程(RemoteThread)的方法进入那个进程的内存地址空间。在DLL木马的范畴里，这个技术也叫做“注 入”，当载体在那个被注入的进程里创建了远程线程并命令它加载DLL时，木马就挂上去执行了，没有新进程产生，要想让木马停止惟有让挂接这个木马DLL的 进程退出运行。但是，很多时候我们只能束手无策——它和Explorer.exe挂在一起了。
3.木马的启动
也许您会有这样的想法，直接把这个DLL加入系统启动项目不就可以了?“NO”!前面已经介绍过，DLL不能独立运行，所以无法在启动项目里直 接启动它。要想让“马儿”顺利地跑起来，就需要一个EXE使用动态嵌入技术让DLL挂上其他正常进程，让被嵌入的进程调用这个DLL的DllMain函 数，激活木马运行，最后启动木马的EXE结束运行，木马启动完毕。启动DLL木马的EXE非常重要，它被称为加载(Loader)。所以，一个相对比较成 熟的DLL木马会想办法保护它的Loader不会那么容易被发现和毁灭。
Loader可以是多种多样的，Windows的rundll32.exe也被一些DLL木马用来做了Loader，这种木马一般不带动态嵌入 技术，它直接挂着rundll32进程运行，用rundll32的方法像调用API一样去引用这个DLL的启动函数激发木马模块开始执行，即使你杀了 rundll32，木马本体还是在的，一个最常见的例子就是3721中文实名，虽然它不是木马。
注册表的AppInit_DLLs键也被一些木马用来启动自己，如求职信病毒。利用注册表启动，就是让系统执行DllMain来达到启动木马的 目的。因为它是kernel调入的，对这个DLL的稳定性有很大要求，稍有错误就会导致系统崩溃，所以很少看到这种木马。有一些更复杂点的DLL木马通过 svchost.exe启动，这种DLL木马必须写成NT-Service，入口函数是ServiceMain，一般很少见，但是这种木马的隐蔽性也不 错，而且Loader有保障。
4.寥寥无几
到这里大家也应该对DLL木马有个了解了，是不是很想写一个?别急，不知道大家想过没有，既然DLL木马这么好，为什么到现在能找到的DLL木 马寥寥无几?现在让我来泼冷水，最重要的原因只有一个：由于DLL木马挂着系统进程运行，如果它本身写得不好，例如没有防止运行错误的代码或者没有严格规 范用户的输入，DLL就会很容易出错并崩溃。但是DLL崩溃会导致它挂着的程序跟着遭殃，别忘记它挂接的可是系统进程啊，结局就是……惨不忍睹。所以写一 个能公布的DLL木马，在排错检查方面做的工作要比一般的EXE木马多，甚至写得多了连编写者自己都会烦躁不已!
六、DLL木马的发现和查杀
经常看看启动项有没有多出莫名其妙的项目，这是Loader的所在。而DLL木马本体比较难发现，需要用户有一定编程知识和分析能力，在 Loader里查找DLL名称，或者从进程里看有没有挂接什么陌生的DLL!但是，对于一些计算机的初级用户来说，这样的发现过程是非常困难的!因此，最 简单的方法：杀毒软件和防火墙，这虽然不是万能的解决之道，但是对于不了解系统原理，没有编程经验的新手来说，总算是一种权宜之计吧!
揭秘图片病毒技术的内幕 被诅咒的油画
引言：图片病毒已经不是一个新鲜的话题， 随着病毒技术的发展，图片同样也是病毒的载体。
一、被病毒诅咒的油画
在网络上流传着一幅诡异的油画，据说很多人看后会产生幻觉，有人解释为油画的构图色彩导致的视觉刺激，也有人认为是心理作用，众说纷纭，却没有令人信 服的答案。在网络公司上班的秘书小王也从一个网友那里得知了这幅画，她马上迫不及待的点击了网友给的图片连接。图片出来了，小王终于见识到了传说中诡异的 油画，面对着屏幕上那两个看似正常的孩子，她却觉得背后凉飕飕的。那网友也很热心的和她聊这幅画的来源，小王入神的听着，丝毫没有注意到IE浏览器左下角 的状态栏打开页面的进度条一直没停止过。
图片仅供参考
如果说小王刚才只是背后发冷的话，那么现在她已经是全身发冷了：电脑光驱自动弹了出来，刚按回去又弹了出来，她着急的请教那个网友，那边很平静的说：“哦，也许是光驱坏了吧，我有事先下了，你找人修一下。”然后头像暗了。
小王已经无法回复他的话了：鼠标正在不听使唤的乱跑，键盘也没了反应，过了一会儿，电脑自己重启了，而且永远停留在了“NTLDRismissing...”的出错信息上。
显而易见，这又是一个典型的木马破坏事件，但是小王打开的是图片，难道图片也会传播病毒了？答案很简单也很出人意料：小王打开的根本不是图片。
IE浏览器的功能很强大，它可以自动识别并打开特定格式的文件而不用在乎它是什么文件后缀名，因为IE对文件内容的判断并不是基于后缀名的，而是基于 文件头部和MIME。当用户打开一个文件时，IE读取该文件的头部信息并在本机注册表数据库内查找它对应的MIME格式描述，例如打开一个MIDI文 件，IE先读取文件前面一段数据，根据MIDI文件的标准定义，它必须包含以“RIFF”开头的描述信息，根据这段标记，IE在注册表定位找到了“x- audio/midi”的MIME格式，然后IE确认它自己不具备打开这段数据的能力，所以它根据注册表里的文件后缀名信息找到某个已经注册为打开后缀名 为“.MID”的文件，然后提交给此程序执行，我们就看到了最终结果。
正是因为这个原理，所以IE很容易受伤。入侵者通过伪造一个MIME标记描述信息而使网页得以藏虫，在这里也是相同的道理，小王打开的实际上是一个后 缀名改为图片格式的HTML页面，它包含上述两个漏洞的病毒文件和一个高度和宽度都设置为100%的图片IMG标记，所以在小王看来，这只是一个图片文 件，然而，图片的背后却是恶毒的木马。木马程序体积都比较大，下载需要一定时间，这就是IE进度条一直没停止的原因。入侵者为了确保受害者打开页面的时间 可以使整个木马文件下载完毕，就采用了社会工程学，让受害者不会在很短的时间内关闭页面，当木马下载执行后，“图片”的诅咒就应验了。
二、位图特性的悲哀
他是一家公司的网络管理员，在服务器维护和安全设置方面有足够多的经验，因此他无需惧怕那些利用浏览器漏洞实现的病毒。这天他在一个技术论坛里看到一 个网友发的关于AMD某些型号的处理器存在运算瑕庇的帖子，并给出一个测试页面连接，根据官方描述，如果你用的CPU存在瑕庇，那么你会看到页面上的测试 图片显示得破损错乱。他心里一惊：自己用的CPU正是这个型号。他马上点击了页面连接。
看着页面上乱七八糟的一幅图片，他心里凉了一截：这台机器的CPU居然有问题，而他还要用这台机器处理公司的重要数据的！他马上去管理部找负责人协商，把显示着一幅胡里花哨图片的机器晾在一边。
管理部答应尽快给他更换一台机器，让他把硬盘转移过去，因为上面有重要的业务资料。他回来时看到那幅图片还在耀武扬威，他厌恶的关闭了页面，照例打开 存放资料的文件夹，他的脑袋一下子空白了：资料不见了！谁删除了？他慌乱的查找硬盘每个角落，可那些文件却像蒸发了一样。许久，他终于反应过来了：机器被 入侵了！他取下硬盘直奔数据恢复公司而去。
事后他仔细分析了原因，因为机器已经通过了严格的安全测试而且打了所有补丁，通过网页漏洞和溢出攻击是不可能的了，唯一值得怀疑的只有那个所谓的瑕庇 测试网页了，他迅速下载分析了整个页面代码，看着页面源代码里后缀名为“.BMP”的IMG标记和一堆复杂的脚本代码，他知道自己是栽在了BMP木马的手 上。
那幅“测试瑕庇”的图片，无论到什么机器上都是一样有“瑕庇”，因为它根本不是图片文件，而是一个以BMP格式文件头部开始的木马程序。
为什么看似温顺的图片文件也变成了害人的凶器？这要从位图（Bitmap）格式说起，许多朋友应该都知道流传了很久的被称为“图片藏字”的“密文”传 播方式，即在位图文件尾部追加一定量的数据而不会对原位图文件造成太大破坏，这是位图格式的限制宽松而造成的。系统判断一个位图文件的方法并不是严格盘 查，而是仅仅从文件头部的54字节里读取它的长宽、位数、文件大小、数据区长度就完成了图片的识别，宽松的盘查机制使得BMP木马得以诞生。 不过先要 澄清一点概念，BMP木马并不是在BMP位图文件屁股后追加的EXE文件，而是一个独立的EXE可执行文件，但是它的文件PE头部已经用位图文件头部替换 了，由于系统的盘查机制，这个EXE文件就被浏览器认成位图文件了。既然是位图，在浏览器的程序逻辑里，这是需要下载到Internet高速缓存文件夹然 后显示在页面上的文件，但是因为这个文件本来就不是位图，它被强制显示出来以后自然会变成一堆无意义的垃圾数据，在用户眼里，它就成了一幅乱七八糟的图 像。但这不是引起木马危机的原因，要留意的是这些文字：“需要下载到Internet高速缓存文件夹”！这说明浏览器已经请狼入室了——木马已经在硬盘上 安家了，但是目前它还在沉睡中，因为它的文件头部被改为位图格式，导致它自身已经不能运行，既然不能运行，理所当然就不能对系统构成危害，那么这只狼在硬 盘呆多久也是废物一个，入侵者当然不能任由它浪费，因此他们在做个页面给浏览器下载木马的同时，也会设置页面代码让浏览器帮忙脱去这只狼的外衣——把位图 格式头部换成可执行文件的PE头部，然后运行它。经过这些步骤，一只恶狼进驻了系统。
这个无法修补的漏洞十分可怕，用户很难知道他们正在浏览的页面是否正在偷偷下载着木马数据，因为即使他们打好了所有补丁也无济于事，木马是被IE“合 法”下载的，不属于代码漏洞，而且单靠程序本身也很难判断这个图像是不是木马程序，机器靠二进制完成处理工作，而不是视网膜成象交给大脑判断。但是，由于 这也是需要下载文件的入侵方式，它能否下载完毕以及用户愿不愿意去看页面就要取决于入侵者的社会工程学了，在任何一个页面里放出一个乱七八糟的图片或者来 一个隐藏的图片框都不是最明智的选择，除非利用一些“暇庇声明”或更能引起人的兴趣的伎俩。那家公司的网管之所以会这么不设防，就是因为攻击者偷用了人们 的“心理盲区”，因为人们对安全、漏洞、病毒、暇庇等内容会特别敏感，所以入侵者发个专业暇庇案例就欺骗了一大堆人，这次是拿真实的事件：AMD某些型号 CPU会导致图像显示出问题的暇庇来做鱼饵，下一次又该拿什么了呢？
三、病毒魔鬼的诅咒
对于某娱乐论坛的大部分用户来说，今天是个黑色的日子，因为他们在看过一个《被诅咒的眼睛》油画帖子后，系统遭到了不明原因的破坏。
论坛管理层的技术人员立即对这个帖子进行了多次分析，可是整个页面就只有一个JPEG图片的连接，其他恶意代码和程序根本不存在。入侵者靠什么破坏了看帖用户的机器？难道竟是这个JPEG图片？
答案恐怕让人难以接受，的确就是这幅JPEG图片让用户感染了病毒。尽管病毒研究一直未曾停止，可是发展到这个地步，实在让人不能承受：再下去是不是打开一个文本文件都会被感染病毒？
图片带毒来袭，实在让所有人都擦了一把汗，然而我们都知道，JPEG、GIF等格式图片不具备可以执行自身并散播病毒的条件，这不符合逻辑。回忆一下 2004年9月14日的事，微软发布了MS04-028安全公告：JPEG处理(GDI+)中的缓冲区溢出可能使代码得以执行。没错，就是这个漏洞，它的 术语叫GDI+，对应的动态链接库为GdiPlus.dll，这是一种图形设备接口，能够为应用程序和程序员提供二维媒介图形、映像和版式，大部分 Windows程序都调用这个DLL完成JPEG格式图片的处理工作。但是现在，正是这个“公众人物”成了众矢之的。
说到这里，有基础的读者应该明白了吧：并不是图片自己能传播病毒，而是系统负责图形处理工作的模块会在处理图片时发生溢出导致图片内携带的恶意指令得 以执行破坏。如果某个图片工具不调用这个系统模块，而是使用自己的处理模块，那么同样包含恶意指令的图片就不能达到破坏目的。但是因为这个系统模块是默认 的处理模块，所以大部分程序在“JPEG病毒”面前纷纷落马。
这个溢出是怎么产生的呢？这要从系统如何读取JPEG格式图形的原理说起，系统处理一个JPEG图片时，需要在内存里加载JPEG处理模块，然后 JPEG处理模块再把图片数据读入它所占据的内存空间里，也就是所说的缓冲区，最后我们就看到了图片的显示，然而就是在图片数据进入缓冲区的这一步出了错 ——Windows规定了缓冲区的大小，却没有严格检查实际容纳的数据量，这个带缺陷的边界检查模式导致了噩梦：入侵者把一个JPEG图片的数据加工得异 常巨大并加入恶意指令，那么这个图片在系统载入内存时候会发生什么情况呢？图片数据会涨满整个JPEG处理模块提供的缓冲区并恰好把恶意指令溢出到程序自 身的内存区域，而这部分内存区域是用于执行指令的，即核心区，于是恶意指令被程序误执行了，入侵者破坏系统或入侵机器的行为得以正常实施。有人也许会疑 惑，入侵者都是神算子吗，他们为什么能准确的知道会是哪些数据可以溢出执行？答案很简单，因为Windows在分配JPEG处理模块的空间时，给它指定的 内存起始地址是固定的，入侵者只要计算好这个空间大小，就能知道会有哪些数据被执行了，所以JPEG病毒迅速传播起来。
所谓JPEG病毒，并不是JPEG图片能放出病毒，而是系统处理JPEG图片的模块自己执行了JPEG图片携带的病毒，所以我们大可不必人心惶惶，只 要补上了GDIPLUS.DLL的漏洞，那么即使你机器上的所有JPEG图片都带有病毒数据，它们也无法流窜出来搞破坏，正如美国马萨诸塞州立大学助理教 授奥斯汀所言：“病毒不仅仅是可自我复制的代码，他们需要通过可执行代码的方式来进行传播。JPEG文件不能执行代码，他们是由应用软件打开的数据文件。 应用软件不会去查找数据文件中的可执行的代码，为此不会运行这些病毒代码。”
四、防范
对于虚假图片文件的欺骗手法，只要用户补上了MIME和IFRAME漏洞，那么入侵者让你停留多久也无济于事；至于BMP木马，它的防范是几乎不可避 免，但是它有个最大的弱点，大部分情况下只能在Win9x环境正常执行，用Win2000以上的用户不必草木皆兵了；而对于JPEG病毒来说更好办了，微 软已经提供JPEG模块的更新了，你倒是去补一下啊！即使真的一点也不会，买个防病毒软件在后台监视也OK了，但是为什么国内用户却偏偏喜欢徒劳的恐 慌？
纵观这一系列图片病毒的原理和手法，我们可以发现“社会工程学”这个身影的扩大化趋势。如何避免被骗，这只能看你自己了