|
|
这东西原本是老美开发来对付当今世界”流氓国家“工厂PLC的蠕虫，不过对使用WinCC的电脑都会中招，坏电脑是小事，破坏生产是大事，下面是复制来的解读
详细解读Stuxnet 的感染流程
两个月前，赛门铁克首次披露了W32.Stuxnet 针对工业生产控制系统(ICS) 进行攻击，如应用于管道和核动力工厂的控制系统。读者可参见赛门铁克
2010 年7 月19 日的博客– “W32.Stuxnet 攻击微软零日漏洞利用USB 设备大肆传播”。2010 年9 月29 日，我们还将在Virus Bulletin 会议上发布一篇包含W32.Stuxnet 详尽技术细节的论文。同时我们也注意到，最近非常多的人开始对Stuxnet 感染系统且不易检测的事情表示关注。由于Stuxnet 针对某个特定的工业生产控制系统进行攻击，而这些行为不会在测试环境中出现，因此在测试环境下观察到的病毒行为不全面，很可能产生误导。事实上，运行后Stuxnet 会立即尝试进入一个可编程逻辑控制器(PLC)的数据块—DB890。这个数据块其实是Stuxnet 自己加的，并不属于目标系统本身。Stuxnet 会监测并向这个模块里写入数据，以根据情况和需求实时改变PLC的流程。
在这篇博客里，我们会深入探讨Stuxnet 的PLC 感染方式和Rootkit功能，特别是以下几个方面：
• 它如何选择作为攻击目标的工业生产控制系统；
• 感染 PLC 代码块的方法；
• 注入 PLC 的恶意代码；
• 在被感染 Windows 机器中的PLC Rootkit 代码。
这四点我们会分开讲，因为用来实现这些目的的代码差异很大。Stuxnet 的目的是通过修改PLC 来改变工业生产控制系统的行为，包括拦截发送给PLC 的读/写请求，以此判断系统是否为潜在的攻击目标；修改现有的PLC 代码块，并往PLC 中写入新的代码块；利用Rootkit 功能隐藏PLC 感染，躲避PLC 管理员或程序员的检测。这些任务之间差别很大，比如，在被感染的Windows 机器中隐藏感染代码使用的是标准的C/C++ 代码，而Stuxnet 试图在工业生产控制系统及PLC 中执行的恶意代码则是用MC7 字节码写的。MC7 是PLC环境中运行的一种汇编语言，并常用STL 进行编写。
在讨论Stuxnet 攻击PLC 的技术之前，让我们先来看看PLC 是如何访问和编写的。
(原文件名:详细解读Stuxnet的感染流程.jpg)
要进入PLC, 首先需要安装特殊的软件；Stuxnet 会专门针对编写PLC某些模块的WinCC/Step 7 软件进行攻击。安装这些软件后，程序员可以通过数据线连接PLC，以访问其中的内容，重新配置PLC，下载程序至PLC，或调试之前加载的代码。一旦PLC 被配置和编译后，Windows 机器就可以断开和PLC 的联
系了，PLC 会自行运行。为了使您有一个更直观的感受，下图显示了在实际操作中，实验室里一些基本的设备配置：
(原文件名:详细解读Stuxnet的感染流程.jpg)
下面的截图显示了Step7 STL 编译器中Stuxnet 恶意代码的一部分。其中，编写Stuxnet 功能代码块的MC7 代码的开始部分是可视的；下面显示的代码来自于反汇编后的FC1873 模块。
(原文件名:详细解读Stuxnet的感染流程.jpg)
Step 7 软件使用库文件s7otbxdx.dll 来和PLC 通信。当Step7 程序准备进入PLC 时，它会调用该DLL 文件中不同的例程。例如，如果一个代码块需要用Step 7 从PLC 中读出，那么，例程s7blk_read 就会被调用到。s7otbxdx.dll中的代码会进入PLC, 读出其中的代码，并把它传回Step 7 程序，如下图所示：
(原文件名:详细解读Stuxnet的感染流程.jpg)
现在让我们看看当Stuxnet 是如何进入PLC 的。运行后，Stuxnet 会将原始的s7otbxdx.dll 文件重命名为s7otbxsx.dll。然后，它将用自身取代原始
的DLL 文件。现在，Stuxnet 就可以拦截任何来自其他软件的访问PLC 的命令。
(原文件名:详细解读Stuxnet的感染流程.jpg)
被Stuxnet 修改后的s7otbxdx.dll 文件保留了原来的导出表，导出函数为109 个，这就令Stuxnet 可以应付所有相同的请求。大部分导出命令会转发
给真正的DLL，即重命名后的s7otbxsx.dll，并不会出现什么难对付的状况；事实上，109 种导出形式中的93 种都会照这样处理。然而，真正的“诡计”使用
在剩下的16 种导出命令中。这16 种导出不会被简单的转发，而是被改动后的DLL 拦截了。被拦截的导出命令为在PLC 中读、写、定位代码块的例程。通过拦
截这些请求，Stuxnet 可以在PLC 管理员没有察觉的情况下，修改发送至PLC 或从PLC 返回的数据。同时，通过利用这些例程，Stuxnet 可以将恶意代码隐藏在PLC 中。为了更好的了解Stuxnet 如何进入和感染PLC，我们先来看看各种类型的数据。PLC 会处理由管理员加载到PLC 的代码和数据。这里，我们将简要介绍一下最常见的模块和他们的功能：
• 数据模块(DB)包含了程序相关的数据，比如数字，结构等。
• 系统数据模块(SDB) 包含了 PLC 的配置信息； 它们是根据连接到PLC 的
硬件模块的数量/种类设立的。
• 组织模块(OB) 是程序的入口。他们由CPU 循环执行。针对Stuxnet， 有
两个特别需要的OB:
o OB1 是 PLC 程序的入口。它没有特别的时间要求，总是循环执行。
o OB35 是一个标准的“看门狗”模块，系统会每 100ms 执行一次。
这个功能可能包含了所有用于监控紧要输入的逻辑，以达到立即响
应，执行功能的目的。
• 功能模块（FC）都是标准的代码快。它们包含了会被 PLC 执行的代码。
一般说来，OB1 模块会引用至少一个FC 模块。
下面的部分会详细讲述之前提到的威胁的四大方面。
1. 如何选择需要感染的PLC。
Stuxnet 会根据目标系统的特点，使用不同的代码来感染PLC。一个感染的序列包括了许多PLC 模块（代码模块和数据模块），用以注入PLC 来改变目标PLC 的行为。这个威胁包括了三个感染序列。其中两个非常相似，功能也相同，我们将其命名为序列A 和B。第三个序列我们命名为序列C。Stuxnet 通过验证“指纹”来判断系统是否为计划攻击的目标。它会检查：
• PLC 种类/家族：只有CPU 6ES7-417 和6ES7-315-2 会被感染。
• 系统数据模块：SDB 会被解析；根据他们包含的数据，感染进程会选择
A,B 或其它感染方式开始行动。当解析SDB 时，代码会搜索这两个值是否
存在-- 7050h and 9500h；然后根据这两个数值的出现次数，选择序列A
或B 中的一种来感染PLC。
代码还会在SDB 模块的50h 子集中搜索字节序2C CB 00 01, 这个字
节序反映了通信处理器CP 342-5 (用作Profibus-DP) 是否存在。
而选择序列C 进行感染的条件则由其他因素构成。
2. 感染方法
Stuxnet 使用“代码插入”的感染方式。当Stuxnet 感染OB1 时，它会
执行以下行为：
• 增加原始模块的大小；
• 在模块开头写入恶意代码；
• 在恶意代码后插入原始的 OB1 代码。
Stuxnet 也会用类似于感染OB1 的方式感染OB35。它会用自身来取代标准的协同处理器DP_RECV 代码块，然后在Profibus (一个标准的用作分布式I/O
的工业网络总线) 中挂钩网络通信。
利用A/B 方法的感染步骤如下：
• 检查 PLC 类型；该类型必须为S7/315-2；
• 检查 SDB 模块，判断应该写入序列A 或B 中的哪一个；
• 找到 DP_RECV，将其复制到FC1869，并用Stuxnet 嵌入的一个恶意拷贝将
其取代；
• 在序列中写入恶意模块（总共 20 个），由Stuxnet 嵌入；
• 感染 OB1，令恶意代码可以在新的周期开始时执行；
• 感染 OB35, 它将扮演“看门狗”的角色。
3. 感染代码
被注入OB1 功能的代码是用来感染序列A 和B 的。这些序列包含了以
下模块：
• 代码块：FC1865 至 FC1874, FC1876 至FC1880 （注意：FC1869 并非
Stuxnet 的一部分，而是PLC 的DP_RECV 模块的一个拷贝）；
• 数据模块：DB888 至 DB891。
序列A 和B 用DP_RECV 挂钩模块来拦截Profibus 中的数据包，并根据在这些模块中找到的数值，来构造其他的数据包并发送出去。这由一个复杂的状态机控制（状态机被建立在上面提到的FC 模块中）。这个状态机可部分受控于数据块DB890 中的DLL。在某些条件下，序列C 会被写入一个PLC。这个序列比A 和B 包含更多的模块：
• FC6055 至 FC6084；
• DB8062, DB8063；
• DB8061, DB8064 至 DB8070 （在运行中产生）。
序列C 主要为了将I/O 信息读写入PLC 的内存文件映射的I/O 区域，以及外围设备的I/O。程序A/B 的控制流如下图所示，在之前的Step7 编辑器的截图中也有
部分显示（数据模块FC1873）:
(原文件名:详细解读Stuxnet的感染流程.jpg)
(原文件名:详细解读Stuxnet的感染流程.jpg)
4. Rootkit
Stuxnet PLC rootkit 代码全部藏身于假冒的s7otbxdx.dll 中。为了不被PLC 所检测到，它至少需要应付以下情况：
• 对自己的恶意数据模块的读请求；
• 对受感染模块(OB1 , OB35, DP_RECV) 的读请求；
• 可能覆盖 Stuxnet 自身代码的写请求。
Stuxnet 包含了监测和拦截这些请求的代码，它会修改这些请求以保证Stuxnet 的PLC 代码不会被发现或被破坏。下面列出了几个Stuxnet 用被挂钩
的导出命令来应付这些情况的例子：
• s7blk_read: 监测读请求，而后Stuxnet 会返回：
o 真实请求的 DP_RECV (保存为FV1869)；
o 错误信息，如果读请求会涉及到它的恶意模块；
o OB1 或OB35 的干净版本的拷贝
• s7blk_write: 监测关于OB1/OB35 的写请求，以保证他们的新版本也会被感染。
• s7blk_findfirst / s7blk_findnext: 这些例程被用于枚举PLC 中的模块。恶意模块会被自动跳过。
• s7blk_delete: 监测对模块的“删除”操作。
如上文所述，Stuxnet 是一个非常复杂的威胁，而其中的PLC 感染代码令问题更加难以解决。仅仅关于注入的MC7 代码（我们于几个月前通过逆向工
程获得）就可以讨论很久。若想了解更多关于PLC 感染例程和Stuxnet 的总体情况，请务必关注我们即将于Virus Bulletin 会议中发布的白皮书。 |
阿莫论坛20周年了！感谢大家的支持与爱护！！
一只鸟敢站在脆弱的枝条上歇脚，它依仗的不是枝条不会断，而是自己有翅膀，会飞。
|
发表于 2011-1-19 15:44:31
楼主