级别： 初级 Larry Loeb (larryloeb@prodigy.net), 作家, Secure Electronic Transactions
2001 年 10 月 01 日 由于最近一些病毒（如“红色代码”和 SirCam）在世界各地肆意猖獗，开发人员社区正在就如何应付这类威胁进行长期而仔细的研究。本文（也就是本系列文章的第一部分）中，一流的安全性专家 Larry Loeb 分析了（代码和所有信息）“红色代码”如何得以造成如此大的麻烦，而在第二部分中他将研究 SirCam 所带来的严重破坏。
过去的这个夏天对于大多数计算机用户而言是一个恼人的夏天。从因特网带来的病毒对安全性来说始终是一种威胁，并且这种威胁随着“红色代码”和 SirCam 的横行也发展到新的程度。这些侵犯行为给那些联网的社区带来一个新的认识：邻居的命运会影响到自己的处境，即使在网络中自己的那部分周围的护城河中放满食人鱼也于事无补。
发生了什么以及何时发生
有时几行文字对于在非常困惑的时期理解所发生问题的完全形态将很有帮助。上下文是相当重要的，因为首先必须在上下文中寻找已发生行为的意义。经我女儿 Jaemi 提醒，我意识到被亚里士多德称做
post hoc ergo propter hoc（或在希腊语中其它的说法）的那个逻辑错误在今天仍然有效。在汉语中，可以把这段拉丁语译做“事后归因”― 这里很明显的逻辑缺陷就是：起因事实上可以与事情为何以及何时发生没有直接联系。因此在文中随后的所有内容里，请不要仅仅因为 A 发生在 B 之前，就假定 A 使 B 发生。我们将会看到事情远比这个复杂。
在 2001 年 6 月 18 日，一个名为 eEye Digital Security 的公司发表了一份报告，声称它发现了一个广泛使用的商业现货（COTS）操作系统的问题（请参阅
参考资料）。这份报告较详细的描述了一个缓冲区溢出的弱点。因为 eEye 销售的安全性软件被设计用来预防和改正 COTS 软件的安全性问题，事后曾有过怨言说这些家伙应该对那个缺陷闭口不谈，而不该描述它。
注：我不同意这种观点。那个缺陷正如他们所描述的那样（经我们发现），而且 eEye 没有把它写进 OS 中。eEye 一贯主张他们的兴趣是通过完整公布信息来增强安全意识。即使他们认为他们最终将把他们的软件卖给那些突然变得更有安全意识的客户，这种自由公布问题的正确性仍然必须得到支持。这是一种含蓄的改正机制，它是如此重要，意义非凡而且很有必要，以至于它必须一直得到鼓励。这些都是题外话了。
果然，在 eEye 公布后不超过 30 天，一个正是利用 eEye 所描述的缓冲区溢出问题的蠕虫程序出现了（有关制造商的补丁程序，请参阅
参考资料）。
深入研究病毒代码（带偏移）
那么，这个家伙到底是如何工作的呢？尽管下列对这个蠕虫程序第一个版本的讨论取自 eEye 最初发表的公告并假设读者对 COTS OS 功能很了解，但攻击的方法比细节更重要。
当一个易受攻击的 Web 服务器遭受一个包含发动攻击所必需的代码以及包含蠕虫程序作为有效负载的 HTTP GET 请求袭击时，最初的病毒感染便开始发生。然后用 msvcrt.dll 中的地址 0x7801CBD3 重写 EIP。这个地址的代码反汇编以调用 ebx。当 EIP 被重写后，它就使程序流转回到堆栈。然后堆栈上的代码跳转至保留在初始 HTTP 请求主体中的蠕虫程序代码中。
第一个执行的代码是蠕虫程序为自己的使用而建立一个新的堆栈。这个新堆栈是由 CCh 填充的 218h 字节。然后，蠕虫程序代码继续运行以初始化它的函数跳转表。请注意整个蠕虫程序都使用 EBP 基于堆栈的内存偏移系统，这意味着所有的变量都以“EBP-X”值来引用。
接着，蠕虫程序引用位于 EBP-198h 的漏洞检测代码（exploit code）的数据部分。这就设置了它内部的函数跳转表（用来存储函数地址的基于堆栈的表）。这样就允许蠕虫程序在运行时生成函数地址，因而给了它更好的机会在更多系统上彻底地执行。
这种蠕虫程序所使用的技术被称为相对虚拟地址（Relative Virtual Address (RVA)）查寻。这意味着所有的函数 ― 特别是
GetProcAddress ― 都是在被感染的服务器程序本身中找到的。经过这些步骤，RVA 技术被用来获得
GetProcAddress 的地址。然后用
GetProcAddress 来获得
LoadLibraryA 的地址。在这两个函数的的合作之下，蠕虫程序需要的所有其它函数都可以轻易地找到。
蠕虫程序然后检查自己有多少线程（所有线程都共享同一代码基址）在活动，如果数目超过 100，则蠕虫程序进入另一种方式。在此过程中，蠕虫程序还执行
WriteClient （ISAPI 扩展 API 的一部分)，将“GET”发送回正在攻击的蠕虫程序。这些线程中的九十九个都用来攻击其它站点，而第 100 个则对 OS 做检查。如果它在检查中发现文件 c:\notworm，它就进入睡眠状态并且不再继续针对站点进行攻击。
如果蠕虫程序发现自己在安装 Windows 2000 英文版的机器上，它会试图通过钩连（hooking）来进行 Web 毁损（defacement）。钩连是一种通过指向内存驻留位置而不是通常的 TCP 连接来进行欺骗的技术。蠕虫程序修改 w3svc.dll（IIS 核心引擎）来更改
TcpSockSend 正常的操作。
TcpSockSend 是 w3svc.dll 用来将信息返回给客户机的。这个钩连（hook）在某个 Web 页面被请求时就胡乱拼凑用户所见的东西。幸运的是，10 小时后它会自行销毁，然后第 100 个线程将 w3svc.dll 还原到它的原始状态，包括重新保护内存。
针对站点的攻击较简单。首先创建一个套接字，然后试着通过端口 80 连接到 www.targetedsite.tld 并发送 100KB 数据。如果连接建立，则蠕虫程序创建一个执行 18000h 次单字节“send ()”的循环。蠕虫程序现在将重新把自身发送到任何它可以通过端口 80 连接的 IP 地址。（现在只有端口 80，但在以后的变种中会更改。）它使用多个“send()”，因此信息包通信可能会中断。在成功完成发送之后，它关闭套接字返回到攻击的开始，无限地重复这个循环。
仅仅为了使事情复杂 ...
一种类似的蠕虫程序也出现了，它使用相同的注入机制，但用“特洛伊木马”作为有效负载。“特洛伊木马”安装以后，就会给远程用户对被感染系统的完全访问权而并不实施针对站点的分布式拒绝服务（Distributed Denial of Service (DDoS)）攻击。通常它被称为“红色代码版本 2（CRv2）”。eEye Digital Security 的 Marc Maiffret 和 Ryan Permeh 对这种蠕虫程序的分析较详细地描述了特洛伊木马的机制（请参阅
参考资料）。
CRv2 最终把文件 explorer.exe 写到一个假的目录中，它一开始就已经把 cmd.exe 的副本 root.exe 放到那个目录中。（正如您所知道的，使用的假目录是 Drive:\progra~1\common~1\system\MSADC\root.exe 以及 Drive:\inetpub\scripts\root.exe 和 Drive:\progra~1\common~1\system\MSADC\root.exe。）在 Crv2 中有一个嵌入的二进制代码也将被写到 explorer.exe。这个二进制代码有这样的特性：如果嵌入的字节是 0xFC，它会被 20h 个 0x00 字节而不是常规字节替换。
为什么是这个文件？唔，Windows 2000 一个有趣的特征构成了这种攻击的基础。当用户登录系统时，OS 必须装入 explorer.exe（包含桌面和任务栏等等。）。OS 首先在主驱动器路径 [C:\] 中寻找它，这意味着“特洛伊木马”感染的 explorer.exe 将在下一次用户登录时被装入。这使系统每次引导时都被“特洛伊木马”感染。非常讨厌，是吗？
别急，还有更厉害的。“特洛伊木马”的效果之一是创建一个虚拟 Web 路径（/c 和 /d），来将 /c 映射到 c:\ 并将 /d 映射到 d:\。注意这个蠕虫程序的创作者设计这种例程来允许在受害系统上安置后门。这样，即使从 local/scripts 文件夹中除去了 root.exe（cmd.exe 命令行提示窗口程序），攻击者仍然可以使用 /c 和 /d 虚拟根路径来侵犯您的系统。只要“特洛伊木马”感染的 explorer.exe 还在运行，攻击者就可以远程访问服务器。
攻击看起来可能与以下情况相似：
- http://IpAddress/c/inetpub/scripts/root.exe?/c+dir（如果 root.exe 仍然在那里）或者
- http://IpAddress/c/winnt/system32/cmd.exe?/c+dir（其中，dir 可以是攻击者想执行的任何命令）。
“红色代码”影响
CRv1 最初的传播速率将 bewilliker 吓出了网络守卫者的行列。不加制止的话，它可以（也确实会）在感染并指挥 DDoS 攻击时使网络瘫痪。即使修补服务器软件（或在一些还没有直接被蠕虫程序感染的软件上运行），您还是能感受到这种病毒的可恶后果。您的系统会被受感染的服务器疯狂地扫描，而这白白地占据了系统带宽。网上的资源于是出乎意料地变得不可用。如果您在企业中将网络用于较重要但不是对任务至关重要的数据交换，您的系统好几天都会被攻击。另外，由于“红色代码”“有些随机”的网络访问，可恶的联网 HP 激光打印机会开始古怪地运行。
“红色代码”还会攻击 Cisco 路由器和软件。正如 Cisco 指出：
“这种蠕虫程序所引发的副作用会暴露其它产品的不相关问题。当来自蠕虫程序的信息流量达到一定值时，Cisco CSS 11000 系列的内容服务交换机会遇到内存分配错误，而导致内存崩溃继而要求重新引导。来自蠕虫程序的信息流还会引起 IP/VC 3510 Videoconference 多点控制单元和 Cisco Aironet 无线设备的缺陷。作为单独的副作用，蠕虫程序 [...] 会导致 Cisco 600 系列 DSL 路由器停止转发信息流。”（请参阅
参考资料）
Cisco 提到的那个小的信息流转发中断造成了 Qwest DSL 服务（该服务使用 Cisco 600 路由器）瘫痪，并影响依靠 Qwest 来转发那些发往自己系统的信息流的客户和其他人。“红色代码”如此有害的原因之一是它不仅把 PC 和网络搞糟，它还会追踪到基础设施 ― 可以说，这是另一种级别的危害。
但是别担心。Cisco 提供了一个 Web 页面来帮助您解决问题（请参阅
参考资料）。当然，如果您因为路由器被攻击而不能访问网络，那么 Cisco 所做的努力看起来也就不那么令人满意了。尽管花了一点时间，但 Qwest 现在正在为它的用户分发 Cisco CBOS 的更新版本（哎，还是通过因特网分发），Qwest 说这个软件能够解决问题。
传染用户是一方面。攻击路由器和激光打印机是另一方面。“红色代码”不止是一种传递机制 ― 它只是达不到圣经所说的灾祸。根据 Netcraft Web 服务器的调查（请参阅
参考资料），截止到 2001 年 10 月 1 日，超过 80000 台 IIS 服务器和 150000 个网站因为该蠕虫程序及其后代的攻击而瘫痪。如此大的数量不是某些 ISP 能够处理的。
因为“红色代码”在攻击时是基于日期的（传染，然后一直处于睡眠状态直到很多机器都可能被感染的某个日期，在那时它们将同时行动），网络警察正好在预期的第二波攻击前对社区发出了重要的警告。但反应并不积极。国会议员 Condit 在 CNN 的节目曾因这个蠕虫程序暂时中断，媒体对此事件有过大量报道。
但是当时钟敲过零点之后 ... 一切正常。数据病毒源并没有出现。因特网没有被摧毁（至少现在还没有）。FBI 国家基础设施保护中心（National Infrastructure Protection Center (NIPC)）最后发布了一个公告，公告略带羞怯地声明“红色代码在 2001 年 8 月 19 日晚上 8 点（美国东部时间）从扫描模式变为活动的分布式拒绝服务（DDoS）模式时所引起的因特网威胁明显地减少了”。
当然，主要 ISP 压制和消除了
所有人对端口 80 的访问。毫无疑问，其中一个 ISP 为您提供主机托管服务，那会引起极大的不便。但是关闭 80 端口（“红色代码”唯一的传播媒介）似乎减轻了传染循环。可是它没能消除“红色代码”。所有人都必须自己动手利用随后出现的免费工具中的一个来关闭自己机器上的端口 80。“红色代码”究竟是已被杀死还是变成网上另一个潜伏期很长的噪声级别将由多少主机安装了补丁程序决定，但是（令人惊讶的结果！）“红色代码”并没有导致在第一波攻击时令管理员们恐惧的网上信息资源的丢失。
大约就在 Crv1 病毒发作的同时，在巴尔的摩发生了一场火车隧道火灾，这场火灾持续了五天并熔化了因特网主管道中的一条。这是网络问题的根本原因 ― 物理链路的损坏。“红色代码”只是同时使事情变得更糟。谢谢你，亚里士多德先生。
关于“红色代码”过去和现在的危害性到底有多大，我们知之甚少，也许这才刚刚开始。关于这点的更多内容在本系列文章的第二部分中讨论。
参考资料
- eEye Digital Security 发表了一份有关它发现的被广泛使用的商业现货（COTS）操作系统问题的
报告。
- 获得解决缓冲区溢出弱点的
制造商补丁程序。
- eEye Digital Security 的 Marc Maiffret 和 Ryan Permeh 对“红色代码 II（CRv2）”的分析较详细地描述了
特洛伊木马机制。
- Cisco 提供了详细描述“红色代码”病毒如何运作的
Web 页面，还提供了一份描述“红色代码”如何影响特定 Cisco 产品的
安全性报告。
- 根据
Netcraft Web 服务器调查，截止到 2001 年 10 月 1 日，超过 80000 个 IIS 服务器和 150000 个 Web 站点因为这种病毒及其后代的攻击而瘫痪。
- 可以在
IBM 安全性站点找到最新的与安全性相关的新闻和产品信息。
关于作者  |
| | Larry Loeb 为许多上世纪主要的现可称为“废品”的计算机杂志撰稿，除了其它职务之外，他是 BYTE 杂志的顾问编辑和创办 WebWeek 的高级编辑。作为 BIX 上的 Macintosh Exchange 和 VARBusiness Exchange 的编辑，他从 uucp 用“!”寻址的时代（相对 !decvax 而存在的世界）就开始上网了。他还写过一本关于安全电子交易因特网协议的书。他的第一台 Mac 有 128K 内存。他的第一台 1130 有 4K 内存，和他的第一台 1401 一样。可以通过
larryloeb@prodigy.net给他发送邮件。
|
对本文的评价
| 
