網馬的反掛馬檢測
Magictong
2012-07-25
本次只輸出反掛馬檢測的一些技術，以後有機會再分享掛馬檢測的針對性對抗技術。
最近一段時間跟蹤了微軟XML漏洞（CVE-2012-1889）的掛馬數據，跟進了一些網馬資源，發現裏面存在很多對抗技術，有些還是很不錯的，對於掛馬產業鏈我一直比較好奇。
一、使用Flash來封裝網馬
有兩種方法：
(1) 一種是使用使Flash AS的擴展API：ExternalInterface類來反調JS代碼。
import flash.external.*;
ExternalInterface.call("eval","jscode_string");
這個函數有兩個參數（第二個參數是一個變參，可以傳遞0個或者多個參數，實際就看第一個參數指明調用的js函數需要幾個參數了），一個是要調用的js函數名，一個執行參數，上面代碼的意思本質就是調用js的eval函數，參數是jscode_string。這樣可以將任意JS代碼封裝到Flash文件中，再對Flash文件進行壓縮加密保護起來，這種就很難檢測了。
(2) 另外一種是直接在as腳本里面寫Heapspray代碼，然後配合Js腳本的漏洞觸發代碼，聯合利用一個漏洞，可以繞過一些通用的Heapspray檢測方法。
二、通過String.fromCharCode函數來變形JS代碼
類似：
var sc = "spraySlide =spraySlide.substring(0,spraySlideSize/2)";
var out2 = "";
for(var i=0; i<sc.length; i++)
{
out2 +=String.fromCharCode(sc.charCodeAt(i) - 3);
}
document.write(out2);
既可變形代碼，也可以變形字符串，隨意搭配，提高繞過概率。
三、通過判斷客戶端的操作系統或者客戶端的安全軟件來決定是否掛馬
很多掛馬檢測系統都是跑在後臺的，而後臺一般是linux等服務器系統，通過判斷操作系統，決定是否掛馬，掛馬檢測系統一般不會跑js代碼的全部路徑，不過目前的一些蜜罐系統基本上僞造得和用戶環境一樣，因此此種方式的用途有多大值得商酌。另外就是如果發現某些安全軟件確實繞不過，則可以在客戶端進行檢測，避免被曝光（檢測方式知道創於研究院的總監餘弦在[2]裏面提到過）。
四、判斷Referrer字段
很顯然，蜜罐系統去取網頁代碼時，或者直接訪問時，Referrer字段是空的，而從已知的掛馬網站跳轉而來，或者從搜索引擎跳轉而來，則掛馬。更牛逼的是加上時間判斷，哪個時間段掛，哪個時間段不掛，譬如晚上掛，到白天了安全工作人員都上班的時間則不掛，猥瑣吧。
var url=document.referrer;
varp=url.toLowerCase().indexOf(".baidu.com");
if (p>0)
{
document.writeln("<iframesrc=*** width=0 height=0></iframe>");
}
var url=document.referrer;
varp=url.toLowerCase().indexOf(".google.com.hk");
if (p>0)
{
document.writeln("<iframesrc=*** width=0 height=0></iframe>");
}
五、使用JS訪問插件的屬性時進行變形
使用這種方法可以繞過很多通過JS的靜態特徵檢測漏洞的利用方式，直接上代碼說明，以最近的CVE-2012-1889漏洞爲例。
下面是CVE-2012-1889漏洞的原始POC代碼：
再看一段真實樣本的代碼：
它這裏其實也是訪問definetion屬性，不信你看：
用這種方式進行變形，基本上可以千變萬化。你可以發揮你的想象力。
六、其它反掛馬檢測技術
(1) 判斷當前IP是否是已知的IDC機房的IP，如果是則認爲是Spider（爬蟲）在爬取，給予錯誤的信息。或者甚至通過信息蒐集的方法直接探知Spider的IP地址。
(2) 通過cookie等指紋信息判斷用戶是否已經訪問過，如果已經訪問過了就不用再訪問了，不過可能躲不過蜜罐系統。
(3) 使用一些免費的空間，免費二級域名等方式隱藏行蹤[3]。
參考
[1] 免殺迅雷PPLAYER.DLL ActiveX控件溢出漏洞,http://blog.csdn.net/leeeryan/article/details/6127887
[2] xKungfoo上的網馬猥褻技巧, http://hi.baidu.com/ycosxhack/item/50aef2e8a6c1cae1fa42baa5
[3] 網馬的反掛馬檢測及精確投放, http://hi.baidu.com/monyer/item/a89437ea339cf2e3fb42ba63
[4] 網馬的反掛馬檢測及精確投放（續）, http://hi.baidu.com/monyer/item/948ea84244a37dab60d7b963
一個實例的簡單分析
以今天剛剛看到的一個掛馬鏈接爲例（最後分析發現其實沒掛馬，但是有Heapspray行爲，因此被Heapspray攔截抓獲了）。
分析過程：
URL：http://142.0.128.141/uuBxvO2.html（不要直接訪問，有一定危險性）
1、首先取到源代碼（注意：如果發現代碼不對頭，那就換環境試試）
HTML代碼裏面前面是一些Heapspray庫的代碼，不用看，直接看後面
2、這種代碼比較噁心，各種混淆變形，其實分析網馬，我們的目的是要找出最終執行的JS核心代碼，把這部分代碼通過alert，或者document.write()的方式打印出來，基本上就完成網馬分析了，剩下的工作就是找出是利用的什麼漏洞了。
3、對於這種混淆變量的JS代碼，沒什麼特別好的辦法，一層層的剝出來纔是王道。好吧，剝啊剝……其實那個字符串sNotc8裏面的代碼是可見的第一層JS代碼，sNotc8會被eval直接執行，看圖：
4、sNotc8裏面又是什麼代碼呢？繼續剝……這是一個苦力活，不過網上有一些JS代碼格式化工具可以使用，可以稍微減輕一下工作量，最後剝出來是（把變量名作了修改，已便於查看）：
5、好下面來剝這個第二層JS代碼，也就是上圖中的_strNull的值，這下不能靜態看，需要使用原始代碼，把這個值輸出來。代碼如下（有一個小技巧就是sNotc8這個字符串你不能修改他，因爲第一層的JS代碼裏面使用了這個字符串來解密第二層JS代碼，因此這裏重新定義一個字符串sNotc8_1，內容和sNotc8一樣，並稍做修改，見圖，然後eval這個字符串）：
6、坐等輸出第二層的JS代碼。
7、好吧，分析完成，至於第二層JS代碼（上圖）是在幹嘛，應該很清楚了。但是確實沒利用漏洞，純粹Heapspray！！！
後來和同事討論了下發現，之前的分析其實還沒有完成，問題出在原始的URL不全，原始URL是：http://142.0.128.141/uuBxvO2.html?%3Cembed%20src%3D%27dGaxmb6.swf%3Fhash%3D24C0AF115312706A8C9776145B5C4E955F27%27%20width%3D100%20height%3D0%3E%3C/embed%3E
解碼之後是：http://142.0.128.141/uuBxvO2.html?<embedsrc='dGaxmb6.swf?hash=24C0AF115312706A8C9776145B5C4E955F27'width=100 height=0></embed>
8、這就可以解釋當時分析時覺得沒用的那段代碼了：
9、沒錯，就是獲取當前URL裏面的數據，作爲HTML代碼的一部分，顯然這個代碼的關鍵部分就是：
<embed src='dGaxmb6.swf?hash=24C0AF115312706A8C9776145B5C4E955F27' width=100 height=0></embed>
10、下載這個swf文件回來反編譯發現，果然有玄機。
11、如果我沒有看錯，它應該是掛 [CVE-2012-0754] adobe flash play mp4格式解析漏洞，但是這裏比較巧妙的是他的mp4文件是直接從網絡讀取的。
結論：天下無免費的午餐，看來它不會無緣無故去做Heapspray的。而這種利用方式要精確攔截，還有點麻煩，因爲攔截這個漏洞的關鍵在於攔截最後觸發漏洞的那個MP4文件，如果這個文件不落地，我們現有技術無法進行內存查殺（當然我們現在還不能進行非PE查殺），當前只能依靠Heapspray攔截技術進行通殺攔截。
