“DNS隧道”盜號木馬分析
責編：admin ｜2014-07-15 15:05:48盜號木馬相信大家都不陌生。隨著網絡越來越普及，網上的賬號密碼越來越重要，盜號木馬的生命力也就越發的頑強了。
隨著與殺毒軟件的對抗，盜號木馬也在不斷的更新換代。QQ粘蟲就是一個很典型的例子，這類木馬的特點可以參考我們之前寫過的博文《“神奇”的qq粘蟲之旅》。而最近我們又監控到了QQ粘蟲中的一例新變種，其主要的突破在于將盜取的信息通過網絡發送出去的方法，思路頗為新穎，分享出來與大家共同把玩。
預熱
從行為上來看，這其實就是個普通的QQ粘蟲木馬而已：
偽裝成一個文件夾，誘導用戶點擊
運行后不斷監控頂端窗口，一旦發現為QQ，就彈出一個自己偽造的QQ登陸窗口，誘導用戶輸入密碼
編碼與發送
如果你不幸輸入了密碼并點擊了登陸，那么請節哀——你中招了。你的QQ號和密碼這些隱私數據正在木馬指令的授意下，被你自己不惜高價買下的高性能CPU和內存飛速的進行著編碼，并最終由你所鐘愛的那塊網卡發送到盜號者的服務器上……這絕對會是一個憂傷的故事……
但木馬的編碼過程卻頗費周章：
首先，是將一個固定字符串“aaaaaa”與你的QQ號和密碼這三組字符串，以制表符(’ ’)相連，拼成一個新的字符串，并將其轉為UTF-16編碼
然后，將上面的拼出的字符串的字符數(非字節數，實際上由于是UTF-16編碼，字符數是字節數的1/2)，保存為大端的WORD形式
接著，再將之前得到的賬號信息字符串取Hex字符串后再次進行UTF-16編碼……
我自己說著都亂……舉個例子，字符’a'，也就是’x61′，UTF-16編碼后就是’x61x00′，取Hex字符串就變成了’6100′，也就是’x36x31x30x30′，再UTF-16后則是’x36x00x31x00x30x00x30x00′
好吧，我猜大部分人還是暈……直接給大家看看最終結果吧，你的賬號信息已經變的面目全非了：
同時，前面獲取到的字符數也做同樣的處理，并拼到上面這個字符串的前面，如下：
最后，以16字符為一批進行循環加密，并將加密后數據轉成UTF-16編碼的Hex字符串，最終結果如下：
這么麻煩，當然是為了繞過各種檢測和分析系統，但同時還有一個目的——盜號者需要加密后的結果依然保持所有字符必須只有字母和數字組成(理論上還可以有連字符)。
這是為了給這個木馬最關鍵的一步做好鋪墊——以DNS查詢的形式將賬號信息發送出去！
木馬在內存中將加密后的字符串，前面拼上”www.”，后面拼上”.cn”，得到了一個根本不存在的域名。再填上必須的結構，精心構造出了一個DNS查詢數據包。
再將這個數據包用UDP協議發送到了自己的服務器的53端口——一切看起來都如此的天衣無縫。
一個DNS查詢而已，沒有額外的非法數據，只是查詢了一個不存在的域名，偽裝的夠深了吧！
百密一疏
但其實，通過Wireshark抓包還是可以看到一個很諷刺的事實——這個數據包依然是畸形的！根本不是正常的DNS查詢。
根據Wireshark的報錯信息，可以看到問題出在Queries這一段上，那具體是哪里異常了呢？QNAME部分的每個Label和前面的字節數都能對應上，QType是0×0001——A類請求，QClass是0×0001——IN。看著好像都沒錯啊？
其實問題還就是出在了木馬作者精心拼湊的這個加密字符串上，這一段Label的字節數為0×80——即128字節。而DNS請求的數據結構中隊Label的長度可是有嚴格的規定的：
Labels must be 63 characters or less.(參考RFC882 [Page30])
也就是說Label被允許的最大長度只有63字節——即0x3f，只要超過了這個值，即為畸形！
再次提醒大家——不要隨意執行網上下載下來的程序，發現涉及到賬號密碼的異常狀況，更要慎之又慎。在這個信息的時代，你的任何一些看起來無關緊要的數據的泄露，都可能成為黑客手中的重要社工數據——信息安全無小事。