正在阅读：Flame借Windows更新MITM代理服务器传播Flame借Windows更新MITM代理服务器传播

　　经过卡巴斯基实验室安全专家的研究分析，发现Flame恶意软件使用多种手段传播自身，其中最有趣的一种手段是利用微软Windows的更新服务。这一功能通过Flame的“SNACK”、“MUNCH”和“GADGET”模块实现。做为Flame的一部分，这些组件很容易进行重新配置。这些组件的行为由Flame的全局注册表控制，其中包含了数千个配置选项。

　　SNACK：NetBIOS名称服务器欺骗

　　SNACK模块会为所有网络接口或预设网络接口创建一个RAW网络套接字，并开始接收所有的网络数据包。它会查找其它计算机发送的寻找本地网络名称的NBNS数据包。一旦接收到这样的数据包，会将其写入加密的日志文件中（“%windir%\temp\~DEB93D.tmp”），之后将其传递进行进一步处理。

　　当NBNS请求中的名称同表达式中的“wpad”或“MSHOME-F3BE293C”匹配，会返回自己的IP地址。如果“SNACK.USE_ATTACK_LIST”变量被设置为“True”，该模块会检查数据包是否来自“SNACK.ATTACK_LIST”中指定的IP地址，并针对这些地址发出反馈。

　　“Wpad”是自动代理检测所使用的名称。通过将自己的IP地址反馈给“wpad”名称请求，SNACK模块向局域网宣告受感染计算机是局域网中一个代理服务器。

　　SNACK和MUNCH模块同样会同GADGET模块进行通讯，而GADGET模块能处理来自其他模块的各种事件。Flame的注册表包含LUA模块，能够处理像““MUNCH_ATTACKED”和“SNACK_ENTITY.ATTACK_NOW”这样的事件。

　　MUNCH：代理检测欺骗和Windows更新请求欺骗

　　“MUNCH”是FlameHTTP服务器模块的名称。只有在“MUNCH.SHOULD_RUN”变量被设置为“True”时，该模块才会启动。启动后，也不会出现任何提示，受害用户不会察觉。很多程序（包括反病毒程序、防火墙、网络嗅探器等）均收录于Flame注册表的“SECURITY.BAD_PROGRAMS”列表中。当MUNCH启动后，会从 “MUNCH.WPAD_DATA”变量中读取一个缓冲区，使用最匹配的网络接口IP地址替换“%%DEFAULT%%”模板并等待HTTP请求。

　　“MUNCH.WPAD_DATA”缓冲区其实是一个网络客户端请求的WPAD文件，允许自动代理服务检测的网络客户机会请求这个文件。WPAD文件中的代码会将请求连接的客户机的主机名MD5和其自己的MD5列表中的MD5进行匹配，如果匹配到，就会将自身声明为HTTP代理。

　　所以，如果一台设置了自动代理检测的计算机试图访问Windows更新主机时，会收到来自受感染计算机中的SNACK提供的IP地址，并通过由MUNCH提供的“wpad.dat”文件将受感染计算机用作代理服务器。这样，针对Windows更新服务的请求会被转移到MUNCH服务器。

　　当网络终端连接MUNCH服务器时，如果请求的是URI 而不是“/wpad.dat” and “/ view.php”，服务器就会：

　　1)运行“MUNCH.SHOULD_ATTACK_SCRIPT”）—一个Lua脚本，检查User-Agent首部是否有一项能匹配MUNCH.USER_AGENTS.CAB_PATTERN_*中指定的模板。Flame的我们手上的Flame注册表文件中包含以下模板：

　　MUNCH.USER_AGENTS.CAB_PATTERN_4 : WinHttp%-Autoproxy%-Service.*

　　MUNCH.USER_AGENTS.CAB_PATTERN_3 : Windows%-Update%-Agent.*

　　MUNCH.USER_AGENTS.CAB_PATTERN_2 : Industry Update.*

　　MUNCH.USER_AGENTS.CAB_PATTERN_1 : Microsoft SUS.*

　　2)检查请求的URI能否匹配到名为“MUNCH.GENERIC_BUFFERS.*.data.PATTERN”.的字符串列表中指定的任一模板。如果匹配，则获取相应的“MUNCH.GENERIC_BUFFERS.*.data.FILE_DATA”中指定的缓冲区，读取名为 “MUNCH.GENERIC_BUFFERS_CONTENT.value_of_FILE_DATA”的payload值，将其发送给客户端。

　　所有的payload均在Flame的注册表中列出，名称都以“MUNCH.GENERIC_BUFFERS_CONTENT.payload_name”开始，并使用了固定的104字节RC4密钥加密。

　　大多数payload都是已签名的CAB文件。文件中包含已签名的恶意代码，签名时间从2010年12月到2011年11月不等，签名机构为“MS”。此外，还有一些文件似乎真的来自Windows更新服务，这些文件的签名机构是“微软公司”。

　　由于这些CAB文件具有有效的签名（这些签名目前已经被微软撤销），Windows更新服务会对其当作合法的更新程序进行正常接收和处理。这些文件会被下载和安装，其中的恶意功能也会被有效执行。

　　这些CAB文件中最主要的恶意功能模块是一个下载器组件，名为“Wusetup.ocx”或“WuSetupV.exe”。该模块会收集大量计算机的信息，包括时区信息，并试图下载，URI中还追加有主机信息。由于“MSHOME-F3BE293C”名称由SNACK模块处理，所以URL就会指向运行MUNCH的服务器，而MUNCH则会将Flame的主模块“mssecmgr.ocx”加入到下载URI中。

　　WuSetupV下载该文件，将其保存到受攻击计算机的“%windir%\Temp\~ZFF042.tmp”目录下。将其作为DLL文件加载，并调用其导出的“DDEnumCallback”函数，即Flame的安装例程，这样这台计算机就被感染了。

　　卡巴斯基实验室最初发现Flame恶意软件时，曾想在其代码中寻找至少一种零日漏洞利用代码，因为想到Flame可能会用零日漏洞进行传播，感染网络中的其它计算机。考虑到其复杂性，而且还能够感染已经安装全部安全补丁的Windows 7计算机，卡巴斯基实验室安全专家认为这种可能性应该是存在的。但是，从目前发现的情况来看，它的传播方式比利用零日漏洞还精妙，因为它有一张免死金牌——有效的微软数字签名。而这些签名被发现后，立刻就被撤销了。微软也很快发布了安全公告，提供了KB2718704安全更新。