97年度漏洞檢測
TOP10漏洞檢測 |
|
A1 Cross-Site Scripting |
XSS是一種能夠威脅任何網頁形式的攻擊手法，只要使用者的瀏覽器支援任一種scripting語言便可能受到XSS的攻擊。XSS與SQL Injection同樣都是一種未做好輸入查驗(Input Validation)的問題，即在撰寫程式時，沒有對使用者的輸入做妥善的過濾與處理，便將其顯示成網頁能夠執行的scripting，進而對網頁瀏覽者造成危害。 |
A2 SQL Injection |
SQL Injection是一種未做好輸入查驗 ( Input Validation ) 的問題，即在撰寫應用程式時，沒有對使用者的輸入做妥善的過濾與處理，便將其組合成 SQL 指令，傳送給 SQL server 執行。若使用者輸入之資料中含有某些對資料庫系統有特殊意義的符號或命令時，便可能讓使用者有機會對資料庫系統下達指令，而造成入侵所帶來的損失。事實上，這樣的疏漏並不是資料庫系統的錯誤，而是程式設計師或軟體開發者的疏忽所產生的。 SQL Injection 弱點與威脅主要是因為未作輸入檢查，所以讓攻擊者有機會可以將 SQL 指令送至後端資料庫執行，進一步竊取資料或造成系統破壞。 |
A3 Malicious File Execution |
Malicious File Execution是一種能夠威脅任何網站形式的漏洞，只要攻擊者在引入(include)程式的參數中修改參數內容，網頁伺服器便會引入惡意程式內容而受到Malicious File Execution攻擊。Malicious File Execution與SQL Injection同樣都是未做好輸入查驗（Input Validation）的問題，主要產生原因為在撰寫程式時，沒有對使用者的輸入做妥善的過濾與處理，便將其網頁程式引入網頁伺服器執行，使攻擊者能夠藉由輸入網頁程式，進而對網頁伺服器造成危害。 |
A4 Insecure Direct Object Reference |
Insecure Direct Object Reference是一種能夠威脅任何網站形式的漏洞，只要攻擊者在導出(export)程式的參數中修改參數內容，網頁伺服器便會導出程式原始碼而受到Insecure Direct Object Reference攻擊。Insecure Direct Object Reference與SQL Injection同樣都是未做好輸入查驗（Input Validation）的問題，主要產生原因為在撰寫程式時，沒有對使用者的輸入做妥善的過濾與處理，便將該參數所對應之檔案藉由其網頁程式導出執行，使攻擊者能夠藉由修改程式參數值後查看任意檔案原始碼，進而對網頁伺服器造成危害。 |
A5 Information Leakage and Improper Error Handling |
Information Leakage and Improper Error Handling是一種任何網站常忽略的漏洞，程式撰寫者或管理者的不良習慣，在網站裡遺留會洩露系統訊息的敏感物件，如：備份檔(參考A10-Backup File)、直接瀏覽目錄索引(Directory Indexing)或資訊頁面導致原始碼洩露。此外，對錯誤狀況處理不當的頁面，如：程式語法錯誤或SQL指令執行失敗時，可能在顯示錯誤訊息的頁面，提供了軟體版本、檔案路徑、程式架構、SQL語句…等，讓攻擊者取得更多資訊，進行更進一步的攻擊。 |
A6 Broken Authentication and Session Management |
Broken Authentication and Session Management是網頁應用程式中身份驗證功能有缺陷，導致攻擊者可以針對這些缺陷攻擊。 網頁應用程式透過Cookie的傳輸以完成使用者身份的認證，在通過驗證後，在這次會期間仍持續核可使用者的身分。若只對首次傳送的Cookie加以驗證，當通過身份認證後，程式沒有持續對Cookie中內含資訊驗證比對，攻擊者修改Cookie中的重要資訊，以提升權限進行網站資料存取，或是冒用他人帳號取得個人私密資料。 |
A7 Insecure Communications |
使用者在傳送敏感資訊時，若網站未提供安全的傳輸管道，攻擊者可能利用監聽方法，蒐集使用者的敏感性資訊。 此一攻擊行為常發生於無線網路的傳輸過程中。當使用者使用無線網路時，若在連線時沒有使用加密的技術作資料傳輸，或是Web系統本身未提供任何加密的方法，在瀏覽具有敏感性資料的網站時，例如：網路銀行，資料即相當容易被駭客利用竊聽方式盜取。對此，SSL機制可以在Web server端與使用者瀏覽端建立可靠安全的網路連線，以確保用戶端應用程式與 Web 服務間通訊的安全。 |
A8 Failure to Restrict URL Access |
Failure to Restrict URL Access漏洞發生的主要原因是由於敏感的網頁(例如訊息公告、檔案上傳等後台管理頁面)未經適當的權限管控，使得攻擊者藉由搜尋引擎或是直接輸入連結的方式找出未經保護的頁面，獲得非經授權之使用。 |
A9 Insecure Configuration Management |
ICM為「不安全的設定管理」，網頁伺服器和應用程式的設定值在資訊安全中佔有一個關鍵的地位。這些伺服器是用來提供內容或產生內容以服務使用者的，此外，這些伺服器也可能提供諸如：資料儲存、訊息傳送服務、電子郵件、目錄服務等。一旦設定管理上有問題，將會廣泛的影響到整個網頁服務的運作。 ICM主要針對FrontPage Server Extensions及HTTP PUT Method此2項漏洞。 |
A10 Backup File |
Backup Files為存留在系統內部，通常副檔名為.bak(或是.bk等)的檔案；重要的Backup Files可能有系統資料，而攻擊者通常利用這些備份檔案竊取系統資訊。主要產生原因為在撰寫程式時，將備份檔案放置於網站可存取之處，使攻擊者能夠尋找出這些備份檔案，進而造成系統資訊的洩漏。 |
檢測標的
檢測23縣市政府之相關網站，共計46個網站之TOP 10 漏洞。
檢測工作行程
96年度漏洞檢測
XSS漏洞檢測
XSS是一種能夠威脅任何網頁形式的攻擊手法，只要使用者的瀏覽器支援任一種scripting語言便可能受到XSS的攻擊。XSS與SQL Injection同樣都是一種未做好輸入查驗(Input Validation)的問題，即在撰寫程式時，沒有對使用者的輸入做妥善的過濾與處理，便將其顯示成網頁能夠執行的scripting，進而對網頁瀏覽者造成危害。
檢測標的
檢測25縣市政府之
1. 主網站、
2. 稅捐稽徵處網站、
3. 警察局網站及
4. 衛生局網站，
共計96個網站之XSS漏洞。
檢測工作行程
95年度漏洞檢測
SQL Injection漏洞檢測與修復工作
SQL Injection是一種未做好輸入查驗(Input Validation)的問題，即在撰寫應用程式時，沒有對使用者的輸入做妥善的過濾與處理，便將其組合成SQL指令，傳送給SQL server執行。若使用者輸入之資料中含有某些對資料庫系統有特殊意義的符號或命令時，便可能讓使用者有機會對資料庫系統下達指令，而造成入侵所帶來的損失。事實上，這樣的疏漏並不是資料庫系統的錯誤，而是程式設計師或軟體開發者的疏忽所產生的。SQL Injection弱點與威脅主要是因為未作輸入檢查，所以讓攻擊者有機會可以將 SQL指令送至後端資料庫執行，進一步竊取資料或造成系統破壞。
進行25縣市政府SQL Injection的檢測與修復工作為本專案的重點工作之ㄧ，為積極協助縣市政府單位網站SQL Injection問題修復工作將的進行流程規劃說明如下：
欲檢測與確認系統是否受SQL Injection的威脅，首先須要對於檢測標的進行系統相關資訊的搜集，了解檢測標的系統的現狀，作為決定選用的工具與下一步檢測的實行策略。搜集完系統資訊後，先利用自動化的工具進行掃描與檢測，測試系統是否有SQL Injection的弱點。隨後根據自動化工具檢測結果進行手動的驗證，並將工具無法測試的網頁以手動檢測方法進行確認。由於工具掃瞄部分無法將所有的問題檢測出來，並可能有許多誤判的結果，因此本檢測將以手動檢測為主。最後將搜集到的系統現狀與SQL Injection 弱點的確認結果撰寫成檢測報告，如下圖所示。
詳細的檢測工作流程說明如下：
• 資訊蒐集
資訊蒐集旨在蒐集檢測標的系統現況，主要搜集的項目與說明如下：
蒐集項目 |
說明 |
使用工具或指令 |
Domain Name 與 IP 對應 |
確認檢測目標的 IP 與網域名稱的對應，驗證檢測標的。 |
Nslookup 、 TWNIC Whois |
Web Server |
檢測目標所使用的 Web Server 軟體，以備後續報告撰寫時能夠確認其降低威脅的方式。 |
telnet IP 80 options / HTTP/1.1
|
網頁技術 |
使用何類的網頁技術，如： ASP 、 PHP 、 JSP 等。 |
IE 、 Firefox |
網頁目錄 |
列舉網頁目錄，作為決定檢測標的須驗證 URL 與網頁。 |
Google 、 Paros 、 web spider 、搭配手動方式進行
|
使用的資料庫類型 |
探知後端的資料庫類型，以備後續報告撰寫時能夠確認其降低威脅的方式。 |
由錯誤訊息、 absinthe
|
• 工具掃瞄
蒐集完相關的資訊後，接下來即是建立檢測的列表，包含：所有須要檢查的目錄與頁面等 URL ，請參見附件 1- 2 。此次的 SQL Injection 檢測使用三種自動化掃描工具，分別為： Remote PHP Vulnerability Scanner 、 lilith 、 wpoison ，說明如下：
• Remote PHP Vulnerability Scanner ( 簡稱： RPVS ) ：
用來檢測 php 網頁是否具有 SQL Injection 的弱點，利用下列參數將所有在資訊蒐集步驟所蒐集的網頁目錄與 URL 進行驗證。
Remote PHP Vulnerability Scanner 參數： - bf : 暴力攻擊的變數 - f : 快速模式 - v : 吵雜模式 ( 顯示較多訊息 ) - rapport : 建立 rapport.txt 檔案儲存檢測結果 - sql : 偵測 執行 sql error 不能與 - rapport 選項共用。 ( 須個別執行一次 ) - post : 使用 POST 方法 |
• lilith ：
此工具為一 perl script 所構成的檢測程式， lilith 會掃瞄目標主機目錄下的所有網頁的 < form > 及 < input > 等項目，並輸入部分的 SQL Injection 字串，以檢測該網頁是否有 SQL Injection 弱點存在，利用下列參數將所有在資訊蒐集步驟所蒐集的網頁目錄與 URL 進行驗證。
Usage ： lilith.pl [options] <host> - d < dir > : 設定有哪一個目錄或檔案開始 < dir > ( or file ) [ default : /] - a < agent > : 送出 client 類型。 - u < user:pass > : 驗證用的帳號與密碼 ( 如果有 ) - p < proxy > : 使用的 proxy ( proxy:port ) - U < user:pass > : proxy 驗證的帳號與密碼 - T < delay > : 送出 requests 的 delay 秒數 - f < file > : 外部記錄的檔名 - g : 當檢測有問題時，試著進行攻擊動作 - i : 不要事著進行攻擊的動作 - A : 印出所有檢測的字串與程式碼 ( 顯示許多訊息 ) - v : 吵雜模式 ( 顯示較多訊息 ) |
• Wpoison ：
Wpoison 原本是用來進行 web application 壓力測試的工具，在最新的版本中加入 SQL Injection detection 的模組。 Wpoison 會分析網頁中的所有 < a > 與 < form > 的所有項目，並試著輸入 SQL Injection 字串，然後將 URL 送出給檢測標的，並依據回應的訊息來判斷該頁面是否有 SQL Injection 問題。利用下列參數來進行檢測：
./ wpoison [-R [level]] [-C <cookie value>] [-o file] [-f signature file] url - R [level] : 設定檢測的 web 階層。 - o file : 將檢測的結果利用 HTML 格式儲存。 url : 檢測的標的或 URL |
• 手動檢測
手動檢測分為具輸入介面網頁與 URL 兩類為主，說明如下：
• 具輸入介面網頁
檢測具輸入介面網頁主要以輸入格式化字串來確認，此一部份，僅用簡單的測試方式進行檢測。列舉檢測字串如下：
ASP 網頁 • ' or 1=1-- • " or 1=1-- • or 1=1-- • ' or ' ' = ' • ' or 'a'='a • " or "a"="a • ') or ('a'='a • ' or 1=1 • ' or '1=1 PHP 網頁： • ' or 1=1 • ' or '1=1 • '/* • '%23 // ” ‘#” • ' and password='mypass • id=-1 union select 1,1,1 • id=-1 union select char(97),char(97),char(97) • id=1 union select 1,1,1 from members • id=1 union select 1,1,1 from admin • id=1 union select 1,1,1 from user |
檢測的主要字串為「 'or' 1' ='1 」（字串型別）與「 or 1=1 」（數字型別）等。
• 字串型別
當提供的輸入介面為字串型別時，輸入「 ' or ' 1 ' = ' 1 」或「 ' 」來確認是否能夠通過輸入介面轉化為可執行的 SQL 指令。此一部分須從傳送後的訊息來加以判定，若輸入上述字串並傳送後，回應登入畫面，則表示可能有 SQL Injection 問題；若回應錯誤表示須進一部測試其他字串。或透過 absinth 工具組合成 URL 測試方式來進行檢測。
• 數字型別
當提供的輸入介面為字串型別時，輸入「 and 1=1 」及「 and 1=2 」來進行測試。當輸入「 and 1=1 」傳回正確的頁面與輸入「 and 1=2 」傳回錯誤的頁面，則表示在輸入介面中輸入並送出的 SQL 條件判斷式可以送入 SQL 執行，則該網頁有 SQL Injection 的潛在威脅，反之則否。
同樣的此一部分的檢測可能須藉助 absinth 工具組合成 URL 測試方式來進行檢測。此外，透過檢測的訊息來驗證網頁是否存在 SQL Injection 弱點。並可藉由錯誤訊息來檢測網站的其他安全弱點，如：目錄列表等。
• absinth 工具
absinth 工具提供介面允許進行手動的輸入參數設定來製作 SQL 指令的組合，進行檢測網頁的 SQL Injection 問題。同時該工具亦可協助探知資料庫類型，並利用手動輸入各個網頁表單中輸入選項或隱藏欄位的值，將這些欄位的值串接起來猜測 SQL 指令來達到檢測網頁的 SQL Injection 問題。當檢測的頁面有 SQL Injection 問題時，可藉由 absinth 工具進一步檢測並列舉資料庫的類型與結構，此一部分可能為敏感資訊，故此次檢測儘量不使用該功能，僅利用來測知資料庫的類型。
圖： absinth 工具
• URL ：
URL 檢測分為兩類：
• 字串型別：
字串型別指的是輸入的資料為字串類型，在 URL 中以「＋」或「＆」連接，如：
http://example/login.asp?userid=a'+or+'+'+=+'&pw= a'+or+'+'+=+' |
與具輸入介面網頁檢測相同，只是將輸入的部份，串成網頁 URL 方式傳送至網頁伺服器執行。
• 數字型別：
數字型別為公告、最新消息等網頁中最為常見，通常為下列形式：
http://example/listnews.asp?id=2323 |
進行檢測時，使用下列兩項檢測 URL 輸入：
當 A 傳回正確的頁面與 B 傳回錯誤的頁面，則表示在 URL 中加入的 SQL 條件判斷式可以送入 SQL 執行，則該網頁有 SQL Injection 的潛在威脅，反之則否。
利用手動檢測主要在驗證經工具檢查出有問題的頁面及無法使用工具檢查的頁面，使得所進行的檢測能夠更具準確，避免工具的誤判情況。
檢測的安全問題
此次檢測利用工具與手動的方式進行驗證網頁主機是否有 SQL Injection 問題。測試也不會危及網頁的運作，僅因送出檢測的 HTTP Request ，網頁伺服器的紀錄檔會顯示較多的存取或錯誤訊息。所有進行的 SQL Injection 測試不會有攻擊的行為，而僅是利用正常的網頁存取方式對進行存取，但網站的存取動作次數會較為頻繁，原因為可能對網頁進行反覆驗證。所有的檢測將透過學術網路 140.116.7.141~143 網段進行，因此受測單位可以依據網頁的記錄檔比對檢測過程的進行。同時，我們也將於檢測的結果中記錄下所進行的指令與相關的參數，提供受測單位進行參考。檢測時，由受過 SQL Injection 檢測的專業人員進行，以 2 到 3 人為主，一人負責進行檢測，另一人負責相關的記錄，在國立成功大學中的地方政府資通安全服務中心所設立的管制區域內進行，檢測相關的文件、電子紀錄皆於管制區內儲存與保護。最後的檢測結果，不包含敏感或機密的資訊，但同樣進行嚴格的文件管控，僅提供地方政府資通安全服務中心與技術服務中心人員存取電子檔，並僅以紙本方式交付受測單位參考。
預期檢測問題及成果
經由工具的檢測與手動的驗證與檢測，可以詳盡地檢測標的主機的網站 SQL Injection 弱點是否存在，除此之外，常見的設定錯誤或安全問題皆可依起發掘出來，並提供未來修補或修正時適當的資訊，預期能夠檢測的問題如下：
• 網頁輸入頁面的 SQL Injection 問題，如：登入頁面、留言板輸入頁面等。
• URL 的 SQL Injection 問題，如：最新消息頁面、公告等。
• 設定錯誤，如：顯示詳細的錯誤訊息、目錄列表等。
台南市東區大學路1號成功大學自強校區電機系館9樓92975室 電話:(06)2756555 傳真:(06)2743533