Malwarebytes安全更新如何導致錯誤地識別惡意軟件

　　不久前的4月15日，在Malwarebytes論壇上開始出現關於惡意軟件檢測問題的帖子。似乎突然間它將操作系統的一些部分文件還有它本身當做是惡意軟件。

　　C:WindowsSystem32SessEnv.dll (Trojan.Downloader.ED) -> No action taken. [2c3c895fbbb0b97dfa37ff68d42fc63a]

　　C:WindowsSystem32upnphost.dll (Trojan.Downloader.ED) -> No action taken. [f1772bbd0a61f343e64b0463e3206898]

　　C:WindowsSystem32wcncsvc.dll (Trojan.Downloader.ED) -> No action taken. [35339a4ef07b2b0b6dc48dda8a79b749]

　　C:WindowsSystem32WebClnt.dll (Trojan.Downloader.ED) -> No action taken. [3a2e0adea3c82016c46d4720f21122de]

　　C:WindowsSystem32WsmSvc.dll (Trojan.Downloader.ED) -> No action taken. [e7815f897dee56e036fbf374e91af60a]

　　它為何開始檢測到它自己就是惡意軟件，一個可以解釋的通的起因是有什麼東西出現了極其嚴重的錯誤。

　　C:Program Files (x86)Malwarebytes’ Anti-Malwarembam.exe (Trojan.Downloader.ED) -> No action taken. [0365915779f2d16560d1a6c139cabf41]

　　C:Program Files (x86)Malwarebytes’ Anti-Malwarembamscheduler.exe (Trojan.Downloader.ED) -> No action taken. [d29647a1b2b9b18573be363108fb42be]

　　C:Program Files (x86)Malwarebytes’ Anti-Malwarembamservice.exe (Trojan.Downloader.ED) -> No action taken. [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.chk HTTP/1.1。

　　當時，返回的版本號是"v2013.06.27.09"，這個版本的數據庫我本地沒有(目的就是確保我自己的是過期的，從而能夠顯示這個更新的過程)。使用這個新的版本信息，它開始請求這個定義文件的信息文件，它是一個yaml格式的文件，描述了定義文件的大小，在下載後進行校驗的哈希值，以及一些其它的元數據。請求如下：

　　GET /v1/database/rules/data/rules.v2013.06.27.09.ref.yaml HTTP/1.1

　　隨後，來自更新服務器的響應如下：

　　filename: rules.v2013.06.27.09.ref

　　version:

　　previous: v2013.06.27.08

　　current: v2013.06.27.09

　　date: Thu, 27 Jun 2013 16:32:13 GMT

　　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.inc HTTP/1.1。

　　我獲得了一個二進制數據文件，好像就是其定義文件。我想要補充說明的是，正在管理Malwarebytes更新服務器的某位管理員添加了一些額外的“X前向頭”到了響應中：

　　HTTP/1.1 200 OK

　　Accept-Ranges: bytes

　　Cache-Control: max-age=7200

　　Content-MD5: TtzBRPrw2mTl+UYhEYzMvw==

　　Content-Type: text/plain

　　Date: Thu, 27 Jun 2013 16:51:37 GMT

　　ETag: “8b6-4e02516192100"

　　Expires: Thu, 27 Jun 2013 18:51:37 GMT

　　Last-Modified: Thu, 27 Jun 2013 16:16:36 GMT

　　Server: ECAcc (ams/489A)

　　x-admin: tedivm was here.

　　X-Cache: HIT

　　x-shameless-plug: Looking for a dev job? Send your resume to [email protected]

　　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.ref HTTP/1.1

　　GET /v1/database/rules/data/rules.v2013.04.15.13.ref HTTP/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點為我制作出了解密工具，你知道自己是誰的。