WebShell檢測思路淺談

Author: lake2 [80SEC][TSRC]
EMail:  lake2[at]foxmail.com
Site:   http://www.0x54.org
Date:   2010-12-19


[目錄]

0x00  前言
0x01  Webshell檢測模型
0x02  靜態特征檢測
0x03  動態特征檢測
0x04  結語


0x00  前言

    什么是webshell？我相信如果看官能有興趣看這篇文章，一定對webshell有個了解。不
過不了解也沒關系，那就請先搜索下相關資料[1]。當然，本著“know it then hack it”
的原則，建議你還是搭個環境，熟悉下先，畢竟紙上談兵是要不得的。

    隨著網絡的發展，Web站點的增加，webshell這種腳本后門技術也發展起來了，多少黑
客故事都是從一個小小的webshell開始的。所以對于網站，特別是站點和應用眾多的互聯網
企業，能夠在出現webshell的階段及時發現和響應就顯得尤為重要。

    本文以筆者多年從事相關工作的經驗來探討下webshell的檢測手段。


0x01  Webshell檢測模型

    記得當年第一個ASP木馬出來的時候號稱“永不被殺的ASP木馬”（請大家虔誠地起立，
我們一起來膜拜一下海洋頂端ASP木馬之父LCX大叔），因為它使用正常端口，且腳本容易變
形，使得查殺它變得困難。但是，Webshell這種特殊的Web應用程序也有兩個命門：文件和
HTTP請求。

    我們先來看下Webshell的運行流程：hacker -> HTTP Protocol -> Web Server -> CGI。
簡單來看就是這樣一個順序：黑客通過瀏覽器以HTTP協議訪問Web Server上的一個CGI文件。
棘手的是，webshell就是一個合法的TCP連接，在TCP/IP的應用層之下沒有任何特征（當然
不是絕對的），只有在應用層進行檢測。

    黑客入侵服務器，使用webshell，不管是傳文件還是改文件，必然有一個文件會包含
webshell代碼，很容易想到從文件代碼入手，這是靜態特征檢測；webshell運行后，B/S數
據通過HTTP交互，HTTP請求/響應中可以找到蛛絲馬跡，這是動態特征檢測。


0x02  靜態特征檢測

    靜態特征檢測是指不執行而通過圍觀的方式來發現webshell，即先建立一個惡意字符串
特征庫，然后通過在各類腳本文件中檢查是否匹配。這是一種最簡單也是最常見的技術，高
級一些的，可能還涉及到語義分析。筆者06年開發的“雷客圖ASP站長安全助手”[2]即是通
過此類辦法查找ASP類型的webshell的。

    靜態特征檢測面臨的一個問題是誤報。因為一些特征字符串正常程序本身也需要用到。
比如PHP里面的eval、system等，ASP里面的FileSystemObject、include等。所以雷客圖在
設計之初就是一個輔助工具，最終還需要有相關安全經驗的人來判定。

    對于少量站點可以用這樣人肉去檢查，如果是一個成千上萬站點的大型企業呢，這個時
候再人肉那工作量可就大了。所以用這樣一種思路：強弱特征。即把特征碼分為強弱兩種特
征，強特征命中則必是webshell；弱特征由人工去判斷。加入一種強特征，即把流行webshell
用到的特征作為強特征重點監控，一旦出現這樣的特征即可確認為webshell立即進行響應。
比如PHPSpy里面會出現phpspy、wofeiwo、eval($_POST[xxx])等，ASP里面出現Shell.Application
等。當然，黑客完全可以變形躲過，沒關系，還有人工檢查的弱特征。

    另一個問題是漏報。程序的關鍵是特征字符串，它直接關系著結果，如果你的特征庫里
面沒有記錄的甚至是一種新的webshell代碼，就可能束手無策了。雷客圖第一版出來后，我
自以為所有的ASP webshell都可以查了，但是我錯了，因為不斷會有新的方式出來繞過，最
終結果就是特征被動的跟著webshell升級而升級，同時還面臨未知的webshell——這個情況
和特征碼殺毒軟件何其相似。

    要解決誤報和漏報，就不能拘泥于代碼級別了。可以換個角度考慮問題：文件系統。我
們可以結合文件的屬性來判斷，比如apache是noboy啟動的，webshell的屬主必然也是nobody，
如果我的Web目錄無緣無故多了個nobody的文件，這里就有問題了。最理想的辦法是需要制度
和流程來建設一個Web目錄唯一發布入口，控制住這個入口，非法進來的Web文件自然可以發
現。


0x03  動態特征檢測

    webshell傳到服務器了，黑客總要去執行它吧，webshell執行時刻表現出來的特征，我
們稱為動態特征。

    先前我們說到過webshell通信是HTTP協議。只要我們把webshell特有的HTTP請求/響應
做成特征庫，加到IDS里面去檢測所有的HTTP請求就好了。

    這個方案有個問題就是漏報。首先你得把網上有的webshell都搜集起來抓特征，這是個
體力活，新的webshell出來還要去更新這個庫，總是很被動，被動就算了，但是一些不曾公
開的webshell通信就會漏掉。那么這個方案有沒有效果，只能說效果有限吧，對付拿來主義
的菜鳥可以，遇到高級一些的黑客就無效了。殺毒軟件都搞主動防御了，webshell也不能老
搞特征碼是吧。

    webshell起來如果執行系統命令的話，會有進程。Linux下就是nobody用戶起了bash，
Win下就是IIS User啟動cmd，這些都是動態特征，不過需要看黑客是否執行命令（多半會這
樣），還有就是你的服務器上要有一個功能強大的Agent。要是黑客高興，再反連回去，這
下就更好了，一個TCP連接（也可能是UDP），Agent和IDS都可以抓現行。這里還涉及到主機
后門的一些檢測策略，以后有機會再另文敘述。

    回到網絡層來，之前我們探討過，Webshell總有一個HTTP請求，如果我在網絡層監控HTTP
請求（我沒有監控Apache/IIS日志），有一天突然出現一個新的PHP文件請求或者一個平時
是GET請求的文件突然有了POST請求，還返回的200，這里就有問題了。這種基于區別于正常
請求的異常模型，姑且稱之為HTTP異常請求模型檢測。一旦有了這樣的模型，除了Webshell，
還可以發現很多問題的。

    還有一個思路來自《淺談javascript函數劫持》[3]和某款代碼審計軟件。回憶一下，
我們調試網馬的時候，怎么還原它各種稀奇古怪的加密算法呢，簡單，把eval改成alert就
好了！類似的，所以我們可以在CGI全局重載一些函數（比如ASP.Net的global.asax文件），
當有webshell調用的時候就可以發現異常。例如以下ASP代碼就實現了對ASP的execute函數
的重載：

--code-------------------------------------------------------------------------
<%
Function execute(stra)
    Response.Write("get the arg : "+stra)
End Function
a="response.write(""hello,world"")"
execute(a)
%>
-------------------------------------------------------------------------------

    這個方法在應用層還是有些問題，所以如果在CGI引擎內核里面改可能會好些。根據小
道消息，這期ph4nt0m的webzine會有一篇文章涉及PHP內核中防webshell的，有興趣的同學
可以關注。


0x04  結語

    本文只探討了檢測Webshell的一些思路，希望對你有些幫助，如果你有更好的方案，也
可以和我探討。至于一些工具和特征，由于這樣那樣的原因就不公開了，我始終認為，相比
于工具，思路永遠是最重要的。


0x05  廣告

    到此結束，也順便做個廣告。

    80SEC是一個致力于Web安全研究的團體，歡迎關注我們的最新動態，網址http://www.80sec.com

    TSRC是騰訊安全應急響應中心（Tencent Security Response Center）的縮寫，這是騰
訊公司負責突發安全事件處理的團隊，如果您對騰訊產品和業務有任何安全上的意見可以與
我們聯系，也歡迎有意在互聯網安全行業發展的同學加入我們。

    郵箱：security#tencent.com
    主頁：http://security.qzone.qq.com


References

[1] soso百科webshell，http://baike.soso.com/v35165.htm
[2] 雷客圖ASP站長安全助手，http://www.onegreen.net/code/HTML/24443.html
[3] 淺談javascript函數劫持，http://www.xfocus.net/articles/200712/963.html

-EOF-