Malwarebytes安全更新如何导致错误地识别恶意软件

  　　不久前的4月15日，在Malwarebytes论坛上开始出现关于恶意软件检测问题的帖子。似乎突然间它将操作的一些部分文件还有它本身当做是恶意软件。　　C:WindowsSystem32SessEnv.dll(Trojan.Downloader.ED)->Noactiontaken.[2c3c895fbbb0b97dfa37ff68d42fc63a]　　C:WindowsSystem32upnphost.dll(Trojan.Downloader.ED)->Noactiontaken.[f1772bbd0a61f343e64b0463e3206898]　　C:WindowsSystem32wcncsvc.dll(Trojan.Downloader.ED)->Noactiontaken.[35339a4ef07b2b0b6dc48dda8a79b749]　　C:WindowsSystem32WebClnt.dll(Trojan.Downloader.ED)->Noactiontaken.[3a2e0adea3c82016c46d4720f21122de]　　C:WindowsSystem32WsmSvc.dll(Trojan.Downloader.ED)->Noactiontaken.[e7815f897dee56e036fbf374e91af60a]　　它为何开始检测到它自己就是恶意软件，一个可以解释的通的起因是有什么东西出现了极其严重的错误。　　C:ProgramFiles(x86)Malwarebytes’Anti-Malwarembam.exe(Trojan.Downloader.ED)->Noactiontaken.[0365915779f2d16560d1a6c139cabf41]　　C:ProgramFiles(x86)Malwarebytes’Anti-Malwarembamscheduler.exe(Trojan.Downloader.ED)->Noactiontaken.[d29647a1b2b9b18573be363108fb42be]　　C:ProgramFiles(x86)Malwarebytes’Anti-Malwarembamservice.exe(Trojan.Downloader.ED)->Noactiontaken.[1e4ad612fc6f0a2c3af7ce9941c2ab55]　　就像在主题为http://forums.malwarebytes.org/index.php?showtopic=125127的帖子中所看到的，它开始认为一些运行的进程，注册表项，还有存储在上的文件都是恶意软件的部分。　　但Malwarebytes的开发人员很快就发布了解决此问题的更新，甚至提供了一个专门修复此问题的工具。如马尔辛.克列金斯基在Malwarebytes博客上所发的帖子，这个问题在几分钟内就得到了修复-“在不到8分钟的时间里，就可以从我们的服务器上获取更新”。  

  　　那么是什么方面出了问题了?为了能够弄明白其中的原因，我们必须搞清楚更新系统是如何工作来找到我们所需的合适的恶意软件定义文件。一条线索来自什么时候添加了错误签名，然后什么时候发布了修复的定义文件。从一个名叫“catscomputer”的用户所发的一个帖子中我发现好像是一个升到版本“v2013.04.15.12”的更新，破坏了操作系统。而根据一个名叫“莫里斯.纳加尔”的Malwarebytes员工在论坛上的所说，修复这个问题的更新是“v2013.04.15.13”。　　为了了解Malwarebytes在更新时做了些什么，我打开Wireshark进行抓包分析(此时我正在写这篇博客)。它做的第一件事情是检查是否程序是最新的版本，然后是看看有没有什么新闻消息(我是这么认为的，但不是完全的确定)。  

  所有有关更新的请求都发送到了“data-cdn.mbamupdates.com”。最后它所做的是我们感兴趣的部分，更新定义文件。它开始请求最新的定义文件：GET/v1/database/rules/version.chkHTTP/1.1。　　当时，返回的版本号是"v2013.06.27.09"，这个版本的数据库我本地没有(目的就是确保我自己的是过期的，从而能够显示这个更新的过程)。使用这个新的版本信息，它开始请求这个定义文件的信息文件，它是一个yaml格式的文件，描述了定义文件的大小，在下载后进行校验的哈希值，以及一些其它的元数据。请求如下：　　GET/v1/database/rules/data/rules.v2013.06.27.09.ref.yamlHTTP/1.1　　随后，来自更新服务器的响应如下：　　filename:rules.v2013.06.27.09.ref　　version:　　previous:v2013.06.27.08　　current:v2013.06.27.09　　date:Thu,27Jun201316:32:13GMT　　package:　　size:6616865　　md5:cc8b2b2ace236d10eb833d9d3b46e23a　　format:legacydb　　content:　　size:26780341　　md5:318dd700ef1ac0b26b2eb2cf38d90cd4　　format:legacydb　　metadata:　　size:323　　当时，它看起来像是在做针对这一天的增量更新，其发出的请求如下：　　GET/v1/database/rules/data/rules.v2013.06.27.08_v2013.06.27.07.ref.incHTTP/1.1。  

  　　我获得了一个二进制数据文件，好像就是其定义文件。我想要补充说明的是，正在管理Malwarebytes更新服务器的某位管理员添加了一些额外的“X前向头”到了响应中：　　HTTP/1.1200OK　　Accept-Ranges:bytes　　Cache-Control:max-age=7200　　Content-MD5:TtzBRPrw2mTl+UYhEYzMvw==　　Content-Type:text/plain　　Date:Thu,27Jun201316:51:37GMT　　ETag:“8b6-4e02516192100"　　Expires:Thu,27Jun201318:51:37GMT　　Last-Modified:Thu,27Jun201316:16:36GMT　　Server:ECAcc(ams/489A)　　x-admin:tedivmwashere.　　X-Cache:HIT　　x-shameless-plug:Lookingforadevjob?Sendyourresumetojobs@malwarebytes.org　　Content-Length:2230　　Connection:close　　我想tedivm是这个管理员的代号，所以它与“x-shameless-plug”头能够很好地吻合。　　现在根据这些已经获得的更新文件，我们知道了它是如何工作的，对于我们所需要的两个版本的定义文件，分别是“v2013.04.15.12”和“v2013.04.15.13”，我们能够像下面这样获取：　　GET/v1/database/rules/data/rules.v2013.04.15.12.refHTTP/1.1　　GET/v1/database/rules/data/rules.v2013.04.15.13.refHTTP/1.1　　我们所获得的两个二进制数据文件，一个大小是6294406字节，一个大小是6294350字节，两者没有什么大的变化，但的确删除了某些东西。关于这些更新文件有一个问题，它们已经被加密。我不会告诉你如何去解密它们，但我在一个好友的帮助下，通过使用OllyDbg工具进行一些逆向工程分析，最终我们搞清楚了如何解密这些文件。下面是这些解密后的文件的不同之处：　　VOFFSET=Trojan.Downloader.ED,74433,1,6,　　687474703A2F2F36342E36342E32302E35302F32373753457236372E657865,NS　　VOFFSET=Trojan.Downloader.ED,74485,1,14　　687474703A2F2F6674702E74636D6C732E6F72672F7172415165562E657865,NS　　这里的描述信息“Trojan.Downloader.ED”就是之前在论坛帖子上所述的出现问题的描述信息。  

  尽管这些规则准确的工作原理，我不能说我已经100%确信是如何进行的，但这已经是到目前为止我所理解的东西：　　VOFFSET:某种用于字节匹配的偏移。无论是什么在等号之后的都是描述　　74433和74485好像是数字签名标识符，　　1,6和1.14好像是某种范围，后面我会再回过来看它们　　是与VT上的一种恶意软件有关的URI的二进制编码格式　　是与polyloader恶意软件加载程序有关的URI的二进制编码格式　　NS:没有关于这个是什么的线索　　我想在应用这些规则时出现了偏移错误或误解。如果你使用规则中的范围作为那些字节模式匹配中的串分割符的话，那么在第一条规则中范围1-6表示“http:”，而另一条规则中的范围1-14表示“http://ftp.tc“。我猜开始的时候"http:"与每个地方都可以匹配上，可能NS是一个标记，用以指示部分匹配也是可以的，谁知道了。　　我对MBAM检测为恶意软件的文件，做了一些检查，方法是首先执行Linux命令"strings-el"打印Unicode字符，然后根据其输出的字节编码，通过grep命令查找字符串"http:"。巧合的是，我从论坛上之前所投的帖子中所获得的所有被误认为是恶意软件的文件都包含了这些串，因此我想问题可能就出在这里。  

  　　这是一件很有趣的事情去弄明白加密方法和实际的定义文件本身。我甚至尝试将我自己定义的字节模式放入到自定义的规则文件中，去看看它是否那样工作，而结果是确实如此。另外，要特别地感谢被我剥夺了睡眠的好友，你在凌晨4点为我制作出了解密工具，你知道自己是谁的。