觀點

駭客現形

2011 / 04 / 01
洪肇蔚
駭客現形

一個個西裝筆挺以及身著套裝的男女,快步地穿梭街頭。精明幹練的眼神中隱隱約約地透露出公事繁忙而形成的憔悴。一家頗具知名度的高科技產業,MIS和鑑識人員正揮汗如雨地觀看Snort發出的警訊,在成千上百行的日誌中,試著理出些許頭緒;是的!因為內部使用者資安意識的缺乏和不佳的使用習慣,使得駭客利用已知的瀏覽器漏洞製作出Exploit code(漏洞攻擊程式碼)夾帶惡意程式入侵員工個人電腦,並在短時間內感染其他系統,同時將木馬程式藏匿於中伺機竊取個人重要資訊。事件在初期的危害,雖然可以被內部架設的Snort IDS所擷取,然Snort每天發出警訊的事件量極大,且誤判的情況所在多有,加上管理者資安意識及能力的不足,疏忽了初期的防備而導致災難的開始。
  如何了解並判讀Snort產生的警訊已經是資安人員管理IDS產品的主要能力之一。本文闡述Snort rule各欄位的意涵,分享封包閱讀的經驗,同時提供誤判封包與實際攻擊封包的例子做比較,以提高資訊人員在Snort事件觸發時判斷的精準度,並降低閱讀封包所帶來的困擾。

Snort rule欄位面面觀
  Snort是一套網路入侵檢測系統,可用來偵測網路上的異常封包。Snort 可以運行在*nix/Win32 平台上,它具有即時記錄網路資料封包的能力,能夠進行協定分析,對內容進行搜索/比對並檢測各種不同的攻擊方式,並對攻擊即時警告。而且這些偵測規則是以開放的方式來發展的,所以也可以加入檢查規則,就檢測攻擊的規則數而言,日前查看Snort官方組織公佈最新數據顯示,至今共約為4,313條檢測規則(2005/10/12,註1)。其中包括緩衝區溢位攻擊、阻絕服務、通訊埠掃描、拇指紋拓取(fingerprinting)和CGI攻擊的檢測等等。該產品免費(目前在Snort pattern release上,針對會員和一般使用者採取時間差別性的釋出)且可擴充性高,故維護成本低且易於取得,因此廣為大眾喜愛和使用。Snort歷經廣大社群的維護及改良,如今已經被公認為開放原碼中最成功的產品之ㄧ。市面上出版大筆相關書籍,不在此多加詳述,本篇希望透過封包閱讀的實例,有助於資訊人員從Snort rule欄位及檢測規則判斷事件的真偽。

Snort檢測規則的定義:
Snort的每條規則在邏輯上都可以分成兩個部分:規則表頭(rule header)和規則選項(rule option)。規則表頭包括:規則行為(rule''s action)、協定(protocol)、來源/目的IP地址、子網路遮罩以及源/目的埠。規則選項包含預警資訊和異常封包的特徵碼(signature),當封包內容符合所有特徵碼時,Snort才會執行其規則行為。
下面我們舉例來具體說明規則的定義:
alert tcp any any -> 192.168.1.0/24 111(msg:"mountd access";content:"|00 01 86 a5|";)
這條簡單的snort規則,從括弧外的字串屬於規則表頭部分,括弧內的部分屬於規則選項。其基本格式為:
規則行為 通訊協定 IP位址 來源埠-> 通訊協定 IP地址 目的埠(規則選項)
因此當您看到觸發這條Snort rule所發出的警告時,我們可以用白話一點的口語解釋為:警告!您至少有一台電腦處於192.168.1.X的網段中,發現目的埠111(sunrpc)被任何來源的任何來源埠所存取,且通訊協定為tcp型態,請電腦管理員密切注意。當該單位電腦管理員一看到這個警訊,會即刻檢驗所屬網段的電腦是否有不正常遠端存取行為。它主要用於防禦Sun Unix的漏洞,早期攻擊者利用Sun RPC緩衝區溢位(buffer overflow)問題進行入侵。這個緩衝區溢位可能造成入侵者遠端觸發以獲得root的權限。過去駭客經常藉由該漏洞開啟其它的程式並植入後門,造成政府單位及企業資料暴露在高度風險當中。所以,Snort就像網路監視、警報器一樣,當有非法事件產生,它會忠實地反應第一手資料,使你免於危難的發生。


解開記憶的百寶盒-Tcpdump
  一套完整的大樓保全系統不但要有監視器監看預警範圍的一舉一動,更要有閉路系統隨時紀錄發生的變異,以防事件發生時,人為疏忽、責任釐清歸屬和事後鑑識稽核之用,當然,Snort也提供如同閉錄系統的機制-日誌紀錄-以供未來分析。Snort啟動後,會在硬碟上記錄大量的警報資訊;一個日誌匯總,特定事件的攻擊報告,或某些特定資訊,都能協助你做進一步的研究。不論出於什麼目的,日誌分析可以幫助你從中獲取有用的資訊,以便針對攻擊威脅採取必要措施。你可以指定一個日誌目錄,使用下面的命令把所有的封包記錄到2進位日誌檔格式中:
./snort -l ./log -b
接下來我們就可以使用2進位格式側錄器tcpdump,讀出封包資料並進行分析。
Tcpdump的應用
  Tcpdump用於監聽TCP/IP連線並直接讀取資料連結層的封包。您可以指定哪些封包需被監看、以什麼樣的方式顯示封包格式。它可以幫助我們描述系統的正常行為,並識別出那些不正常的行為。當然,它只是有助於收集特定網段上的資料流程(網路協定類型、方向等)資訊,至於分析網路活動是否正常,那是分析師和管理員所要做的工作。以下讓我們來介紹tcpdump各種語法、條件式及對應封包顯示之方式。Tcpdump採用命令列,它的語法為:
tcpdump [ -adeflnNOpqStvx ] [ -c 數量 ] [ -i 網路介面 ] [ -r 檔案名] [ -s 封包大小(bytes) ] [ -T 類型 ] [ -w 檔案名 ] [ 條件式 ]
以下舉幾個常用的參數幫助讀者了解:
-e 在每列資料上顯示資料連結層的表頭內容。
-v 詳細顯示指令執行過程。
-i (網路介面) 抓取指定的網路介面送出之封包。
-r (封包文件) 從指定的文件讀取封包內容。
-vv 更詳細顯示指令執行過程。
-x 用十六進位碼列出封包資料。
-X用ascii碼及十六進位碼列出封包資料
上述幾個參數必須搭配條件式才能真正閱讀封包內容。Tcpdump利用條件式作為過濾封包的依據,如果一個封包內容符合條件式,這個封包才會被顯示。條件式有以下類型定義,一種是關於型態(type)的定義,主要參數包括host、net、port,例如 host 192.168.10.1是單指一台主機,net 10.0.0.0 則是指一個網段,port 21 則是指埠號。第二種是關於封包方向的定義,主要參數包括src、dst 、dst or src。舉例而言src 192.168.0.2,是指封包來源地址,dst net 10.0.0.0 指監聽目的網段為10.0.0.0。第三種是通訊協定的定義,主要參數包括arp、rarp、tcp、udp等類型。例如 tcp port 21 host 10.20.2.33指明監聽由10.20.2.33這個IP所屬電腦進出tcp協定且通訊埠為21的流量。如果沒有確切指定任何協定,則會監聽所有協定的封包。
  除了以上3種類型的定義之外,您還可以自行定義以下邏輯運算:反相運算“not”、“and”及“or”,組成更強大的條件滿足您的需要。我們利用上述命令及條件式拆解Snort alert所留下的蛛絲馬跡吧!
指令:
Tcpdump –eXvvr 檔案名稱 src 來源IP and dst 目的IP and src port 來源port and dst port 目的port
這條指令的意義是:讀取Snort,懷疑為入侵攻擊之可疑封包檔,並將已知來源位址、目的位址和已知來源埠和目的埠的封包以ascii碼及16進位碼列印出該封包內容,同時詳列指令執行過程。鍵入上述命令列後,隱含在封包內的秘密就可以一覽無疑!真相近在眼前,讓我們一起發掘出問題。

位元大海的一縷真相-封包解析大公開
  記得筆者小時候鄰居裝了一個的警報器,只要有物體侵入監視範圍,必定鈴聲大作。尤其附近野貓常常跳入他們家後院,兩光的警報器經常因此鈴聲大作,吵得大家天翻地覆,附近住家的抗議之下,屋主黯然地拆下該預警裝置。小時候的記憶歷歷在目,Snort的感測器也是相同的道理,網管人員接受大量的警報,在一陣忙碌的觀看、解析封包後,卻一無所獲。最後,Snort本身依照規則庫定義產生的誤判讓管理人員對於大量信息無法信任外,加上對封包內容的不解及看似不相關的片斷資料,導致網管人員一看到Snort警報就會有「狼來了!」的聯想。一旦在最關鍵的幾個封包中出現後門植入或入侵攻擊的特徵及資訊,「狼來了!」的教訓就真實上演。久而久之,這些警訊不但不會成為保護公司網路的最佳利器,相反的,成為網管人員最大的夢靨!可以想見,Snort最後會成為筆者小時候鄰居裝的兩光警報器,它的命運就是被移除。封包判讀已成為網管人員不可不備的重要能力,封包內容可以告訴你一個事件發生的流程,藉著封包上透漏的資訊,甚至可以蒐集到更多的蛛絲馬跡以判斷事件的來龍去脈。筆者手邊有一些Snort真實攻擊封包及誤判封包的紀錄,藉由分析兩者間的差異對讀者在判讀封包的經驗及技巧上有所幫助。
Snort事件:WEB-MISC PCT Client_Hello overflow attempt
有沒有印象這個事件幾乎是所有曾經安裝Snort的人都曾遇到的警訊,原因在於SSL (Secure Sockets Layer) 函式庫的一項通訊協定 PCT (Private Communications Transport) 具有一項緩衝區溢位的漏洞。攻擊者若成功利用此弱點可以取得受影響系統的完整控制權,包括安裝程式、檢視變更、刪除資料或建立一個擁有完整控制權的新帳戶。一旦您啟動SSL加密連線,經過加密後傳輸的字串有可能正巧符合Snort特徵資料庫中所定義的攻擊剖繪,因此您的信箱應該也常被這些事件所觸發的警訊所塞爆!舉一誤判封包範例做解釋:
圖1:False positive Payload

我們找出符合Snort rule ""*01*""字串的16進位碼並依規則推算,發現所謂的警報應是規則符合入侵模式所觸發。顯然的,這只是一個符合Snort定義字串所引起的誤判。但是我們仍不能鬆懈警覺心,透過Snort rule記?的參考資料,回頭看看此漏洞造成的因素(CVE,2003-0719,http://www.cve.mitre.org/),我們發現漏洞產生來自於MS04-011,也就是同樣被Sasser Worm所利用的重大漏洞。如果您已經透過微軟網站下載最新的修正檔,那就恭喜您了;反之,請儘速至微軟網站做Window Update的動作,以確保您電腦最基本的安全。

看過了誤判封包後,讓我們來檢視真正的攻擊封包:圖2:Real attack Payload

在這個案例中,我們從原本近似雜亂無章的加密字串中,意外地發現了有意義的明碼!透過google查詢相關字串(THCOWNZIIS),發現由THC(The Hacker''s Choice)團體所開發的Amap掃瞄器針對該漏洞提供類似的exploit code(注2)。同時,我們從payload中可以看見攻擊封包夾帶的資訊內有意圖向受害端取得一個命令列(command line)作為取得權限後執行資料刪除、變更或中繼跳板主機之用。因此如果觀看此類經由通訊埠443之加密連線封包,請注意有無明碼在payload中產生,因為SSL的攻擊大多會在Server和Client端建立起加密連線時觸發相關弱點,以利駭客執行後續入侵動作。
  
綜合我們以上封包判讀的經驗,如果您對Snort所產生的警訊感到有所疑慮,您可以閱讀封包內容並就以下3個面向來檢測電腦安全性:
1. 您的系統是否已更新patch。
2. 造成Snort事件發生的對象(您的個人電腦)是否安裝該事件指稱的軟體或應用函式庫。舉例而言,如果該事件針對的是win32的作業系統,而您的主機裝的為*nix系統,則事件的產生明顯為誤判。
3. 您從payload中是否觀測到異常狀況。例如文中看到的SSL連線出現明碼或是從不知名網址夾帶一個異常的檔案。筆者常發現一些釣魚(phising)網站先利用瀏覽器的漏洞造成緩衝區溢位,再藉機塞入一個惡意程式以取得受害電腦的控制權。
如果您可以保握以上3點原則,我想大部分的Snort事件您都可迎刃而解,不再為天書般的封包內容所苦惱囉!

結語
  Snort IDS是一套普遍便又好用的入侵偵測系統,我們從Snort rule欄位的基本認識到使用tcpdump解開Snort遺留下的可疑警報,再到真正的解析、閱讀封包內容,不外乎是要告訴讀者,即使在一個不起眼的小地方,你仍有可能挖掘潛在的危機。期望藉由本文分享封包閱讀的經驗,提高資訊人員對於Snort事件更多的認知,同時帶來更多不同的啟發。

本文作者現任職國家資通安全會報技術服務中心工程師