Stuxnet的PLC感染方式文档格式.doc
《Stuxnet的PLC感染方式文档格式.doc》由会员分享，可在线阅读，更多相关《Stuxnet的PLC感染方式文档格式.doc（10页珍藏版）》请在冰点文库上搜索。
在终端上的用户设置最小用户权限。
在打开附件或通过网络接收文件时，弹出安全警告或提示。
在打开网络链接时，发出安全警告或提示。
尽量避免下载未知的软件或程序。
使用强口令，以保护系统免受攻击。
两个月前，赛门铁克首次披露了W32.Stuxnet针对工业生产控制系统（ICS）进行攻击，如应用于管道和核动力工厂的控制系统。
读者可参见赛门铁克2010年7月19日的博客–“W32.Stuxnet攻击微软零日漏洞利用USB设备大肆传播”。
2010年9月29日，我们还将在VirusBulletin会议上发布一篇包含W32.Stuxnet详尽技术细节的论文。
同时我们也注意到，最近非常多的人开始对Stuxnet感染系统且不易检测的事情表示关注。
由于Stuxnet针对某个特定的工业生产控制系统进行攻击，而这些行为不会在测试环境中出现，因此在测试环境下观察到的病毒行为不全面，很可能产生误导。
事实上，运行后，Stuxnet会立即尝试进入一个可编程逻辑控制器（PLC）的数据块—DB890。
这个数据块其实是Stuxnet自己加的，并不属于目标系统本身。
Stuxnet会监测并向这个模块里写入数据，以根据情况和需求实时改变PLC的流程。
在这篇博客里，我们会深入探讨Stuxnet的PLC感染方式和Rootkit功能，特别是以下几个方面：
它如何选择作为攻击目标的工业生产控制系统；
感染PLC代码块的方法；
注入PLC的恶意代码；
在被感染Windows机器中的PLCRootkit代码。
这四点我们会分开讲，因为用来实现这些目的的代码差异很大。
Stuxnet的目的是通过修改PLC来改变工业生产控制系统的行为，包括拦截发送给PLC的读/写请求，以此判断系统是否为潜在的攻击目标；
修改现有的PLC代码块，并往PLC中写入新的代码块；
利用Rootkit功能隐藏PLC感染，躲避PLC管理员或程序员的检测。
这些任务之间差别很大，比如，在被感染的Windows机器中隐藏感染代码使用的是标准的C/C++代码，而Stuxnet试图在工业生产控制系统及PLC中执行的恶意代码则是用MC7字节码写的。
MC7是PLC环境中运行的一种汇编语言，并常用STL进行编写。
在讨论Stuxnet攻击PLC的技术之前，让我们先来看看PLC是如何访问和编写的。
要进入PLC,首先需要安装特殊的软件；
Stuxnet会专门针对编写PLC某些模块的WinCC/Step7软件进行攻击。
安装这些软件后，程序员可以通过数据线连接PLC，以访问其中的内容，重新配置PLC，下载程序至PLC，或调试之前加载的代码。
一旦PLC被配置和编译后，Windows机器就可以断开和PLC的联系了，PLC会自行运行。
为了使您有一个更直观的感受，下图显示了在实际操作中，实验室里一些基本的设备配置：
下面的截图显示了Step7STL编译器中Stuxnet恶意代码的一部分。
其中，编写Stuxnet功能代码块的MC7代码的开始部分是可视的；
下面显示的代码来自于反汇编后的FC1873模块。
Step7软件使用库文件s7otbxdx.dll来和PLC通信。
当Step7程序准备进入PLC时，它会调用该DLL文件中不同的例程。
例如，如果一个代码块需要用Step7从PLC中读出，那么，例程s7blk_read就会被调用到。
s7otbxdx.dll中的代码会进入PLC,读出其中的代码，并把它传回Step7程序，如下图所示：
现在让我们看看当Stuxnet是如何进入PLC的。
运行后，Stuxnet会将原始的s7otbxdx.dll文件重命名为s7otbxsx.dll。
然后，它将用自身取代原始的DLL文件。
现在，Stuxnet就可以拦截任何来自其他软件的访问PLC的命令。
被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:
OB1是PLC程序的入口。
它没有特别的时间要求，总是循环执行。
OB35是一个标准的“看门狗”模块，系统会每100ms执行一次。
这个功能可能包含了所有用于监控紧要输入的逻辑，以达到立即响应，执行功能的目的。
功能模块（FC）都是标准的代码快。
它们包含了会被PLC执行的代码。
一般说来，OB1模块会引用至少一个FC模块。
下面的部分会详细讲述之前提到的威胁的四大方面。
感染原理
1.如何选择需要感染的PLC
Stuxnet会根据目标系统的特点，使用不同的代码来感染PLC。
一个感染的序列包括了许多PLC模块（代码模块和数据模块），用以注入PLC来改变目标PLC的行为。
这个威胁包括了三个感染序列。
其中两个非常相似，功能也相同，我们将其命名为序列A和B。
第三个序列我们命名为序列C。
Stuxnet通过验证“指纹”来判断系统是否为计划攻击的目标。
它会检查：
PLC种类/家族：
只有CPU6ES7-417和6ES7-315-2会被感染。
系统数据模块：
SDB会被解析；
根据他们包含的数据，感染进程会选择A,B或其它感染方式开始行动。
当解析SDB时，代码会搜索这两个值是否存在--7050hand9500h；
然后根据这两个数值的出现次数，选择序列A或B中的一种来感染PLC。
代码还会在SDB模块的50h子集中搜索字节序2CCB0001,这个字节序反映了通信处理器CP342-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）:
而序列C的程序流则更加复杂，可以从下面的图表中看到:
4.Rootkit
StuxnetPLCrootkit代码全部藏身于假冒的s7otbxdx.dll中。
为了不被PLC所检测到，它至少需要应付以下情况：
对自己的恶意数据模块的读请求；
对受感染模块（OB1,OB35,DP_RECV）的读请求；
可能覆盖Stuxnet自身代码的写请求。
Stuxnet包含了监测和拦截这些请求的代码，它会修改这些请求以保证Stuxnet的PLC代码不会被发现或被破坏。
下面列出了几个Stuxnet用被挂钩的导出命令来应付这些情况的例子：
s7blk_read:
监测读请求，而后Stuxnet会返回：
真实请求的DP_RECV（保存为FV1869）；
错误信息，如果读请求会涉及到它的恶意模块；
OB1或OB35的干净版本的拷贝s7blk_write:
监测关于OB1/OB35的写请求，以保证他们的新版本也会被感染。
s7blk_findfirst/s7blk_findnext:
这些例程被用于枚举PLC中的模块。
恶意模块会被自动跳过。
s7blk_delete:
监测对模块的“删除”操作。
如上文所述，Stuxnet是一个非常复杂的威胁，而其中的PLC感染代码令问题更加难以解决。
仅仅关于注入的MC7代码（我们于几个月前通过逆向工程获得）就可以讨论很久。
若想了解更多关于PLC感染例程和Stuxnet的总体情况，请务必关注我们即将于VirusBulletin会议中发布的白皮书。
卡巴斯基关于360解读“超级工厂”的声明
卡巴斯基实验室于2010年7月15日向全球公布了对“Stuxnet”病毒（国内译成“震网”、“超级病毒”或“超级工厂”，以下称“超级工厂”）的技术分析，并于9月24日由其创始人及CEO尤金@卡巴斯基先生公布了更为深入的行业解读：
1、“超级工厂”病毒采用了复杂的多层攻击技术，同时利用四种“零日漏洞”对微软操作系统进行攻击，利用两种有效的数字证书（Realtek和JMicron），让自己隐身。
2、“超级工厂”的目的不像一般的病毒，干扰电脑正常运行或盗窃用户财产和隐私，其最终目的是入侵SimaticWinCCSCADA系统，该系统主要被用做工业控制系统，能够监控工业生产、基础设施或基于设施的工业流程。
类似的系统在全球范围内被广泛地应用于输油管道、发电厂、大型通信系统、机场、轮船甚至军事设施中。
3、“超级工厂”已然是网络武器，被用于攻击敌对方的有重要价值的基础设施。
它标志着网络军备竞赛的开始。
4、“超级工厂”的幕后团队是技术非常高超的专业人员，并且具有广泛的资源以及强大的财力做后盾，他们应该是得到了某个国家或政府机构的支持。
对于这样一款标志着全球网络安全进入“基础设施保护时代”的恶性病毒，360不但没有做出任何得到微软承认的实质性贡献，却在10月2日，即卡巴斯基公布技术分析两个月后，发表了一份可谓“一派胡言”的官方新闻，声称“超级工厂”利用了“已知的”微软漏洞，更口出狂言：
“因为有360系列安全软件的存在”，“中国已躲过‘超级工厂’病毒攻击”。
事实上，“超级工厂”利用的正是“未知的”微软漏洞（国际上通常称之为“零日漏洞”），也即它是在微软尚没有认识到该漏洞之前进行系统攻击的。
因此，即使用户天天在用360打微软补丁，也无法防御这类攻击。
专业安全软件厂商之所以能够存在，就是因为它能在微软发布漏洞补丁之前就能帮助用户抵御这类病毒，甚至是比微软更早的发现这些“未知”的漏洞。
卡巴斯基是全球第一个发现“超级工厂”利用了两个最新的“零日漏洞”来进行攻击的专业安全厂商，比微软自身发现的还早，并在第一时间协助微软修复此漏洞，发布漏洞补丁。
“超级工厂”之所以没有同步在中国大爆发，最根本的原因是“超级工厂”的幕后团队并没有在第一时间把中国当成攻击目标，并不是因为中国有多少人安装了360。
如360宣称的那样，360依靠的是帮助用户打微软补丁防御“超级工厂”，这就意味着在微软发布补丁之前，360是没法防御“超级工厂”的。
如果“超级工厂”第一时间就攻击中国，那么安装了360的3亿网民（360官方数据）将全部“沦陷”，无一能逃。
卡巴斯基实验室认为，像360这样的非专业安全厂商，没有相应的技术和能力在第一时间截获“超级工厂”，不能对“超级工厂”这样的恶性病毒做出深入而合理的分析，是可以理解的。
但是，360掩饰自己的不足，就“超级工厂”发表严重背离事实，混淆视听的官方新闻，是完全不能接受的。
360的言论很容易让很多普通用户认为装了360就能抵御类似“超级工厂”这样的恶性病毒。
如果长期容忍这种欺骗用户、不顾事实的假宣传在安全行业蔓延，那么整个中国的互联网安全形势将进一步恶化，越来越多的最终用户会因为得不到正确的安全知识和专业的安全保护而受到伤害，遭遇更大的损失。
卡巴斯基实验室
2010年10月13日
360回应：
卡巴斯基对“超级工厂”的反应迟到了3个月来源：
360安全中心 发布日期：
2010-10-13
最近，360隐私保护器引发了腾讯公司的激烈反应。
根据以往经验，每当360为了用户利益而与其它厂商发生冲突的时候，总部设在俄罗斯的卡巴斯基公司总会不失时机地在背后发表攻击360的言论，譬如发表“回头是岸”公开信，又譬如发表所谓免费杀毒的“N宗罪”。
这一次也不例外，10月13日，卡巴斯基公开散布名为《360欺骗4亿网民胡乱解读“超级工厂”病毒》的文章，为了掩盖卡巴斯基对Stuxnet超级工厂病毒防护不力、反应迟钝的真相，故意歪曲事实，对360进行大肆攻击。
鉴于卡巴斯基的声明与事实严重不符、并使用了侮辱性的语言，360公司决定正式起诉卡巴斯基（中国）。
对卡巴斯基的文章，360公司回应如下：
一、360安全卫士在7月17日就能防御和查杀Stuxnet病毒，7月21日首家发布应急补丁，比微软官方补丁早两周
卡巴斯基声称“360依靠的是帮助用户打微软补丁防御‘超级工厂’，这就意味着在微软发布补丁之前，360是没法防御‘超级工厂’的。
”
事实的真相是，Stuxnet超级工厂病毒最早由赛门铁克在7月15日截获。
7月17日，360安全中心在国内率先发现Stuxnet病毒样本，当时命名为“假面”。
当天，360木马防火墙就通过升级迅速拦截了该病毒。
7月21日，360安全卫士率先针对Stuxnet攻击的“快捷方式自动执行”漏洞发布应急补丁，彻底堵死了Stuxnet病毒针对“快捷方式自动执行”漏洞的攻击，比微软官方8月3日修复漏洞（MS10-046）的日期早两周！
同时，360依赖自身强大的木马防火墙（主动防御技术），即使用户在不打微软补丁修复漏洞的前提下，360安全卫士和360杀毒都可以完全拦截Stuxnet病毒，包括该病毒带有Realtek和JMicron数字证书的版本。
7月17日，360橙色安全警报《微软0day漏洞遭利用“假面”木马化身快捷方式》
7月21日，《微软高危漏洞将遭大规模攻击360提供应急补丁》
二、为什么卡巴斯基在抵抗Stuxnet超级工厂病毒时姗姗来迟
在Stuxnet病毒刚刚出现的7月，卡巴斯基并没有对Stuxnet做出任何反应。
原因在于，Stuxnet采用了“父进程注入”的攻击方式，直接把病毒代码注入到卡巴斯基所有版本的进程中，能够轻松绕开或破坏卡巴斯基的防护。
而这类攻击方式在国内木马病毒中非常普遍，例如2009年感染量上百万的“刺陵”木马家族，而360安全卫士早已能够完美防御“父进程注入”攻击。
图：
Stuxnet用“父进程注入”攻击破坏的杀毒软件列表，其中第1、2位即为卡巴斯基
相比之下，卡巴斯基对中国木马病毒缺乏本地化的应对机制。
当Stuxnet这种全球性病毒采用了在中国很常见的病毒技术时，卡巴斯基反而无法抵抗。
直到病毒曝光3个月后，卡巴斯基才突然向360发难，歪曲说“360没法抵御Stuxnet，而卡巴斯基能够防御‘零日漏洞攻击’”，对于这种颠倒黑白的言论，我们深表诧异。
三、Stuxnet没有在中国爆发的真实原因
在Stuxnet超级工厂病毒的传播过程中，最主要的传播途径是攻击“快捷方式自动执行漏洞”（MS10-046），此外还有WindowsServer服务的远程溢出漏洞（MS08-067）以及打印后台程序服务中的远程代码执行漏洞（MS10-061）。
在入侵目标电脑系统后，Stuxnet会再利用Windows操作系统的两个本地权限提升漏洞来获得系统控制权。
从Stuxnet病毒出现在国内第一时间算起，360安全卫士当天升级了木马防火墙，就能够拦截Stuxnet病毒。
随后，360又发布了彻底免疫“快捷方式自动执行漏洞”的应急补丁，短短2周内，即为用户拦截了超过30万次相应的漏洞攻击，阻止了漏洞危害在国内的扩散。
由此可见，国内早有大批木马病毒采用Stuxnet的漏洞攻击技术，正因为有360的存在，在微软发布补丁前及时防御病毒，在微软发布补丁后彻底修复漏洞，为阻止国内出现Stuxnet病毒疫情做出了贡献。
而卡巴斯基所谓“中国躲过Stuxnet是因为该病毒不针对中国”的说法，是完全不正确的。
反观自命专业的卡巴斯基，被Stuxnet使用简单的“父进程注入”技术破坏后，一直没有修复自身存在的缺陷。
目前国内外已经有大量木马借用Stuxnet的技术攻击卡巴斯基，使所有卡巴斯基的用户面临安全威胁，在此，我们郑重建议卡巴斯基正视自身的问题，解决用户的实际需要。
四、360多次率先发现并为高危零日漏洞提供解决方案
诚然，Stuxnet超级工厂病毒首先出现在国外，其利用的快捷方式自动执行漏洞（MS10-046）、打印后台程序服务中的远程代码执行漏洞（MS10-061）都并非360安全中心首家发现。
但是在过去3年间，360安全中心已经多次在全球率先发现高危漏洞攻击，包括IEXML漏洞、微软Directshow视频开发包漏洞、Office网页组件漏洞等。
由于360系列安全软件覆盖了中国80%以上的个人电脑，当这些漏洞攻击出现在中国互联网上时，无一例外由360率先截获，并因此成为国内唯一受到微软公开致谢的个人电脑安全厂商。
而根据艾瑞咨询最新数据，截至今年8月份，卡巴斯基在中国安全软件市场覆盖率仅为3.35%，而这个数字仍在继续下降。
可想而知，卡巴在中国能截获的最新木马病毒和相应的攻击数量与360相比将如何。
我们希望卡巴斯基方面能够尊重事实，而不是用片面的说辞攻击同行。
毕竟，一款软件好不好用，有没有真正保护用户的安全，用户说了算，360用户量的迅猛上升和卡巴斯基的直线下跌已经说明了一切。
升级会员 