2020年1月6日，青藤云安全宣布即將推出WebShell強對抗檢測平臺，日前已開啟定向邀測。據(jù)悉，目前已經(jīng)邀請了眾多安全圈大咖參與檢測，未來將進一步放開權(quán)限進行公測。
在安全圈，針對產(chǎn)品發(fā)起邀測或者公測時常有之，為何此次邀測能夠引起業(yè)界關(guān)注呢?究其原因，主要是因為WebShell檢測已經(jīng)是安全圈多年一大頑疾，很難解決，所有安全從業(yè)者都迫切希望能早日解決該問題。
正可謂是“安全圈苦WebShell久矣”。眾所周知，WebShell具有潛在的簡單性和易修改性，隱藏在正常的網(wǎng)頁文件中，傳統(tǒng)安全工具很難檢測到它們。例如，殺毒類產(chǎn)品在檢測WebShell方面基本處于無效狀態(tài)。
問 WebShell 為何物？
WebShell腳本通常被上傳到Web服務(wù)器中用于對機器進行遠程管理，受感染的機器可以是面向互聯(lián)網(wǎng)的主機，也可以是通過WebShell感染的企業(yè)內(nèi)部機器。WebShell可以用目標(biāo)Web服務(wù)器支持的任何語言編寫，例如PHP、ASP最為常用。惡意攻擊者可通過掃描器等偵查工具識別那些可被利用的漏洞，從而安裝WebShell。
攻擊者可以利用常見的漏洞，如SQL注入、遠程文件包含(RFI)、FTP，甚至使用跨站點腳本(XSS)作為攻擊的一部分，以上傳惡意腳本。一旦成功上傳，攻擊者就可以使用WebShell并配合其它技術(shù)進行提權(quán)或遠程發(fā)出命令。這些命令可直接鏈接到Web服務(wù)器可用的特權(quán)和功能，包括添加、刪除和執(zhí)行文件等能力。
在沒有較好的WebShell檢測產(chǎn)品之前或者誤報較高情況下，WebShell檢測就需要專家資源和人工支持。專家憑借經(jīng)驗，如果在服務(wù)器上發(fā)現(xiàn)下述這些特征，表明極有可能被WebShell感染。當(dāng)然這些特征也有可能是正常文件的特征，因此需要在具體場景下進行篩選，進一步檢查或驗證。
不正常的高使用率(包括潛在的上傳和下載活動)。
包含不尋常時間戳的文件(例如，在最新安裝Web應(yīng)用文件后出現(xiàn)了新文件)。
可實現(xiàn)互聯(lián)網(wǎng)訪問的Web根目錄中的可疑文件。
包含對可疑關(guān)鍵字(如cmd.exe或eval)引用的文件。
日志中的異常連接。例如從內(nèi)部子網(wǎng)到DMZ服務(wù)器的可疑登錄，反之亦然。
任何可疑命令的證據(jù)，例如Web服務(wù)器進程的目錄遍歷。
傳統(tǒng)WebShell檢測的六個常見方案
為解決WebShell檢測問題，常用的WebShell檢測方法包括人工識別、靜態(tài)檢測、動態(tài)檢測、日志分析檢測、基于語法檢測和統(tǒng)計學(xué)檢測等。
第一種也是最早的WebShell檢測采用的是人工識別的方法。這是檢測WebShell最古老、最傳統(tǒng)的方法，對網(wǎng)站的管理員要求很高。管理員應(yīng)全面掌握網(wǎng)站文件，對一些新增的異常文件如passby.php、pass.asp、a.jsp等命名的文件有較高的識別能力。這些小文件應(yīng)該小心處理，極有可能是木馬。在發(fā)現(xiàn)可疑文件后，需要分析文件的內(nèi)容。最徹底的方法是仔細查看整個文件，但這將花費大量時間。更好的方法是搜索一些敏感的函數(shù)，比如exec()、shell_exec()、system()，并仔細檢查它們的參數(shù)。
第二種檢測方法，在人工識別之后，就出現(xiàn)了基于靜態(tài)特征WebShell檢測，也是當(dāng)前研究的一個方向。這是手動識別的升級版，從某種程度上說它們幾乎完全相同，都是基于特征。雖然檢測速度較快，但是需要人工提取特征，而且僅僅通過特征匹配來檢測，只能檢測出已知特征的WebShell，不適用于檢測未知的WebShell。由于WebShell特征復(fù)雜多變，所以經(jīng)常需要使用機器學(xué)習(xí)來提高效率和準(zhǔn)確性。
第三種檢測方法，由于WebShell制作者會采用混淆和加密的方式繞過靜態(tài)特征檢測。但是當(dāng)WebShell運行時，必須向系統(tǒng)發(fā)送系統(tǒng)命令，以達到操作數(shù)據(jù)庫甚至系統(tǒng)的目的。動態(tài)特征檢測正是使用WebShell使用的系統(tǒng)命令、網(wǎng)絡(luò)流量和狀態(tài)異常來確定動作的威脅級別。該方法通過檢測系統(tǒng)調(diào)用來監(jiān)視甚至攔截系統(tǒng)命令，并從行為模式深入檢測腳本的安全性。例如在沙箱中執(zhí)行可疑腳本文件，通過查看系統(tǒng)狀態(tài)是否發(fā)生改變來判斷該腳本是否惡意。但是因為需要執(zhí)行和運行系統(tǒng)狀態(tài)，必然導(dǎo)致資源的浪費。此外針對一些特殊的特洛伊木馬，使用沙箱也基本無果。
第四種是日志分析檢測，正常網(wǎng)頁腳本文件通常相互都是存在連接關(guān)系的，但是惡意文件通常是處于“孤島”狀態(tài)，不與別的文件發(fā)生連接。使用WebShell一般不會在系統(tǒng)日志中留下記錄，但是會在網(wǎng)站的Web日志中留下WebShell頁面的訪問數(shù)據(jù)和數(shù)據(jù)提交記錄。日志分析檢測技術(shù)通過大量的日志文件建立請求模型從而檢測出異常文件，稱之為HTTP異常請求模型檢測。例如：一個平時是GET的請求突然有了POST請求并且返回代碼為200。但是該方法無法解決內(nèi)置在正常文件中的WebShell，而且黑客使用WebShell之后會清除對應(yīng)日志記錄。
第五種是統(tǒng)計學(xué)檢測，也是目前使用較為廣泛的一種方法。通過提取文件中特征代碼，針對某些變形惡意腳本效果較好，但是誤報和漏報非常高。目前，市場上有五種統(tǒng)計學(xué)方法可在腳本文件中搜索潛在的被混淆或被編碼的惡意代碼。
信息熵(Entropy)：通過使用ASCII碼表來衡量文件的不確定性。
最長單詞(LongestWord)：最長的字符串也許潛在的被編碼或被混淆。
重合指數(shù)(Indexof Coincidence)：低重合指數(shù)預(yù)示文件代碼潛在的被加密或被混淆過。
特征(Signature)：在文件中搜索已知的惡意代碼字符串片段。
壓縮(Compression)：對比文件的壓縮比。
采用這種檢測方法也存在明顯的弱點，它的檢測重心在于識別混淆代碼，它常常在識別模糊代碼或者混淆編排的木馬方面表現(xiàn)良好。未經(jīng)模糊處理的代碼極可能無法被識別出來。
第六種是屬性判斷，主要是基于WebShell文件屬性的判斷，例如創(chuàng)建時間、修改時間、所屬者等，這類方法并不針對文件本身進行檢查，只能做為一個參考信息。
未來可期，青藤 WebShell 檢測方案
上述六種方法都依賴于人工提取特征，自動化程度較低，而且非常容易被繞過。那么青藤究竟采用了什么樣的技術(shù)能夠解決安全圈多年頑疾呢?青藤定向邀測結(jié)果又如何呢?敬請大家關(guān)注下期文章《經(jīng)過10位被邀測的骨灰級技術(shù)大咖驗證：青藤WebShell檢測創(chuàng)史上最強……》。
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
