如何修復網站與作業系統常見之漏洞與弱點

手機版選單

下方連結

如何修復網站與作業系統常見之漏洞與弱點

卷期：v0023
出版日期：2012-12-20

作者：游子興 / 臺灣大學計算機及資訊網路中心網路組幹事

在 Internet 提供各種服務如 Web, Email, FTP之機器，因為需提供24小時之不中斷服務，因此非常容易成為駭客攻擊之目標。本文主要在介紹如何利用常見之弱點掃描軟體，快速尋找系統或程式可能存在之弱點與漏洞，並提供修正建議，進而提高 Internet服務運作之可靠性。

前言

本文將以 Linux Distribution: CentOS 5.x 為例，搭配兩套常見之弱點掃瞄軟體，IBM Rational AppScan 與 Nessus，快速尋找系統或程式可能存在之弱點與漏洞，並提供修正建議。

IBM Rational AppScan 主要針對 Web application 服務之弱點進行掃瞄，使用方法為提供一個起始 URL，AppScan 會搜尋相關之連結找出所有網頁，接著分析每個網頁之內容與特性，若為動態網頁(可供使用者輸入)，則會使用內建之各種測試模組進行測試，此種測試方法又稱為”黑箱測試”，因為測試程式並不需知道程式原始碼及其撰寫邏輯，就把整個網站當成一個黑箱，而不斷嘗試使用各種方法掃瞄是否存在漏洞。

圖1:： IBM Rational AppScan 之操作畫面

Nessus 則是全面性的掃瞄系統提供之服務，目前最新版本為 Nessus 5.02，提供之掃瞄模組稱為 Plugin，主要依據不同之作業系統、服務、攻擊方式…等分門別類，目前版本共提供 Families:44 Plugins: 51388 之各式弱點掃瞄。

2：Nessus 提供之掃瞄模組介面
　

IBM Rational AppScan 弱點掃瞄

首先進行 IBM AppScan 弱點掃瞄，掃瞄所需時間主要依據網站之網頁多寡與網頁是否有可輸入之動態欄位而定，時間在半小時到數小時之間。
掃瞄完成之結果報告會依照 URL 匯總存在之弱點個數：

圖3：IBM Rational AppScan 掃瞄結果摘要
　

以下針對掃瞄結果嚴重性：高與中的弱點逐一進行分析與解決。
AppScan偵測之漏洞： XSS Scripting 跨網站 Scripting
依據 AppScan 掃瞄結果，網站有 XSS Scripting 之高風險漏洞，報告摘要如下：

圖4：XSS Scripting 漏洞摘要
　

XSS Scripting是十分常見且危險性頗高的一種漏洞，程式設計人員若沒有稍加留意，非常容易寫出具有 XSS Scripting 漏洞之網頁。以下以一個簡單的帳號密碼登入網頁之 PHP 程式，說明何謂 XSS Scripting 漏洞：

圖5：帳號密碼登入驗證網頁
　

login.html 網頁程式內容：
<form name="theForm" method="post" action="login_submit.php">
login: <input type="text" name="login"><BR>
passwd:<input type="password" name="passwd"><BR>
<input type="submit" value="login">
</form>

若帳號密碼輸入錯誤，網頁提示錯誤訊息：”您輸入的帳號： davis-test 錯誤!”

圖6：登入錯誤之提示訊息
　

負責驗證帳號密碼之網頁 login_submit.php 內容：
<?php
if ($_POST['login'] == 'davis'){
echo "驗證成功";
}
else {
echo "您輸入的帳號： " . $_POST['login'] . " 錯誤!";
}
?>

上述程式已簡化驗證之部分，重點在後半段帳號密碼輸入錯誤時之訊息提示，此段程式就隱藏有 XSS Scripting 漏洞。

若試著在 login欄位輸入： <script>alert('test')</script>

圖7：login欄位輸入含有 Java Script 之程式 Code

按下 login 按鈕後，網頁直接跳出 Java Script 之訊息視窗 “test”如下圖：

圖8：出現Java Script 訊息視窗

上述結果表示此網頁可執行使用者自行定義之 Java Script 程式，而最常見之攻擊手法即是使用 APT 進階持續性威脅 (Advanced Persistent Threat, APT)，夾帶類似 <script>document.cookie</script> 之URL 連結，欺騙使用者在不經意狀況下點取，進而偷取使用者存在本機 Browser 之 Cookie 檔案，就可登入原本需帳號密碼才能登入之網站，而盜取個人基本資料或取得系統管理之權限。

解決方法也十分簡單，僅需將原程式加上php 提供之 function: htmlentities()，修改後之login_submit.php 內容：

echo "您輸入的帳號： " . htmlentities($_POST['login']) . " 錯誤!";

再測試一次在 login欄位輸入： <script>alert('test')</script>
結果網頁已沒有再跳出 Java Script 之訊息視窗，而直接顯示輸入之內容如下：

圖9：直接完整顯示使用者輸入內容
　

我們使用 IE 之檢視 -> 原始檔察看：
</head>
<body>
您輸入的帳號： <script>alert('test')</script> 錯誤!</body>
</html>

發現多了一些特殊字元： < >，原來就是 htmlentities() 發生作用，將字元 < 取代為 < 字元 >取代為 >，因此 Browser 直接解讀為文字而將結果顯示出來。

AppScan偵測之漏洞： SQL Injection SQL 注入

圖10： SQL Injection 漏洞摘要

我們以如下驗證帳號密碼之SQL語法範例來說明何謂 SQL Injection：
$query = "SELECT * FROM admin where login='" . $_POST['login'] . "' and passwd='" . $_POST['passwd'] . "'";

當任意輸入一組錯誤的帳號密碼：
Login 輸入： davis
Passwd 輸入： 12345

圖11：輸入一組錯誤的帳號密碼

我們模擬一下 SQL程式執行的語法：
-> select * from admin where login='davis' and passwd='12345'

因為資料庫中並沒有該組帳號密碼，SQL 執行的結果沒有任何紀錄符合上述條件，因此系統出現無法登入之錯誤訊息：

圖12：顯示登入失敗訊息
　

此時我們嘗試在密碼欄位輸入如下之字串：
Passwd 輸入： ' or 'a'='a

再模擬一下 SQL程式執行的語法：
-> select * from admin where login='davis' and passwd='' or 'a'='a'

圖13：帳號密碼錯誤卻顯示登入成功

此時大事不妙，上述SQL 執行的語意代表撈出所有 Table: admin 的資料，也就是完全不需輸入正確的帳號密碼，就可讓 SQL 語法驗證成功。SQL Injection 後果十分嚴重，尤其是個人資料保護法已在今年10月1日施行，若存在 SQL Injection 之漏洞將極有可能洩漏個人資料。

解決辦法也十分簡單，/etc/php.ini 有個參數：
; Magic quotes for incoming GET/POST/Cookie data.
magic_quotes_gpc = On

當啟用 magic_quotes_gpc 參數後，對於GET/POST 中使用者輸入之特殊字元，如單引號（'）雙引號( " )、反斜線( \ ), 前面會自動再加上反斜線( \ )，此時即視同為字元。當 magic_quotes_gpc 功能開啟後，SQL 執行之語法已改變為：
SELECT * FROM admin where login='davis' and passwd='\' or \'a\'=\'a'

如此就避免了 SQL Injection 之攻擊。

AppScan偵測之漏洞：目錄清單瀏覽

圖14：目錄清單瀏覽之漏洞摘要

所謂目錄清單瀏覽，就是當 URL 僅指定目錄而沒有指定 HTML檔名時，網頁將顯示該目錄下所有檔案，且可自由下載，若其中有些敏感文件或檔案，將造成外流。

圖15：目錄清單瀏覽之顯示結果

修正方法也很簡單，Apache 安裝時預設允許某些目錄有清單瀏覽功能，需修改/etc/httpd/conf/httpd.conf 將 Options 中 Indexes 字串移除：

<Directory "/var/www/icons">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>

其中 Indexes 之功能參考 Apache 原始文件說明： If a URL which maps to a directory is requested, and there is no Directory Index (e.g., index.html) in that directory, it will return a formatted listing of the directory.

因此就是這個設定造成目錄清單瀏覽，刪除此設定
<Directory "/var/www/icons">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>

將 URL 再輸入一次，果然已經沒有清單瀏覽之漏洞出現：

圖16：已修復目錄清單瀏覽之漏洞
　

Nessus 弱點掃瞄

接著我們使用 Nessus 進行作業系統層面之弱點掃瞄，總共回報有 3個等級屬於 Medium 之漏洞需處理。

圖17：Nessus掃瞄結果摘要
　

Nessus偵測之漏洞： mDNS Detection

圖18：mDNS Detection 漏洞摘要
　

Multicast DNS (mDNS) Detection 屬於IETF Zero Configuration Networking (zeroconf) 與DNS Extensions (dnsext) 協定之成員之一，主要用於小型網路系統中，當沒有 DNS Server 時，各裝置可透過 Host Discovery & Service Discovery，來認識彼此並瞭解各自提供的服務。
mDNS 主要的問題在於會揭露機器的 hostname、service & port、CPU型號與 Running OS 版本，在 Internet 世界中，揭露太多的資訊將讓駭客有可趁之機。

我們以 netstat 指令驗證機器是否有開啟 udp port: mdns (5353)
# netstat --listen

圖19：顯示機器 Listen之所有ports

果然有一個 UDP Service Listen Port: mdns (5353)，除非有特別需要，否則建議可關閉此 Service。在 CentOS 可執行下列指令關閉此服務：
service avahi-daemon stop

Nessus偵測之漏洞： HTTP TRACE / TRACK Methods Allowed

圖20：HTTP TRACE/TRACK Methods Allowed 漏洞摘要

HTTP TRACE/TRAC 通常用於 Debug，如何驗證系統是否真的有開啟 TRACE/TRACK 之功能，可使用telnet 網頁所在 ip 80 port：
telnet 127.0.0.1 80
之後輸入
TRACE / HTTP/1.1
Host: localhost.localdomain
再連續按兩下 Enter

圖21：有開啟HTTP TRACE/TRAC Method 之測試結果

如上圖，若系統有回應：
HTTP/1.1 200 OK
…
表示確實HTTP TRACE / TRACK Methods Allowed。
那該如何關閉呢？可在 Apache 之設定檔 httpd.conf 加上 TraceEnable off 即可。
vi /etc/httpd/conf/httpd.conf
加上字串：
TraceEnable off

接著重新啟動 Apache 即可.
service httpd restart

圖22：已關閉HTTP TRACE/TRAC Method 之測試結果

如上圖使用 telnet 再測試一次，系統直接回應錯誤訊息：
HTTP/1.1 403 Forbidden
…
表示HTTP TRACE / TRACK 確實已關閉

Nessus偵測之漏洞： Apache HTTP Server httpOnly Cookie Information Disclosure

圖23：Apache HTTP Server httpOnly Cookie Information Disclosure 漏洞摘要
　

依據弱點描述，此版本之Apache 存在一個 bug，當 HTTP header 過長時，可能導致 HTTP 400 error，而將原本不應該顯示之 httpOnly 之 cookies 顯示出來。
解決方法也很簡單，僅需將 Apache 升級至 2.2.22 以上即可。在 CentOS 中，不需也不建議去抓 Apache 原始檔回來自行make config... 等，而是直接執行：
yum install httpd
系統會自動執行升級之動作。

圖24：使用 yum 升級 apache 之版本"
　