SSL:一種錯誤的安全感



贊助商連結


giogio2000
2002-02-05, 02:22 PM
SSL:一種錯誤的安全感

CNET US : 文:Chris Prosise 及Saumil Udayan Shah/ 林志峰 譯
04/06/2001

在這個專欄裡面,我們將指出大部分網路較鮮為人知的弱點:網頁伺服器(Web server)的安全性。我們將提供工具程式以及相關技術, 以便幫助網路安全管理者改善他們審查以及監控這個在電子商務裡頭不容忽視的安全技術。

有多少次我們看過的網頁會用 SSL 來向我們保證他們網站的安全性? 我們常常看到諸如此類的話,「你的交易受到 SSL 的保護。」這句話到底代表著什麼意思? 用 SSL 防護的網站真的能夠防堵駭客嗎? 現在就讓我們來探討到底 SSL 在保護的是什麼,駭客們的攻擊有時候是怎樣穿透 SSL 的,以及, 為了反制起見,系統管理者要如何審查及監控 SSL 防護的網站。

Secure Sockets Layer (SSL) 通訊協定把在網頁以及伺服器之間的資料傳輸加密起來。這個加密(encryption)的措施能夠防止資料竊取者直接看到傳輸中的資料, 像是密碼或者信用卡號碼等等。幾乎所有處理具有敏感度的資料,財務資料或者要求身分認證的網站都會使用 SSL 加密技術。(當你看到 https 在你的網頁瀏覽器上的 URL 出現時,你就是正在使用具有 SSL 保護的網頁伺服器。)


迷思:SSL 保護主機或者是應用程式
SSL 不是設計用來保護作業系統的; 它是被設計用來保護傳輸中的資料。你可以把 SSL 想像成是一種在瀏覽器跟網路伺服器之間「受密碼保護的導管」(cryptographic pipe)。 這個導管把使用者以及網站之間往返的資料加密起來。但是 SSL 並不會消除或者減弱網站所將受到的威脅性。在 SSL 導管的背後,一般沒有受到 SSL 防護的網站一樣具備了相同的網頁伺服器程式, 同樣的網頁應用程式,CGI 的 script 以及後端資料庫。不幸的是,很多系統管理者卻認為, 受到 SSL 防護的網頁伺服器自動就變得安全了。事實上,正如同我們即將看到的,受到 SSL 防護的網頁伺服器同樣還是會受到與一般其他網站伺服器遭受攻擊的威脅。

有著 SSL 防護的網站伺服器很少接受審查以及監測
促使 SSL 成為網路商務安全的全球通用選擇的這項獨特特質卻同時也造成了網路安全管理員的困擾。因為系統管理員沒辦法使用現有的安全漏洞掃描(vulnerability scanners)或網路入侵偵測系統(intrusion detection systems,IDS),來審查或監控網路上的 SSL 交易。網路入侵偵測系統是透過監測網路傳輸來找尋沒有經過認證的活動。任何符合已知的攻擊模式或者並未經過政策上授權的網路活動都被標起來以供系統管理者檢視。 而要讓 IDS 能夠發生作用,IDS 必須能夠檢視所有的網路流量資訊,但是 SSL 的加密技術卻使得透過 http 傳輸的資訊無法讓 IDS 辨認。
再者,雖然我們可以用熱門的安全掃描軟體審查一般的網頁伺服器來尋找已知的安全盲點,這種掃描軟體並不會檢查經過 SSL 保護的伺服器。受到 SSL 保護的網頁伺服器的確擁有與一般伺服器同樣的安全盲點,可是也許是因為建立 SSL 連結所需要的時間以及困難度,安全漏洞掃描軟體並不會審查受到 SSL 保護的網頁伺服器。沒有網路監測系統再加上沒有安全漏洞審查,使得最重要的伺服器反而成為受到最少防護的伺服器。



解決方案
我們有一些技術,是以先前我們做諮詢服務的經驗為基礎的,可以用來監控以及審查受到 SSL 防護的伺服器。這個解決方案不是很複雜難懂的技術, 只是針對一個在網路安全上,人們很少去正視的問題,所提出的新方法而已。


OpenSSL
OpenSSL 包含了一套程式以及函式庫,提供前端使用者 SSL 功能,並且允許軟體工程師將 SSL 模組與他們的程式結合。在眾多由 SSL 提供的產品裡面,最能夠用來讓我們在這裡討論的是命令列模式的(command-line) SSL 客戶端以及伺服端工具軟體。 OpenSSL 程式是一個指令列介面的程式,它是用來以手動的方式起始 SSL 連結。OpenSSL 讓你重新導引與其他程式之間的資料輸入以及輸出。

使用普遍可得的安全掃描軟體來審查 SSL 伺服器
在研究技術文件時,我們在 Apache 提供給 OpenSSL 的介面模組 mod_ssl 讀到了一些有趣的資訊。其中有 一段常見問題(FAQ)討論到有關測試在 SSL 保護下的網站伺服器。你可以利用 Telnet 連到網頁伺服器第 80 號連接埠,然後下達如下的 http get 指令,從網頁伺服器取得網頁:

telnet www.ramsec.com 80
Trying 216.182.36.154...
Connected to www.ramsec.com.
Escape character is '^]'.
GET / HTTP/1.0
HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Content-Location: http://216.182.36.154/index.html
Date: Mon, 10 Jul 2000 11:43:59 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Thu, 23 Mar 2000 01:41:15 GMT
ETag: "305fc7e06894bf1:38441"
Content-Length: 886

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">


因為 SSL 通聯必須要經過一個安全的連接埠,而在這裡我們使用的是沒有安全防護的連接埠 80,因此,這個技巧在 HTTPS 通訊協定上是行不通的。然而,如果我們用的是 OpenSSL 程式,我們就可以在 SSL 連接上做同樣的一件事情。

觀看 OpenSSL 連結的細節

有了這項技術,我們就可以直接傳送資料到有 SSL 保護的網站,然後用我們一般審查任何 HTTP 伺服器安全性的方式來審查這個 SSL 網頁伺服器。

透過 Proxy 代理伺服器的 SSL
我們可以在一個 SSL Proxy 代理程式上使用這項資料審查技術。SSL Proxy 是一個在連接埠 80 上接收純文字的 HTTP 通訊請求的軟體,它會將這些請求透過經由 SSL 加密過的連結,轉寄到目標網站。我們在連接埠 80 開一個聽取的 socket,透過上述的 OpenSSL 指令,將所有進入這個 proxy 的資料傳送出去。這在 Unix 上,只是個小技巧:我們只須將以下的指令加到我們的 /etc/inetd.conf 檔案裡面,這個 inetd.conf 包含所有 inetd 所提供的網路服務的設定:



www stream tcp nowait root /usr/sbin/tcpd /usr/local/bin/ssl_proxy.sh

而 /usr/local/bin/ssl_proxy.sh 的內容則如下所述:


#!/bin/sh
/usr/local/ssl/bin/openssl s_client -no_tls1 -quiet -connect 192.168.100.10:443 2>/dev/null

192.168.100.10 是 SSL 防護下的網站的位址所在。其中 -no_tls1 以及 -quiet 選項將 SSL 交談 (handshake)的標題顯示關掉,並且也刪除了 SSL 對於尚未經過授權的網站認證所發出的警告。

要想測試我們的 proxy 連結,我們只要以純文字的方式,在執行 SSL proxy 的系統的連接埠 80 建立連線。這個 proxy 會使用 SSL 來轉寄接收的請求到目標網站。


$ telnet 192.168.100.2 80 GET / HTTP/1.0


在這裡,我們的伺服器正在 192.168.100.2 的位址執行 SSL proxy 機制,而真正受到 SSL 保護的位址則是在 192.168.100.10。

透過這個 SSL proxy 機制,我們只要將安全掃描軟體指向 proxy 的 IP 位址,就可以使用它來審查一個 SSL 伺服器。

在這裡,我們有一個使用 whisker 程式來審查 SSL 防護的網站伺服器。Whisker 是一個由 Rain Forest Puppy 寫出來的 script,可以用來檢查已知的比較容易受到入侵的網站應用程式以及 CGI script。


./whisker.pl -h 192.168.100.2
-- whisker / v1.3.0a / rain forest puppy / ADM / wiretrip --
- Loaded script database of 1691 lines
= - = - = - = - = - =
= Host: 192.168.100.2
= Server: Microsoft-IIS/4.0

+ 404 Object Not Found: GET /cfdocs/
+ 404 Object Not Found: GET /cfide/Administrator/startstop.html
+ 404 Object Not Found: GET /cfappman/index.cfm
+ 404 Object Not Found: GET /cgi-bin/
+ 403 Access Forbidden: HEAD /scripts/
+ 403 Access Forbidden: HEAD /scripts/cpshost.dll
+ 404 Object Not Found: HEAD /samples/search/queryhit.htm
+ 404 Object Not Found: HEAD /adsamples/config/site.csc
+ 403 Access Forbidden: HEAD /scripts/counter.exe
+ 403 Access Forbidden: HEAD /scripts/samples/
?


以上情況是,我們在 192.168.100.2 上執行 whisker,然後 whisker 使用 SSL 將所有的 HTTP 請求轉寄到 192.168.100.10。

SSL proxy 的觀念已經存在一陣子了。目前有一個名為 sslproxy.c 的程式,可以執行以上的功能。另外一個最近才出來,執行 SSL proxy 還有其他額外功能的工具程式,叫做 stunnel, 是由 Brian Hatch 開發的。然而,因為使用命令列模式操作 OpenSSL 軟體還蠻簡單的,所以我們選擇在這篇專欄裡面介紹這種方式。


監測 SSL 伺服器
現在的網路 IDS 只能夠監視純文字資料內容。這個事實讓我們只能夠有兩項選擇:監視伺服器上的 SSL 連結或者將整個連結資料轉為純文字格式。

大部分的網頁伺服器都有一些基本的日誌紀錄功能。例如,Microsoft 的 IIS Web server 有內建的日誌製作功能,使用的是 W3svc1 格式,它可以偵測到很多一般的網路攻擊狀況。我們透過前述的 SSL proxy 針對 Windows NT 4.0 上具備有 SSL 防護的 IIS 伺服器,來作示範性的攻擊。我們用的是由 Rain Forest Puppy 發現的 一般性常見的 msadc 安全穿透技術。我們的 IIS 伺服器在 C:\WINNT\system32\LogFiles 的目錄下,記載了以下的日誌:


12:25:45 10.0.0.1 GET /msadc/msadcs.dll 200
12:25:48 10.0.0.1 POST / msadc/msadcs.dll 200

然而,因為這些日誌檔通常是存在網頁伺服器上面,因此,一個成功的攻擊事件表示駭客很可能已經對日誌檔下了手腳了。此外,安全管理員必須每天檢查伺服器上的日誌檔 (另外還有 IDS,防火牆等等),這實在不是個最佳的解決方案。
除了使用主機日誌檔的以外,另一個方式是將 SSL 連結轉換成純文字格式。如此一來網路的 IDS 就能夠監視資料往來。有幾種產品提供這項功能,不過他們主要是為了要提昇資料處理效能,而不是為了網路安全的理由。建立以及維護 SSL 連結,必須耗用相當的 CPU 時間,如此一來會減損網頁伺服器的效能。市面上有幾家廠商提供「電子商務加速器」,用來將與 SSL 交涉的工作移到不同的裝置或處理器。你可以將 IDS 置放於加速器跟網頁伺服器之間,以監控純文字格式的網路交通。用這種方式監控的話, 有一個問題。那就是你必須有至少一個網路區隔(network segment)。這個網路區隔必須是安全的,而且與其他的網路裝置分開來。


結論
有兩件重要的事情是你必須牢記在心的。首先,SSL 並不能夠防護你的網站安全。它僅僅防護使用者的網頁伺服器以及目標網站之間的點對點資料連結。網頁伺服器跟後端的網頁應用軟體, 仍舊會受到跟一般沒有 SSL 防護的網站同樣的攻擊威脅。第二點,雖然 SSL 會使網路攻擊者很難用目前已知的攻擊模式直接攻擊 SSL 防護網站,不過, 這些防衛仍舊是有可能用諸如 SSL proxy 等工具來加以突破。然而,相同的技術卻也可以被用來監視以及審查系統的安全漏洞。


http://taiwan.cnet.com/builder/backend/story/0,2000027264,20011301-1,00.htm