IT X 4

本文刊登於 RUN!PC 月刊 2009/05 184 期

 

筆者認為，一個強大的技術如果無法應用於周遭，那此技術就真的是雞肋了，接下來將會開始深入介紹稽核於各方面的應用，讓原本認為 Windows 稽核是雞肋的人們化解對它的誤會。我們先以兩個真實案例做開頭，讓各位讀者先為WEB與稽核的關係暖暖身。

WEB 與稽核的關係

• 於協同作業面來看
  在有許多 WEB 設計師與程式設計師的環境中，有時會發生「蓋錯檔」的事情，且每次問每次都沒人承認。程式人員將版面套上程式後，想說可以下班了，但因網頁設計人員的粗心大意不小心將檔檔蓋過去，導致之前套的程式都付之一炬，只好加班重新套程式。以上事情最常發生在沒有版本管理的多人團隊中，就筆者本身就遇過兩次檔案被蓋，那種心情瞬間會覺得昏天暗地，只有親身體驗才能感受其中啊！偏偏又沒人承認更叫人氣結，只好自認倒楣，在沒有加班費的夜晚重套嗎？不，事情可以更明朗化。雖然我們常說：「先不要追究責任歸屬，應該先將眼前問題盡速解決」，但是…往往在解決之後起因追查也跟著不重要了，息事寧人讓團隊心結與低壓氛圍越來越擴大，造成工作效率的降低。當然，在此要說明這裡只是舉個團隊中常發生的案例而已，不是每個網頁設計人員都會這樣的。
   
• 於網站安全面來看
  當發現網站目錄中總是莫名的多出幾個檔案，系統組態常常被變更，核心元件檔案總是搞失蹤時，那很肯定的…系統中一定有後門存在！朋友在一個匆忙的下午中緊急以MSN訊息詢問：「我們稽核也進行了，安全性都導入了，設定也依照標準安全設置完成，MBSA的掃描一切都 Pass，為什麼客戶網站還是一直被竄改？在這樣下去這個月的款項可能請不到，拜託幫個忙吧！」。在這個案例中，所有的準備都OK了，MBSA的掃描也都是PASS，問題從何而來？我們將會在下面說明前因始末與處理方式分享。
   

WEB變動痕跡追蹤
WEB 目錄中的檔案變動一向是很難掌控的，尤其可讓使用者上傳檔案的站台更相形複雜。上面提到，在多人團隊中的網站維護老是被蓋錯檔，且追查不易。其實在這個案例中，我們可以對WEB根目錄設定「物件存取稽核」，並將所有可更新網站人員全員加入至稽核清單中，配合適當的稽核設定，即可在當下找出粗心的人。找到對事情會有幫助嗎？當然是沒有幫助的…但至少可讓這名粗心的人員了解到「一切的行為都會有證據」，除了請該人員下次務必注意外，也讓想賴的人賴不掉，並請求它與程式設計人員一同加班到完成處理為止(了解深夜加班的無奈)。

如果是要針對一般WEB上傳檔案進行稽核，要稽核的帳號就比較特別點，要將[Network Service]帳戶加到稽核清單並設定適當的稽核項目，即可在記錄中看到經由 WEB 上傳的檔案。如有發現允許副檔名以外的檔案被上傳，可能就是程式的邏輯出錯了，要盡快聯絡相關人員進行修正。但不是程式出錯的話呢…除了 Windows 本身的稽核機制外，還要加上內建的工具進行人工稽核，來抓出WEB”鬧鬼”的根本原因了。

 

實戰！找出系統的後門！
筆者的朋友緊急詢問的異常現象是怎麼回事？系統檔案莫名消失與增加是靈異現象嗎？其來自有因，這個案例中除了要從 Windows 的稽核紀錄來分析外，還需要搭配 WEB Server 的 Log 進行交叉比對，透過多重來源的稽核分析找出事發時間有在活動的「犯人」。

• 稽核好幫手-LogParser
  LogParser是微軟所推出的免費Log分析工具，可分析的Log類型有IISW3C、NCSA、IIS、IISODBC、BIN、IISMSID、HTTPERR、URLSCAN、CSV、W3C、XML、EVT、ETW、NETMON、REG、ADS、TEXTLINE、TEXTWORD…等，而筆者最常用的是 IISW3C 與 EVT 的紀錄分析。LogParser 分析語法是以 SQL 語法的方式進行撰寫，熟悉SQL語法的讀著們應該可以很輕易的上手。在接下來的稽核過程中，LogParser占了很重要的角色，熟練的使用它絕對可以輕易找出線索。
  
  由於系統方面都已經確定其安全性設置，MBSA也顯示PASS，追查方向則從系統轉移至WEB。WEB的檔案從何查起？每一個檔案副檔名都是 aspx，目錄又有好幾個階層，這種狀況下檔案比對的效果很有限，用所謂的 “人肉搜尋” 又太浪費時間，沒有更好的風法嗎？別忘了LogParser可支援Windows Event 與IISW3C的LOG格式，只要了解簡單的語法即可開始追查。
  
   
• 找出異常存取紀錄
  第一次使用LogParser時，最常遇到的問題就是不知道需選擇哪些欄位與來源，請放心，絕對沒有想像中的那麼難。SQL語法有個特色，當不知道欄位需選擇什麼的時候，只要輸入「*」所有的欄位就會全數選取了。同樣的，我們要開始選擇安全性紀錄時，可以這樣下語法：
  

  ::切換至LogParser工作目錄並進行一筆資料的輸出 CD “C:\Program Files\Log Parser 2.2” LogParser.exe -i:evt -o:csv "select top 1 * from security > C:\Audit.csv

  
   

接下來至輸出的目錄開啟csv檔案即可看到第一列的資料欄位名稱，這邊挑選 [TimeGenerated], [EventID], [Message]，而新增檔案的EventID於稽核紀錄中為 “560”，將此條件納入查詢語法，撰寫成以下的 T-SQL：



Select TimeGenerated, Message From security Where EventID='560'


將以上語法另存成 .sql檔案備用(這裡存在C:\560.sql)，並開啟LogParser查詢介面後，輸入以下指令：



LogParser.exe -i:evt -o:csv "file:C:\560.sql" > C:\FileName.csv




透過將查詢分析語法先存成 SQL 指令檔，可以讓較長的查詢語法更好修改與撰寫，建議在使用 LogParser時可先測試語法，在測試完成後將SQL指令另存，日後才可方便修改。

剛剛的查詢語法為我們選取出新增資料的紀錄，我們拿其中一個來剖析看看是否正常。下圖的資訊說明事件來源為安全性記錄中的物件存取事件(ID:560)，並由使用者 NETWORK SERVICE (IIS的處理緒帳戶)上傳AddRoute.bat的批次檔，在WEB目錄由IIS的處理緒上傳bat批次檔？這個紀錄怎麼看都覺得奇怪，一定要好好的深入追查！

 

圖1    事件ID 560中的重要項目


現在，讓我們把事件描述重點深入分析一次：


表1    稽核事件重點節錄



看來後門就是來自於 WEB 了！確定標的之後就可以針對範圍進行分析，減少猜測與嘗試的時間成本了。接下來，把這個事件的發生時間 “” 記錄下來，我們要用此時間再對IIS LOG進行交叉比對，看看這個時間內是否有可疑的程式存取。

 

• 時間範圍比對
  接著進入了IIS LOG分析的階段，照慣例的我們將語法寫成SQL並存成C:\IIS_Analytics.sql，其中 From 來源為IIS紀錄的目錄：
  

  select date,s-ip,cs-method,cs-uri-stem,c-ip,sc-status from C:\WINDOWS\system32\LogFiles\w3svc1\*.log where date='2009-04-11' and cs-uri-stem like '%.aspx%'

  
  眼尖的人會注意到日期是”2009-04-11”，為什麼不是”2009/4/12”？IIS的LOG是以格林威治標準時間(GMT 0)為記錄，台灣的時區為 GMT + 8，因此時間要減8小時。此紀錄由於是跨日，所以減去8小時候就是前一天，如果在IIS選項中有勾選”請使用本地時間為檔案命名”的選項則不在此範圍內。

我們再一次將查詢語法組合起來並輸出一個CSV檔案來查閱：




LogParser.exe -i:evt -o:csv "file: C:\IIS_Analytics.sql"



查詢的結果發現在WEB中的img目錄有aspx執行的紀錄，怪哉，一般人不會把網站應用程式放在這個目錄，看來有必要好好分析 “/img/aspxspy.aspx” 這一隻程式。

圖2    LogParser分析出的可疑應用程式與存取IP。

 

• WEB被植入Rootkit
  將上一節所分析出的路徑於瀏覽器中執行時，赫然發現是相當有名氣的 WEB Rootkit。這支 Rootkit 功能非常強大，除了可上傳檔案以外，還可隨意刪除磁碟中的檔案。只有這樣而已嗎？不…還可透過 WEB 直接對伺服器下 Command，如果上傳的是惡意的批次檔，就可直接從WEB執行，很可怕吧。
  
  

 圖3    WEB Rootkit 的上傳介面，幾乎什麼都可以上傳

 

圖4    連 Command Line 的 dir 指令都可完整呈現

 

 

後續處理
當務之急先將所有類似的檔案全部刪除，但保留一份檔案下來以供作為證據。接著，使用此 Rootkit的攻擊者一定還會繼續使用，而檔案已經移除了，所以存取之後會產生IIS LOG的404紀錄。後續只要針對其IP與存取進行追蹤，就看各位的公司政策如何處理了。這個案例持續追蹤的結果出人意料，據說是之前的維護廠商將此程式放至於WEB目錄中，因後面的合作鬧得不太愉快，所以在解約之後就一點一滴的進行破壞。目前已經進入法律訴訟程序，但因證據確鑿，筆者覺得廠商那邊應該沒什麼可以辯駁的了，歹路真是不可行啊。

 

後記
利用多重來源交叉比對的稽核可以非常準確從各面向找到證據，進而保護公司的安全與資產。當然，因為機密的關係無法放上真實案例的截圖，只能以筆者家中的伺服器來模擬"案發過程”，在實際的環境中 CSV 可不是像文中的那麼簡單可用肉眼分析，但只要累積更多的實務經驗則可以更精準的下正確的分析語法。要將企業害蟲遠離我們所保護的環境中，就讓稽核來幫助吧！

如果覺得這篇文章對你有所幫助，可以透過 Paypal 支持作者唷~