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