[工具介紹] zone-h

前一陣子看到電視上的一則新聞，說的是公館商圈的店家被不知名人士塗鴉，造成景觀的破壞。老實說，我看了新聞畫面覺得那些塗鴉還蠻漂亮的，也讓商圈顯得更有活力。但是因為這是違法的行為，所以不管好不好看，錯了就是錯了。這種破壞公物的行為，英文有一個詞叫做 Vandalism，或也可以稱之為 Deface 。

網路上有一種攻擊行為，也稱之為 Deface 或是 Vandalism。這樣說也許大家感到很陌生，但是如果我換的說法，我想你一定會發出「喔」的一聲。Deface 就是我們常聽到的網頁置換攻擊，置換的目標通常是網站的進入點(尤其是首頁)。嚴格來說，就像非法的塗鴉一樣，網頁置換攻擊本身其實通常並沒有造成甚麼實際的危害。但是會這麼受到多注視的眼光，正也是它的攻擊結果最容易被看到。所以網頁置換攻擊所帶來的往往不是實際的資料外洩或金錢損失，而是大幅地降低單位的形象。

台灣由於處於特殊的政治環境下，所以常常受到很多各式各樣的攻擊，其中當然也包括網頁置換在內。在各個特殊的時間點(如大選)，網頁置換攻擊更是受到歡迎。因為除了效果明顯外，還很容易自動化，也不像其它攻擊行為需要那麼多的手段或技術。當然，兵來將檔、水來土掩是不變的道理。以網頁置換攻擊來說，最簡單的治標之道就是檢查網頁是否發生了置換的行為。如果有，馬上換回來就是。基本上這是一個好解法，甚至我認為這是所有網站都必需具備的防護機制之一。但是一個最基本的問題在於如何檢查？可以從本機著手，也可以從別的機器進行、甚至是藉由第三方之手加以檢查。 聽起來很簡單，只是現在一個網頁最後呈現的內容可能來自很多地方，包含 HTML檔、Server端的程式 (如ASP.NET、Java、PHP Script等)、Client 端的程式 (如JavaScriot 與 VBScript)、圖片、影片等等…雖然通常置換攻擊是將整個 HTML檔 或 Server 端的程式換掉或插入一段文字，但是難保沒有惡意分子會針對特定的網頁元素加以置換。所以如果要從本機確保所有內容來源的正確性，有時候是一個不小的工程。那個換個做法，因為惡意份子最後是要讓置換後的結果顯現在使用者的眼前，所以就用外部的電腦將網頁抓回來，看看是不是有問題不就好了。是的，但是甚麼叫做有問題？如果一個網頁的內容都固定不變，那麼只要有任何變動就是有問題。但是現在已經很少有網頁的內容都是固定不變的，所以要如何找出有問題的部分就是一個挑戰。

這些技術性的問題，其實都不是無法解決的難題。我認為檢查機制的問題在於它往往掩蓋了攻擊能夠成功的主要原因，讓管理者誤以為沒有任何安全問題存在，或者是當作不需積極處理的安慰劑。甚至除了檢查機制之外，就忽略了其他防護機制的必要性，因而導致在未來的某個時間點發生更大的災難。這樣的說法可能有失公道，畢竟這不能說是檢查機制的問題，而是管理者的觀念與心態問題。

有一個很有趣的網站 zone-h ，它提供了一個置換攻擊受害者的資料庫。這個資料庫除了有受害者的網址與被發現的時間，甚至還有事發當時的網頁快照。這種在被害者傷口上灑鹽的行為雖不厚道，但是卻也提供了我們一些可供參考的數據。這個資料庫也支援簡單的查詢功能 (ENABLE FILTERS)，可以找出特定的時間或特定的網址。如果你剛好需要研究有關網頁置換攻擊，這將會是一個相當方便的工具。

即時更新網頁置換攻擊受害者清單

查詢功能 

受害者的基本資料以及事發當時的快照 

Alternate Data Streams (二)

在前一篇文章中，我針對 ADS 做了基本介紹。在本篇文章中，我將繼續此一話題，並將介紹重點移至如何實際進行 ADS 的相關操作。篇幅有些長，但是因為大多是截圖的關係，所以在閱讀上應該是不會花費太多的時間。

1. 首先我們建立一個空的目錄(D:\ads)，並在此一目錄下進行測試。
   
2. 我們產生一個一般的文字檔，內容是”Hello World”，大小為16位元組。
   
3. 透過 type 指令確認檔案內容為”Hello World”。
   
4. 接下來我們使用下列指令產生 ADS 資料，其中 hello.txt:hidden.txt 表示將名為 hidden.txt 的 ADS 資料附掛在 hello.txt 上。檔案內容為 “I’m Hidden”。
   
5. 檢查一下檔案，雖然時間變了，但是大小卻沒有變。
   
6. 查看原始檔案內容，同樣沒有任何變動。
   
   
7. 使用 type 指令如法炮製，看看 ADS 內容是甚麼。很不幸的，系統顯示找不到這個檔案。難道是指令下錯了？
   
8. 改用記事本試看看，沒有錯誤訊息。
   
   
9. 筆記本顯示出我們原先輸入的內容，而且注意檔名正是 hello.txt:hidden (最後一個txt的副檔名被記事本自動隱藏了)。由此證明雖然 hello.txt 的檔案大小沒有改變，而且 type 指令也無法顯示，但是我們剛剛輸入的資料確實被儲存在 ADS 中。 事實上，使用其他應用程式也可以看到這個檔案的內容。
   
10. 一個檔案可以擁有多個 ADS 資料，而且不需要同樣的類型。我們將一個執行檔 (calc.exe) 覆掛在 hello.txt 中，原先 hello.txt 已經有另外一個 ADS 資料，名稱為 hidden.txt 。 
    
    
11. 雖然之前我們曾經使用 dir 指令時無法看到任何有關 ADS 的資訊，但是其實 dir 有一個參數 - /r 可以用來查看 ADS 資訊。透過 dir * /r 指令我們確認 hello.txt 有兩個 ADS 資料。不過很可惜的是， /r 參數在Vista 之前的 Windows 版本是不提供的。
    
12. 我們嘗試直接執行儲存於 ADS 內的檔案，系統出現錯誤訊息。
    
13. 上網查詢，可以找到程式啟動的方式必須透過 start 這個指令，執行後卻同樣出現錯誤。 如果你出現跟我一樣的錯誤，恭喜你，表示你的系統至少不是很舊的系統。
    
    
    
14. 為了證明資料不假，我特定找了一個 Windows 2000 的系統，並將小算盤 (calc.exe) 覆掛在 xcopy.exe 的 ADS (ADS 名稱為 hidden.exe) 中。同樣的，直接執行會出現錯誤，但是使用 start 指令可以正確的呼叫出小算盤。
    
    
15. 查看執行程序，可以看到 xcopy.exe 在執行中，卻看不到 calc.exe 在執行，可是實際上真正執行的程式是 calc.exe。此為一大問題，表示 ADS 的檔案就算被執行了，也無法從工作管理員中看到，而且不需要使用到 rootkit 的技術。  
    
16. 如果你以為只有舊系統才會有這個問題，新系統已經免疫了，先別高興得太早。我們先將一個名為 hfs.exe 的檔案附掛在 calc.exe 的 ADS 之中以備測試。
    
17. 使用 start 指令依舊失敗，這次我們改用 runas 這個指令來啟動程式。
    
    
    
18. hfs.exe 被正確啟動了，而且是在 Vista SP1 的環境下。
    
    
19. 唯一值得慶幸的是在工作管理員的顯示名稱為 calc.exe:hfs.exe ，而不再僅是 calc.exe 。 
    
    
20. 當我們嘗試複製包含 ADS 資料的檔案時，ADS 資料也會被一併複製 (只要目的磁碟區也支援 ADS 的功能)。我們看到透過複製的指令 hello2.txt 包含與 hello.txt 相同的 ADS 資料。
     

透過前面的例子，我們看到儲存於 ADS 的資料不但不容易被發現，而且可以被正常的讀取、修改、甚至是執行。雖然微軟也確實做了部分的修正，來避免原先 ADS 可能造成的損害，但是卻不是全面的。以我個人的看法，這樣部分的修改比原先不修改可能還來的更差。原因是這樣會造成更多不一致的現象(尤其是同一個系統內的不一致)，而不一致往往造成使用者的混淆，甚至誤解，因而衍生額外的問題。

除了透過微軟內建的指令外，也有一些第三方的工具可以處理 ADS 的資料。像 Alternate Data Stream Tools for NTFS 這個工具可以掃描並列出系統中所有的 ADS 資料，算是一個很方便的小工具。

Alternate Data Streams (一)

雖然說 NTFS 問世至今已經經過了 10 多年，但是有一個功能卻依舊很少人知道。嗯，或許應該說一般正常使用者很少知道。這個功能叫做 Alternate Data Streams，簡稱 ADS 。用白話的方式來說， ADS 允許一個檔案可以挾帶其他的資訊，而這些資訊當初的規劃是為來做為 Metadata 使用。很玄，我也承認。因為在日常的使用中，根本沒有那個應用程式會利用到 ADS 。甚至連微軟自家的檔案瀏覽器都無法顯示這些資料的存在，更別說可以新增或修改了。

為了瞭解此一設計的初衷，我查了一下資料，才發現這並不是微軟自己的發明，在不少檔案系統都有類似的設計。這類的 Metadata 可以用來儲存顯示檔案的圖示，也可以用來儲存文書檔案的顯示格式，乍聽之下好像還道理的…但是好像也不是那麼有道理。不管如何，ADS 依舊是一個不為一般人知的祕密，也沒有給我們帶來任何的改變。

不過也因為雖然檔案系統支援這樣的功能，但是在絕大多數的應用程式都無法使用此一功能的情況下，利用 ADS 加以儲存的資料幾乎可以說是隱形的，所以成了用來隱藏不希望別人發現的資料的方法。這樣的隱藏方式雖然不錯，但是有幾個比較大的問題，一個是這樣的隱藏在支援 ADS 的程式下是沒有任何效果。另外一個就是如果要隱藏一大堆的檔案、甚至於是目錄，這樣的方式並不適合。最嚴重的問題是當原始檔案被刪掉後，這些隱藏資料也會被一併刪除。所以除非你自己有很好的記性，不然就可能是欲哭無淚了。

一般情況下我們想要隱藏資料，可以選擇像是 Invisible Folders 這類的軟體，不但使用上更為方便，而且效果也較好。那麼，誰適合用 ADS 來隱藏資料呢，或者說必須使用 ADS 來隱藏資料？答案通常是那些不懷好意的分子(例如駭客)。所以病毒可以掛在某個正常檔案的 ADS 內避免被偵測，後門程式也可以，駭客慣用的小工具也可以。不管是哪一類檔案，都是為了避免被輕易發現。雖然通常 Rootkit 也具備有相同的功能，但是 ADS 使用上更為簡單，也不會造成系統任何異常或不穩定的現象，而這些都是駭客會加以考量的要素。

像這種實際使用與原始初衷相差甚遠的例子也不算少見，就像水可載舟、亦可覆舟一樣，好或壞完全取決於使用者的心態。微軟也確實做了一些改變想要避免產生嚴重的危害，但是效果畢竟還是有限。在下一篇的文章中，我們來實際看看 ADS 的使用方式。

網路也有假警察

不知道你是否曾經在上網的時候跳出一個視窗，視窗的內容只有幾個大字(有時還加上一個大大的警示圖示)，內容是告訴你你的電腦被惡意程式感染了。如果你曾看過，不知道你當下的反應是甚麼？如果你選擇直接關掉這個視窗，有兩個可能性，一個是你已經練就處變不驚的能力，另外一個就是你有看沒有懂(因為這種視窗的訊息通常是英文)。記得我第一次看到這類訊息的時候，心裡還真緊張了那麼一下。不過我當下的選擇當然不是點選上面的連結，而是開啟我安裝於我電腦內的防毒軟體進行掃描。是的，那個年代還是一套防毒軟體就可以應付大多數情況的年代。掃描的結果當然是沒有發現異常，心裡也因此總覺得怪怪的。只是在幾次之後，就真的也就見怪不怪了。但是，如果你選擇了相信它，進而點選了上面的連結，通常下場就是引狼入室。也就是本來沒有惡意程式的存在，但是因為下載了所謂的移除軟體，而此移除軟體本身才是惡意程式。

上述的方式其實跟現在很流行的假冒成警察或檢調單位的詐騙行為很類似，都是利用威脅的手段促使受害者失去判斷能力，進而達到後續的欺騙目的。而這樣的威脅跟拿刀子架在你脖子上的威脅完全不一樣，因為如果你看到刀子，就知道這一定是不懷好意。雖然通常你也會加以屈服，但是那只是表面上的，心裡面可還是會想辦法逃脫。就算無法逃脫，也會在事後馬上報警處理。但是前者的威脅，卻有可能讓受害者信以為真，所以一時之間沒有採取任何防範措施。其結果就是造成更大的損害，或是讓詐騙分子有更多的時間加以脫身。而以網路而言，大部分問題屬於前者，也就是讓損害持續加以擴大。

這類的軟體有人將之稱為威脅軟體 (ScareWare)，利用的正是社交工程的一種手段。嚴格來說，威脅軟體本身並不一定會造成真正的危害，通常造成危害的可能是後續下載的程式。而這類只威脅、卻沒有後續危害動作的程式又稱之為惡作劇軟體 (Prank Software)。當然，有些威脅軟體並不需要額外下載另一個程式，本身在威脅過後就可以馬上”提供”惡意的服務。像前幾天微軟公布了一個叫做Win32/InternetAntivirus的惡意程式，不但冒充成防毒軟體，還製造出假的掃描結果，試圖引導使用者購買另外一個完全沒作用的軟體來解決”問題”。除了騙人之外，這個軟體當然也會順道偷走一些資料，例如帳號/密碼。

面對這類社交工程手段的攻擊方式，最基本也是最重要的就是小心謹慎。對於任何不正常的狀況(上網兼做電腦掃描？)，都應該保持警戒。當然，不要任意下載軟體也是必要的防範措施。尤其在發生問題的時候，可別病急亂投醫。如果你已經有習慣使用的安全軟體，請記得向它求助。如果沒有，就求助於知名的產品(但是千萬要確保取得來源的可靠性)，而不是Google上不小心搜尋到的軟體。因為這年頭除了有假警察，也有假醫生的存在，不可不慎。

百密可別一疏 - 如何做好全面的Input Validation

Social Web這兩三年很紅，紅的不只是其受一般使用者歡迎的程度，而且也絕對是駭客的新寵。我個人雖然不常使用Social Web，但是或多或少還是無法避免，Facebook是我使用的其中之一。Facebook除了官方的功能，還提供了許多第三方開發的應用程式，這也是Facebook這麼熱絡的原因之一。話說這天我收到一個朋友發出的應用程式使用邀請，接受邀請想加入後不得了，出現了惡名昭彰的SQL錯誤訊息。雖然直接秀出SQL是不被接受的行為，但是我可也沒放棄這個機會。我稍微看了一下，原來就是’這個符號沒有處理好，而’這個符號剛好對SQL語法而言有重大意義。但是我再仔細想了一下，Facbook因為是全球性的網站，個人資料有’這個符號應該也不是完全不可能，至少我就看過人名是有’這個符號的。而我個人資料有’這個符號是出現在家鄉的省份(T'ai-pei)，難道這個欄位有免受檢查的特權？所以，為了測試我的想法，我又申請了一個帳號測試這個問題。我這次申請的帳號除了所在地區同樣帶有’外，連姓名也加上了’，測試結果顯示姓名的’被移除了。雖然移除不是一個好的選項(因為這樣姓名就變了)，但是至少不會造成程式執行的錯誤。所以應用程式的開發者的確知道該檢查使用者輸入的資料，但是卻沒有檢查到所有該檢查的資料。所以，就有了今天的主題。

Facebook應用程式的錯誤訊息

如果你從事過軟體開發的工作，或接觸過軟體開發的工作，不管有沒有實際的經驗，至少都聽過一個很重要的建議，那就是要記得檢查使用者輸入的資料。這個建議成為人人朗朗上口的推手，一個很重要的因素就是Web的流行。因為Web的特色就是使用者的輸入來源各式各樣，而且都是不可控制的。也因此有許多的攻擊方法，基本上都是利用忘了針對使用者輸入的資料做檢查而產生的漏洞。像是鼎鼎大名的SQL Injection、Command Injection、XSS、CSRF等，都跟這個問題有或多或少的關連。

這句話聽起來很簡單，而且很也容易懂，但是有兩個很重要的問題需要釐清。第一個問題是甚麼叫做好的檢查方式，或者說是足夠安全的檢查方式。第二個問題則是有哪些資料應該檢查。在這篇文章中，我想針對的是第二個問題加以討論。

所以，有哪些資料需要加以檢查？使用者輸入的資料，以Web的系統來說，大家通常最先想到的就是URL 參數(Get 方式)與Form Data(Get/Post 方式)。因為這是主要用來接收使用者資料的兩種方式。在Form Data有一個特別需要注意的地方，就是隱藏欄位也同樣需要檢查。雖然一般使用者在正常的使用中無法看到與修改隱藏欄位的存在與內容，但是駭客既不是一般的使用者，通常也不會用正常的使用方式，所以隱不隱藏對有心份子來說是沒有任何差別的。

除了這些顯而易見的資料外，其實還有一個地方也是在使用者的完全掌握之中，那就是Cookie。雖然Cookie一般存在檔案中、有時甚至存在記憶體中，所以不方便或不可能直接修改其數值。但是HTTP協定的問題就是在於傳送Cookie時是不做任何加密的動作，所以任何人都可以攔截Cookie的內容，甚至是修改Cookie的內容。說任何人當然是誇張了點，但是在技術上並沒有甚麼特別困難之處，只消一個Intercepting Proxy (如WebScarab)就夠了。

Okay，Cookie我們也檢查了，可以放心了嗎？還不夠！HTTP協定中還有一種資料也是在使用者的掌握中，那就是HTTP Header。雖然我們在大部分的情況下不會使用HTTP Header的資訊，也不會直接利用它來處理使用者的資料，但是這類問題的嚴重依舊不可忽視。

使用者可以直接控制的資料都檢查過了，天下應該太平了。是的，只不過這已經是過去的美好時光。在現在的Web環境下，Web應用程式已經不再是一個單一的系統，而是由各式各樣的Widgets、Mashups等小元件所共同組成。這些小元件的特色就是由不同的人所開發，開發的語言甚至可能不同，種種得不同都代表了這些元件不受主要網路服務提供者的管理與潛在的安全問題。此外，分享的內容也由原先單純的文字，演化到圖片、網誌、影片等各種形式，而這些分享的方式與內容，也可能造成安全的危害。所以，光檢查使用者輸入的資料已經不再足夠，而是要檢查所有透過不是由你(的程式)所直接控制的資料來源所取得的資料。這些資料包括(但不侷限於)從其他網站所獲取的資料、檔案(尤其是使用者上傳的檔案)、資料庫的資料(這是一個特例，即使資料庫是”自己的程式”所維護，也需要加以檢查)、E-mail等。

回到Facebook應用程式的例子，我們發現其實T’ai-pei那串文字並不是使用者自行輸入的。我原先輸入的是Taipei，但是系統對應出來的選項卻是T’ai-pei。也或許因為這個字串是由系統產生的，所以應用程式的開發者就假設這個資料是安全的，所以也就認為不需要檢查。很可惜的是，這樣的假設是不成立的，所以就出現了這樣的錯誤。

有問題資料的乃是系統產生的字串

在2009 CWE/SANS Top 25 Most Dangerous Programming Errors中所公布的第一個錯誤正是不適當的輸入驗證(Improper Input Validation)，而其對於哪些資料需要加以驗證有下列文字加以說明

“Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, request headers as well as content, URL components, e-mail, files, databases, and any external systems that provide data to the application. Perform input validation at well-defined interfaces.”

在SANS公布的內容中，針對如何加以檢查也有完整的說明，有興趣的讀者就請自行參考了。

相關連結：

• 2009 CWE/SANS Top 25 Most Dangerous Programming Errors