?

Nov 13 2015

webshell檢測-日志分析

首頁 » 滲透測試 » webshell檢測-日志分析   

一直認為日志分析的最終奧義是取證與預測——講述完整的已發生、正在發生的、將來會發生的攻擊故事(何時.何地.何人.何事.何故)。
而本文之所以講如何識別webshell,就是想從確定的攻擊事件來回溯已發生的攻擊事件,被植入的webshell毫無疑問就屬于確定的攻擊事件,只要曾經被傳入過,就有很高的概率一直被黑

webshell檢測不是新鮮事,主流有殺毒軟件與入侵檢測系統兩種做法,而這兩種方法除了技術上的缺陷外(后文會講),更多時候,由于無法拿到完整的文件樣本(webshell查殺工具部署成本比較高,有系統兼容問題,有性能問題),或無法拿到完整的流量信息(流量鏡像的部署成本也非常高),而采用成本較低的日志分析方法。

本文重點講webshell檢測的日志分析方法,包括模型是如何建立與實現的,最后會簡單的提一下傳統的檢測方法與之對比。

一、分析
總的思路:先找到異常日志,再找到攻擊日志,整個過程分為兩個步驟:webshell提取 + webshell確認
(p.s就像我在

web日志異常檢測實踐之長度異常模型 與理工渣眼中的HMM及安全應用

介紹的,先發現未知,然后從未知中確認已知)

1、webshell提取

根據安全經驗,我們可以給出以下假設 

(1)webshell 的訪問特征(主要特征)
1)少量的IP對其發起訪問 
2)總的訪問次數
3)該頁面屬于孤立頁面


注意紅色標記的詞匯都是抽象的形容詞,我們需要將這些特征量化,比如說少量,多少算少量?什么是孤立頁面?
接下來常見的描述性統計方法上場,我們來統計
1)單個URL每天的總訪問分布
2)單個URL的獨立訪問IP數目分布
3)單個URL的入度、出度分布 (我們可以將網站的訪問路徑當成一個有向圖)

下面,小小科普一下有向圖的基本概念
如何通過數據分析提取webshell - 碳基體 - 碳基體
 
 

節點vertices(node):1,2,3,4,5,6,7,8 相當于訪問日志中的url
邊edge:1->2 1->3 4->1 5->1 6->5 7->7 相當于從A url跳轉到B url
入度in-degree 
出度out-degree

節點1的入度為2, 出度為2
節點2、節點3的入度為1,出度為0
節點4、節點6的入度為0,出度為1 ,屬于懸掛節點(pendant vertex),比較特殊,例如404跳轉到首頁會產生這樣的節點
節點5的入度為1,出度為1
節點7的入度為1,出度為1,但自己指向自己,屬于自回路,大多數有驗證的webshell都屬于這種
節點8的入度為0,出度為0,屬于孤立節點(isolated vertex)

而節點7、8就屬于webshell訪問特征中的(3)該頁面屬于孤立頁面

(p.s. 使用基于圖的異常檢測方法Graph-based Anomaly Detection, 在安全檢測方法中占據非常非常非常非常重要的位置,例如檢測受蠕蟲感染的機器等)

補充20151103:對于出度入度>1的webshell也是存在的,什么是孤立,與其他頁面的交互度為多少算孤立,都是相對的。
當webshell采用<a href>標簽列出當前目錄下的文件的時候,就會產生與其他頁面的交互。當需要多個腳本協同作用的webshell也會產生交互。




當然不是所有的孤立頁面都是webshell,以下情況也會造成孤立頁面
(1)隱藏管理后臺等正常孤立頁面(多半是過期遺忘的,或者沒有做訪問控制權限的)的訪問
(補充20151103:有人質疑過,后臺為啥會孤立,登進去后不就跳轉到其他頁面了嗎?如果只是打開頁面,不做登陸操作呢?)
(2)掃描器行為,常見漏洞掃描,PoC掃描,Webshell掃描(日志中經常可以看到常見webshell路徑加一句話payload的掃描)——這是最主要的干擾數據,需要剔除

對于情況(1)采用白名單的方式,對于情況(2)掃描器識別
(p.s. 爬蟲技術、指紋識別技術、掃描器識別(廣義的可衍生到人機識別)可以稱為web安全技術的三駕馬車,總也繞不過去)

補充20151103:模型運行了1個多月后,發現孤立頁面的情況真是五花八門,一些站點放了個“安全”檢測工具,“上傳壓縮密碼重置”便捷工具都不帶刪的。

(2)webshell 的path特征(輔助特征)
除了weshell特有的訪問特征,我們也可以用path特征來輔助提取
我們來看一批真實的webshell
如何通過數據分析提取webshell - 碳基體 - 碳基體
 
會發現不同手段植入的webshell路徑各有特征,例如上傳的webshell,如果上傳組件有保護措施的(

文件上傳漏洞防御——圖片寫馬的剔除

)會進行文件名重寫(示例中的32位的十六進制的名字),并在路徑中還有日期特征,這類webshell還極易出現在靜態資源目錄(圖片,樣式、配置、)下。

補充20151103:批量寫馬的時候,特別是利用漏洞進行的批量寫馬,會用腳本來自動生成文件名,然后放在特定的目錄下,對path的相似性分析會發現這個規律。
(文本相似性也是數據分析的基本技能)

(3)webshell的時間特征(輔助特征)
將新增的頁面視為異常頁面,但這種方案的缺陷非常明顯

(1)會漏掉已存在頁面寫馬的情況
(2)會誤判正常的站點更新

于是將該特征當做輔助特征,用來還原webshell植入的過程,如果接入了例如WAF這種防御產品,還可以探究是不是繞過了防御

補充20151103: 文件的時間屬性也是可以修改的

(4)webshell Payload特征(輔助特征)
WAF、IDS等基于流量的安全檢測防御工具,會把網絡通信中的payload特征(特別是攻擊特征)當成主要的檢測手段
webshell檢測-日志分析 - 碳基體 - 碳基體
圖片參考 《closing the door on webshell》-by Anuj Soni

下面列舉一些實際發現的payload(做脫敏處理后的)
		

SUPort=43958&SUUser=LocalAdministrator&SUPass=xxx&SUCommand=net+user+spider+spider+%2Fadd+%26+net+localgroup+administrators+spider+%2Fadd&user=spider&password=spider&part=C%3A%5C%5C

		

whirlwind=%40eval%01%28base64_decode%28%24_POST%5Bz0%5D%29%29%3B&z0=QGluaV9zZXQoImRpc3BsYXlfZXJyb3JzIiwiMCIpO0BzZXRfdGltZV9saW1pdCgwKTtAc2V0X21hZ2ljX3F1b3Rlc19ydW50aW1lKDApO2VjaG8oIi0%2BfCIpOzskRD1kaXJuYW1lKCRfU0VSVkVSWyJTQ1JJUFRfRklMRU5BTUUiXSk7aWYoJEQ9PSIiKSREPWRpcm5hbWUoJF9TRVJWRVJbIlBBVEhfVFJBTlNMQVRFRCJdKTskUj0ieyREfVx0IjtpZihzdWJzdHIoJEQsMCwxKSE9Ii8iKXtmb3JlYWNoKHJhbmdlKCJBIiwiWiIpIGFzICRMKWlmKGlzX2RpcigieyRMfToiKSkkUi49InskTH06Ijt9JFIuPSJcdCI7JHU9KGZ1bmN0aW9uX2V4aXN0cygncG9zaXhfZ2V0ZWdpZCcpKT9AcG9zaXhfZ2V0cHd1aWQoQHBvc2l4X2dldGV1aWQoKSk6Jyc7JHVzcj0oJHUpPyR1WyduYW1lJ106QGdldF9jdXJyZW50X3VzZXIoKTskUi49cGhwX3VuYW1lKCk7JFIuPSIoeyR1c3J9KSI7cHJpbnQgJFI7O2VjaG8oInw8LSIpO2RpZSgpOw%3D%3

		

n3b31d1=cGhwaW5mbygpOw==

		

getpwd=admin&go=edit&godir=%2Fhtdocs%2Fbbs%2Fconfig%2F&govar=config_global.php

		

senv=eval(\"Ex\"%26cHr(101)%26\"cute(\"\"Server.ScriptTimeout%3D3600:On+Error+Resume+Next:Function+bd%28byVal+s%29%3AFor+i%3D1+To+Len%28s%29+Step+2%3Ac%3DMid%28s%2Ci%2C2%29%3AIf+IsNumeric%28Mid%28s%2Ci%2C1%29%29+Then%3AExecute%28%22%22%22%22bd%3Dbd%26chr%28%26H%22%22%22%22%26c%26%22%22%22%22%29%22%22%22%22%29%3AElse%3AExecute%28%22%22%22%22bd%3Dbd%26chr%28%26H%22%22%22%22%26c%26Mid%28s%2Ci%2B2%2C2%29%26%22%22%22%22%29%22%22%22%22%29%3Ai%3Di%2B2%3AEnd+If%22%22%26chr%2810%29%26%22%22Next%3AEnd+Function:Response.Write(\"\"\"\"->|\"\"\"\"):Ex\"%26cHr(101)%26\"cute(\"\"\"\"On+Error+Resume+Next:\"\"\"\"%26bd(\"\"\"\"526573706F6E73652E5772697465282268616F72656E2229\"\"\"\")):Response.Write(\"\"\"\"|<-\"\"\"\"):Response.End\"\")\")"



但在日志分析中只能當成輔助特征,有兩個原因:
a. 日志字段不全的問題,無法使用payload
b. 攻擊者很多時候只是在做webshell存活性探測,不會產生攻擊特征,或者將會攻擊payload進行加密處理來繞過特征檢測
如下例wso 2.5.1 的payload為a=RC
webshell檢測-數據分析 - 碳基體 - 碳基體
  
但也不要輕視了這種直觀的特征,常規webshell是占較大比例的,并且在webshell特別是只有回顯信息無GUI的小馬而言,確認上也能起到不容忽視的作用。


2、webshell確認
想想磚家們們如何確認一個頁面是不是webshell的,打開ta,看看頁面長啥樣,也就是請求回放。在進行請求回放的時候,有兩類問題需要考慮
(1)回放是否會造成破壞性操作,例如造成站點壓力,(好心辦壞事的例子也是有的,例如網站速度監測應用,cc防御應用就會把帶寬小性能小的站點打趴),還有刪除文件、重置賬戶、系統重裝(e.g. /setup-config.php)等操作,這也是為啥不直接回放每條訪問日志的原因之一(當然整體日志量的大小也是原因之一)
(2)回放是否侵犯用戶隱私,嚴格的日志存儲規定不能存儲cookie,post等會涉及用戶敏感數據的字段,或必須做脫敏處理再存儲,然后由用戶授權再查看,當然不存儲的更重要的原因是存儲資源的巨大耗費。
(p.s.有時候我會想如何防止安全人員監守自盜呢,做掃描器(漏洞識別)的,特別是全網性質的,有自己的社工庫,有自己的弱點地圖等,扯遠了)

對于情況(1)采用限速,加上回放內容過濾,cookie認證信息消除,威脅操作過濾,對于情況(2)有點微妙


回放的問題解決了,接下來就是根據回放的響應頁面判斷是否是webshell了。我們先看看響應頁面的類型

(1)響應頁面不為空(對URL發起GET請求后,為一個有內容的頁面)

實例1 webshell登陸口
		

<pre align=center><form method=post>Password: <input type=password name=pass><input type=submit value='>>'></form></pre>

登陸框非常非常見(登陸框集錦
webshell檢測-數據分析 - 碳基體 - 碳基體
實例2 上傳文件型webshell
			

<form action="?cmd=up" method="post" enctype="multipart/form-data" name="form1"> <input type="file" name="file" size="17" class="Input"> <input type="submit" name="Submit" value="提交" class="Input"> </form>



實例3 不需要認證的野馬
webshell檢測-日志分析 - 碳基體 - 碳基體
 
實例4 wso webshell
		

a:4:{s:5:"uname";s:81:"Linux li676-178 3.19.1-x86_64-linode53 #1 SMP Tue Mar 10 15:30:28 EDT 2015 x86_64";s:11:"php_version";s:5:"5.6.9";s:11:"wso_version";s:5:"2.5.1";s:8:"safemode";b:0;}



(2)響應頁面為空
對URL發起GET請求后,響應為空白頁面,帶payload回放(脫敏處理后的)


檢測方案如下圖所示,用到了兩個特征
(5)webshell 行為特征 
抽象webshell形成攻擊的關鍵路徑,將其抽象為數學描述的策略庫,來提取異常
(6)webshell 網頁特征:內容/結構/視覺簽名 
(更多內容可從網頁相似性開始了解)

 webshell檢測-日志分析 - 碳基體 - 碳基體


本人的webshell樣本庫: https://github.com/tanjiti/webshellSample


回顧一下,我們是根據特征來檢測webshell,已提到的特征有
(1)webshell 訪問特征(主要特征) ——webshell提取階段
(2)webshell path特征(輔助特征)——webshell提取階段
(3)webshell 時間特征(輔助特征)——webshell提取階段
(4)webshell Payload特征(輔助特征)——webshell提取階段
(5) webshell 行為特征 ——webshell提取階段
(6)webshell Reponse網頁特征(內容特征/結構特征/視覺特征) ——webshell確認

最后還有一個特征——(7)webshell 攻擊關聯特征

  "如果發現一個站點植入webshell,那遠遠不只一個站點被植入"
“如果發現一個站點被植入一個webshell,那遠遠不只一個webshell被植入”

搜索的優勢在這個時候就可以發揮了,用確認webshell的訪問者特征(IP/UA/Cookie),Payload特征,時間特征進行關聯搜索,像這次xcode事件,360在構建了基礎數據后(這里引用我非常崇拜的楚安一段話“永遠記得,數據基礎設施不是采一堆垃圾進來存下就完了,這背后是完善的數據生命周期解決方案。采集,etl,數據質量,快捷的數據交互這些才是最重要的。)利用搜索將數據關聯起來,按時間線進行還原,講述了個有意思的故事。

補充20151103:講到搜索,有兩個難點:
(1)如何將結果按時間線與行為關聯展示
(2)基礎數據設施建設的如何,比如說使用elasticsearch,保留多久的數據量,索引如何建立,集群的負載均衡等
(說到基礎數據設施建設,超級心塞,先是hadoop碎片化導致的數據傳輸坑,然后再是日志字段飄逸變更的坑,還有不可解釋靠重啟解決了的集群莫名掛掉的坑,所幸身邊有不少朋友提供幫助,特別感謝hadoop小王子

二、實現
1. 數據獲取
數據源:web訪問日志
獲取方式:如果存儲在hdfs里,采用distcp的方式拷貝到模型計算集群上
p.s. 光數據的獲取,就遇到了很多坑,不同版本的hadoop之間的數據傳輸hadoop碎片化的問題,也是工程師文化導向的產物之一,都愛用開源的東西去組裝一套單獨的完整的系統,當然也因此培養出了不少全棧工程師)


2.feature提取
http_host   
root_domain
url
path
query 查詢字符串
referer
ip
timestamp
http_response_code 
http_method
request_body 請求體 非必要字段
cookie 非必要字段
user_agent

3.預處理
 
在統計之前我們需要對數據做預處理
預處理1:按小時切割日志(切割主要是為了避免日志量大的情況下計算時間過長)
預處理2: 提取響應碼為2xx,3xx的日志
預處理3: 特征規范化處理,非常重要,如果不做預處理,將會形成一個超級大的有向圖,mapreduce這種批處理會處理不過來
Host規范化: 將*.xxx.com或.xxx.com 變成 www.xxx.com
Path規范化:歸并多個/,替換\為/
referer規范化
(1)將相對地址還原為絕對地址,e.g. /a.php => www.xxx.com/a.php
(2)將host部分非本域(不在根域名內)、空字段、不符合referer規范的referer字段皆設置為空
(3)去除query部分


4.模型建立
1)webshell提取(全自動)
第一步:建立(path,referer)有向圖,提取孤立頁面(入度為0,出度為0 )與自回路頁面( 入度為1,出度為1,自己指向自己)webshell 的訪問特征
第二步:去除不符合規范的path( 是否符合(?:https?://)?[-./\\w]+)
第三步:去除靜態path(例如jpeg,jpg,gif,png,bmp,css,js,xls,xlsx,doc,xml,wav,tar.gz,zip,swf,mp3,ico,pidf,torrent)
第四步:去除白名單path (例如主頁index.php,index.asp,index.aspx,index.ashx,index.html)
第五步:去除非webshell后綴的path (例如asp,aspx,php,jsp,py,cgi,pl,java,sh,war,cfm,phtml)
第六步:去除掃描器造成的path(按掃描器IP信譽庫(云掃描器IP信譽庫與時效性掃描器IP信譽庫)與掃描器行為(可以簡單的按ip+host聚類,將單位時間內請求數超過M,獨立路徑數超過N的請求視為掃描器)來去除)
第七步:去除響應碼非200的path
第八步:按path特征定義webshell的可信度,符合特征的標記為1(例如常見的上傳文件目錄,隨機文件名)webshell 的path特征
第九步:按webshell payload特征定義webshell的可信度,符合特征的標記為1,等同于WAF中的webshell檢測規則(但要更寬松些,因為不怕誤報),如果日志中有WAF檢測結果標記字段,可以直接用該字段來標記webshell可信度 (例如envlpass=) webshell Payload特征
第十步:去除獨立IP訪問數與path訪問請求總數超過閾值的path 

2)webshell確認
第一步:對webshell 提取的path進行GET回放(限速),若有參數,帶參數回放
(p.s.有些小狡猾的webshell不帶參數回放會顯示頁面不存在)
第二步:去除響應碼非200的path
補充:修改為保留401的請求,避免漏掉通過http basic認證的webshell
第三步:去除404重寫path
方法一:隨機生成2個文件名,回放,看response body的大小是否一樣,若一樣,則存在重寫
方法二:神奇的fuzz hashing又要發揮作用了,可以對重寫的response content求fuzz hashing值,設置相似度閾值,在閾值范圍內的判定為404,例下圖所示,將安全狗重寫頁面剔出
webshell檢測-日志分析 - 碳基體 - 碳基體
 webshell檢測-日志分析 - 碳基體 - 碳基體
 

第四步:對空白響應頁面,進行帶payload的回放(限速與脫敏
第五步:對響應頁面計算fuzz hashing值,并做聚類處理
第六步:讀取weshell fuzz hashing特征值庫,相似度在閾值范圍內的path判定為webshell webshell Reponse網頁相似性特征
第五步:網頁信息提取,分為靜態提取,動態提取,提取title,表單,Link,Image信息(全自動)
第六步:抽象webshell行為的關鍵路徑,制定策略,基于策略庫進行webshell異常提取
第七步:基于webshell樣本簽名(網頁的內容/結構、視覺)的自動化攻擊確認,與人工干涉的對屬于異常但不符合樣本簽名的攻擊確認補漏
第八步:提取確認webshell的訪問者特征(IP/UA/Cookie),Payload特征,時間特征,關聯搜索,將搜索結果按時間排序,還原事件 webshell 攻擊關聯特征

5. 模型評估
一般會用召回率,準確率來評估。但如何確認所有的webshell已檢出呢,我采用在自己站點植入webshell,然后看是否能全部檢出,但這種方式有明顯問題——站點的訪問流量非常態的,待解決。


三、模型缺陷
模型待改善的地方
問題一:referer偽造
問題二:圖片webshell(因為靜態文件的放行)
問題三:已有文件植入后門(因為不孤立了)



四、其他檢測方法
上文介紹了如何通過web日志分析來查找webshell,現在來回顧一下傳統的webshell檢測產品
(p.s.從商品化的檢測技術中總能獲得不少檢測靈感,他們的方法雖然土但有效)

WAF/IDS/IPS:檢測HTTP請求是否符合webshell通信特征(被動檢測)
漏洞掃描器:掃描是否存在已知后門植入漏洞,例如常見webshell路徑,菜刀連接(主動檢測)
后門檢測查殺工具:檢查文件系統中是否存在webshell惡意文件
目錄監控工具:文件完整性監控、關注文件的修改時間、所有者,權限(增加的webshell文件,被植入webshell的已存在文件時間都會發生變化)
SIEM日志分析(取證)工具:檢查是否有webshell的訪問事件 (現有的一般是基于特征與簡單關聯,非常少的用到機器學習方法)

而這些產品用到的技術劃分為靜態檢測方法與動態檢測方法,其實也是反病毒領域采用的方法。

1. 靜態檢測 
(1) 文件內容檢測,檢測是否包含webshell特征,例如webshell常用函數
缺點: webshell 花式混淆繞過
webshell檢測-數據分析 - 碳基體 - 碳基體
 花式混淆參見:
http://weibo.com/p/1001603888457062702792
http://pastebin.com/raw.php?i=ctswucid

檢測方法參見:


(2)文件內容檢測,檢測是否加密(混淆處理)
吸取上面的經驗,增加了通過檢測是否加密來判斷webshell(1,2,3,4都是)

1、重合指數(Index of Coincidence):本質是概率,簡單的說,有意義的詞匯重合指數高,被加密或混淆的字符串的重合指數低
2、信息熵(Entropy):本質還是概率,簡單的說,有意義的詞匯熵值小,被加密或混淆的字符串的熵值大
3、最長單詞(LongestWord):比較粗暴的假設,字符串越長被加密或混淆的可能性越大
4、壓縮(Compression):非常有趣的想法,盡然能想到利用壓縮的原理來描述混淆或加密字符串與常規字符串的區別
5、簽名(Signature):特征匹配,屬于傳統方法


檢測方法參見:
NeoPi方法的國人介紹:
http://www.freebuf.com/articles/web/23358.html
http://www.freebuf.com/articles/4240.html


缺點:
第一篇文章下的吐槽能說明一些問題,第二篇文章正好證明了這個問題
數據分析方法特別是機器學習,更多的時候考慮的是大數據量下的概率指向,對特殊情況的覆蓋率低,但優勢也是很明顯的,只是不能單獨使用。

(3)文件Hash檢測,創建webshell樣本hashing庫,將待檢測文件與之對比,在閾值范圍內的判定為可疑文件
ssdeep檢測webshell (fuzzy hashing檢測)

(4)文件完整性檢測
文件的創建時間(新增文件(新增webshell),修改時間(原有文件注入webshell)),文件權限,所有者
缺點:更新頻繁的站點無法運維

2. 動態檢測
沙箱技術,根據動態語言沙箱運行時的行為特征來判斷

缺點:
加密文件無法執行,寫的很挫(本身有語法錯誤)的文件無法執行

檢測產品參加:

五、結語
這篇文章寫了快半個月了,本人是個收集狂魔,喜歡收集資料,也喜歡收集方法,收集了需要驗證,因此花了不少時間,但這個過程還是蠻有趣的,玩過界(匯集不同領域的特長)的感覺真好。同時歡迎交流,把我罵成狗也沒得關系

后記:
結果真的被人罵了,但罵的原因不是預料的文章寫的渣,技術方案存在問題,而是涉及抄襲的人身攻擊,本人除了寫技術博客,寫讀書筆記,推送我發現的好資料,并未混進安全圈內過,會議不曾參加,聚會更是沒有,著實封閉,也不能自證,于是只能忍了。
http://danqingdani.blog.163.com/blog/static/18609419520158221409771?utm_source=tuicool&utm_medium=referral
 
正文部分到此結束

文章標簽:這篇文章木有標簽

版權聲明:若無特殊注明,本文皆為( mOon )原創,轉載請保留文章出處。

也許喜歡: «利用搜索引擎來進行漏洞批量抓取 php小腳本 | NTDS.dit密碼快速提取工具»

已有2條評論

多多

2015-11-24 11:33 沙發
贊。大贊!

mOon

2015-11-25 14:13
@多多:謝謝
?
?
河北11选5开奖