企業(yè)級(jí)Web安全滲透測(cè)試之SSL篇
原創(chuàng)【51CTO.com獨(dú)家特稿】如果Web服務(wù)中的SSL和TLS協(xié)議出現(xiàn)安全問(wèn)題,后果會(huì)如何?很明顯,這樣的話攻擊者就可以擁有你所有的安全信息,包括我們的用戶名、密碼、信用卡、銀行信息……所有的一切。本文將向讀者詳細(xì)介紹如何針對(duì)Web服務(wù)中的SSL和TLS協(xié)議進(jìn)行安全滲透測(cè)試。我們首先對(duì)這兩種協(xié)議進(jìn)行了概述,然后詳細(xì)介紹了針對(duì)加密信道安全性的黑盒測(cè)試和白盒測(cè)試。最后列出了一些常用的安全測(cè)試工具。
一、簡(jiǎn)介
目前,許多重要的Web服務(wù)都使用了SSL和TLS協(xié)議對(duì)通信進(jìn)行保護(hù)。我們知道,http協(xié)議是使用明文進(jìn)行傳輸?shù)?,但是像網(wǎng)絡(luò)銀行之類的web應(yīng)用如果使用http協(xié)議的話,那么所有的機(jī)密信息都會(huì)暴露在網(wǎng)絡(luò)連接中,這就像銀行用一個(gè)透明的信封給我們郵寄信用卡帳號(hào)和密碼一樣,在從銀行到達(dá)用戶之間任何接觸過(guò)這封信的人,都能看到我們的帳號(hào)和密碼。為了提高其安全性,經(jīng)常需要通過(guò)SSL或者TLS隧道傳輸這些明文,這樣就產(chǎn)生了https通信流量。例如網(wǎng)絡(luò)銀行之類的應(yīng)用,在服務(wù)器和客戶端之間傳輸密碼,信用卡號(hào)碼等重要信息時(shí),都是通過(guò)https協(xié)議進(jìn)行加密傳送的。
SSL和TLS是兩種安全協(xié)議,它們通過(guò)加密技術(shù)為傳輸?shù)男畔⑻峁┌踩诺?、機(jī)密性和身份驗(yàn)證等安全功能。我們知道由于對(duì)高級(jí)密碼技術(shù)的出口限制,會(huì)造成遺留系統(tǒng)使用的是弱加密技術(shù)。如果系統(tǒng)采用了弱密碼,或者說(shuō)密碼強(qiáng)度過(guò)低的話,攻擊者可以在有效的時(shí)間內(nèi)破解密鑰,而攻擊者一旦得到了密鑰,就像小偷得到了我們家的鑰匙一樣,所有的鎖都會(huì)形同虛設(shè)。但是,新Web服務(wù)器就不會(huì)使用弱加密系統(tǒng)了嗎?答案是否定的,因?yàn)樵S多新Web服務(wù)器也經(jīng)常被配置成處理虛密碼選項(xiàng)。為了實(shí)現(xiàn)這些安全特性,協(xié)議必須確保使用的密碼算法有足夠的強(qiáng)度,并且密碼算法得到了正確的實(shí)現(xiàn)。即使服務(wù)器安裝使用了高級(jí)的加密模塊,但是如果配置不當(dāng)?shù)脑?,也有可能為安全特性要求較高的通信信道的設(shè)置了較弱的加密技術(shù)。下面,我們將詳細(xì)介紹如何對(duì)這兩種協(xié)議的配置進(jìn)行安全審計(jì)。
二、測(cè)試SSL/TLS的密碼規(guī)范
我們知道,http協(xié)議是使用明文進(jìn)行傳輸?shù)模瑸榱颂岣咂浒踩?,?jīng)常需要通過(guò)SSL或者TLS隧道傳輸這些明文,這樣就產(chǎn)生了https通信流量。除對(duì)傳輸?shù)臄?shù)據(jù)進(jìn)行加密處理之外,https(安全超文本傳輸協(xié)議,HTTPS)還能利用數(shù)字證書(shū)為服務(wù)器或客戶端提供身份標(biāo)識(shí)。
過(guò)去,美國(guó)政府對(duì)加密系統(tǒng)的出口有許多限制,如密鑰長(zhǎng)度最大為40位,因?yàn)槊荑€長(zhǎng)度越短,它就越容易破解。后來(lái),密碼出口條例已經(jīng)放寬了許多,但是,檢查服務(wù)器的SSL配置仍然十分重要,因?yàn)樗锌赡芘渲檬褂昧巳跫用芗夹g(shù)。基于SSL的服務(wù)不應(yīng)該提供選擇弱密碼的機(jī)會(huì)。
注意,我們這里所說(shuō)的弱密碼,指的是加密強(qiáng)度不夠、容易破解的加密系統(tǒng)。不同的加密算法具有不同的密碼強(qiáng)度,但是在算法一定的情況下,密鑰的長(zhǎng)度越長(zhǎng),加密強(qiáng)度越高。
技術(shù)上,選擇加密技術(shù)的過(guò)程如下所示:在建立SSL連接的初期,客戶端向服務(wù)器發(fā)送一個(gè)Client Hello消息,以告知服務(wù)器它支持哪些加密技術(shù)等。一般情況下,客戶端通常是一個(gè)Web瀏覽器,所以瀏覽器是目前最常見(jiàn)的SSL客戶端;然而,任何支持SSL的應(yīng)用程序都可以作為SSL客戶端使用。比如,有時(shí)候SSL客戶端是些SSL代理(如stunnel),它們使得那些不支持SSL的工具也能與SSL服務(wù)通信。同理,SSL服務(wù)器端通常為Web服務(wù)器,但是其他應(yīng)用程序也可以充當(dāng)SSL服務(wù)器端。 加密套件規(guī)定了具體的密碼協(xié)議(DES、RC4、AES)、密鑰長(zhǎng)度(諸如40、56或者128位)和用于完整性檢驗(yàn)的散列算法(SHA、MD5)。收到Client Hello消息后,服務(wù)器以此確定該會(huì)話所使用的加密套件。當(dāng)然,通過(guò)配置可以規(guī)定服務(wù)器能夠接受哪些密碼套件,這樣的話,我們就能夠控制是否跟僅支持40位加密的客戶端通話。 #p#
三、黑盒測(cè)試
為了檢測(cè)可能支持的弱密碼,必須找出與SSL/TLS服務(wù)相關(guān)的端口。通常情況下,要檢查端口443,因?yàn)樗菢?biāo)準(zhǔn)的https端口;不過(guò)運(yùn)行在443端口上的卻未必是https服務(wù),因?yàn)橥ㄟ^(guò)配置,https服務(wù)可以運(yùn)行在非標(biāo)準(zhǔn)的端口上,同時(shí),Web應(yīng)用程序也許使用了其它利用SSL/TLS封裝的服務(wù)。一般而言,為了找出這些端口,必須找出使用了哪些服務(wù)。
利用掃描程序nmap時(shí),加上掃描選項(xiàng)–sV,就能用來(lái)識(shí)別SSL服務(wù)。實(shí)際上,安全漏洞掃描器除了可以顯示使用的服務(wù)之外,還能用來(lái)檢查弱密碼,比如,Nessus就能檢查任意端口上的SSL服務(wù),并報(bào)告弱密碼。
如果攻擊者在您修復(fù)弱密碼之前發(fā)現(xiàn)了它們的話,那么您的處境可就不妙了——利用當(dāng)前強(qiáng)大的桌面計(jì)算力,例如借助GPU的并行運(yùn)算,他們能夠在有效的時(shí)間內(nèi)破解出密鑰,然后就能解密出https信道中加密過(guò)的機(jī)密信息,如口令,用戶名,如果您在使用網(wǎng)絡(luò)銀行,還能獲得他們的帳號(hào)和口令,等等。所以,我們一定要在攻擊者下手之前發(fā)現(xiàn)并修復(fù)存在的弱密碼配置。
例1. 通過(guò)nmap識(shí)別SSL服務(wù)
[root@test]# nmap -F -sV localhost Starting nmap 3.75 ( http://www.insecure.org/nmap/ ) at 2009-07-28 13:31 CEST Interesting ports on localhost.localdomain (127.0.0.1): (The 1205 ports scanned but not shown below are in state: closed) PORT STATE SERVICE VERSION 443/tcp open ssl OpenSSL 901/tcp open http Samba SWAT administration server 8080/tcp open http Apache httpd 2.0.54 ((Unix) mod_ssl/2.0.54 OpenSSL/0.9.7g PHP/4.3.11) 8081/tcp open http Apache Tomcat/Coyote JSP engine 1.0 Nmap run completed -- 1 IP address (1 host up) scanned in 27.881 seconds [root@test]# |
例2. 利用Nessus識(shí)別弱密碼。
下面內(nèi)容摘自Nessus掃描程序生成的報(bào)告,它發(fā)現(xiàn)了一個(gè)允許弱密碼的服務(wù)器證書(shū)(黑體字部分)。
https (443/tcp) Description Here is the SSLv2 server certificate: Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5WithRSAEncryption Issuer: C=**, ST=******, L=******, O=******, OU=******, CN=****** Validity Not Before: Oct 17 07:12:16 2007 GMT Not After : Oct 16 07:12:16 2008 GMT Subject: C=**, ST=******, L=******, O=******, CN=****** Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:98:4f:24:16:cb:0f:74:e8:9c:55:ce:62:14:4e: 6b:84:c5:81:43:59:c1:2e:ac:ba:af:92:51:f3:0b: ad:e1:4b:22:ba:5a:9a:1e:0f:0b:fb:3d:5d:e6:fc: ef:b8:8c:dc:78:28:97:8b:f0:1f:17:9f:69:3f:0e: 72:51:24:1b:9c:3d:85:52:1d:df:da:5a:b8:2e:d2: 09:00:76:24:43:bc:08:67:6b:dd:6b:e9:d2:f5:67: e1:90:2a:b4:3b:b4:3c:b3:71:4e:88:08:74:b9:a8: 2d:c4:8c:65:93:08:e6:2f:fd:e0:fa:dc:6d:d7:a2: 3d:0a:75:26:cf:dc:47:74:29 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate Page 10 Network Vulnerability Assessment Report 25.07.2009 X509v3 Subject Key Identifier: 10:00:38:4C:45:F0:7C:E4:C6:A7:A4:E2:C9:F0:E4:2B:A8:F9:63:A8 X509v3 Authority Key Identifier: keyid:CE:E5:F9:41:7B:D9:0E:5E:5D:DF:5E:B9:F3:E6:4A:12:19:02:76:CE DirName:/C=**/ST=******/L=******/O=******/OU=******/CN=****** serial:00 Signature Algorithm: md5WithRSAEncryption 7b:14:bd:c7:3c:0c:01:8d:69:91:95:46:5c:e6:1e:25:9b:aa: 8b:f5:0d:de:e3:2e:82:1e:68:be:97:3b:39:4a:83:ae:fd:15: b6:58:7e:39:d1:fa:8d:49:bd:ff:6b:a8:dd:ae:83:ed:bc:b2: 40:e3:a5:e0:fd:ae:3f:57:4d:ec:f3:21:34:b1:84:97:06:6f: f4:7d:f4:1c:84:cc:bb:1c:1c:e7:7a:7d:2d:e9:49:60:93:12: 0d:9f:05:8c:8e:f9:cf:e8:9f:fc:15:c0:6e:e2:fe:e5:07:81: 82:fc Here is the list of available SSLv2 ciphers: RC4-MD5 EXP-RC4-MD5 RC2-CBC-MD5 EXP-RC2-CBC-MD5 DES-CBC-MD5 DES-CBC3-MD5 RC4-64-MD5 The SSLv2 server offers 5 strong ciphers, but also 0 medium strength and 2 weak "export class" ciphers. The weak/medium ciphers may be chosen by an export-grade or badly configured client software. They only offer a limited protection against a brute force attack Solution: disable those ciphers and upgrade your client software if necessary. See http://support.microsoft.com/default.aspx?scid=kben-us216482 or http://httpd.apache.org/docs-2.0/mod/mod_ssl.html#sslciphersuite This SSLv2 server also accepts SSLv3 connections. This SSLv2 server also accepts TLSv1 connections. Vulnerable hosts (以下從略) |
#p#
例3. 利用OpenSSL以手工方式審計(jì)SSL的弱密碼
這里我們?cè)噲D通過(guò)SSLv2連接到Google.com:
[root@test]# openssl s_client -no_tls1 -no_ssl3 -connect www.google.com:443 CONNECTED(00000003) depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com verify error:num=27:certificate not trusted verify return:1 depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com verify error:num=21:unable to verify the first certificate verify return:1 --- Server certificate -----BEGIN CERTIFICATE----- MIIDYzCCAsygAwIBAgIQYFbAC3yUC8RFj9MS7lfBkzANBgkqhkiG9w0BAQQFADCB zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl cnZlckB0aGF3dGUuY29tMB4XDTA2MDQyMTAxMDc0NVoXDTA3MDQyMTAxMDc0NVow aDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDU1v dW50YWluIFZpZXcxEzARBgNVBAoTCkdvb2dsZSBJbmMxFzAVBgNVBAMTDnd3dy5n b29nbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/e2Vs8U33fRDk 5NNpNgkB1zKw4rqTozmfwty7eTEI8PVH1Bf6nthocQ9d9SgJAI2WOBP4grPj7MqO dXMTFWGDfiTnwes16G7NZlyh6peT68r7ifrwSsVLisJp6pUf31M5Z3D88b+Yy4PE D7BJaTxq6NNmP1vYUJeXsGSGrV6FUQIDAQABo4GmMIGjMB0GA1UdJQQWMBQGCCsG AQUFBwMBBggrBgEFBQcDAjBABgNVHR8EOTA3MDWgM6Axhi9odHRwOi8vY3JsLnRo YXd0ZS5jb20vVGhhd3RlUHJlbWl1bVNlcnZlckNBLmNybDAyBggrBgEFBQcBAQQm MCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLnRoYXd0ZS5jb20wDAYDVR0TAQH/ BAIwADANBgkqhkiG9w0BAQQFAAOBgQADlTbBdVY6LD1nHWkhTadmzuWq2rWE0KO3 Ay+7EleYWPOo+EST315QLpU6pQgblgobGoI5x/fUg2U8WiYj1I1cbavhX2h1hda3 FJWnB3SiXaiuDTsGxQ267EwCVWD5bCrSWa64ilSJTgiUmzAv0a2W8YHXdG08+nYc X/dVk5WRTw== -----END CERTIFICATE----- subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com issuer=/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com --- No client certificate CA names sent --- Ciphers common between both SSL endpoints: RC4-MD5 EXP-RC4-MD5 RC2-CBC-MD5 EXP-RC2-CBC-MD5 DES-CBC-MD5 DES-CBC3-MD5 RC4-64-MD5 --- SSL handshake has read 1023 bytes and written 333 bytes --- New, SSLv2, Cipher is DES-CBC3-MD5 Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv2 Cipher : DES-CBC3-MD5 Session-ID: 709F48E4D567C70A2E49886E4C697CDE Session-ID-ctx: Master-Key: 649E68F8CF936E69642286AC40A80F433602E3C36FD288C3 Key-Arg : E8CB6FEB9ECF3033 Start Time: 1156977226 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate)--- closed |
#p#
例4.中間人攻擊
為了幫助讀者理解中間人攻擊,我們舉一個(gè)現(xiàn)實(shí)例子。罪犯冒充公安人員給受害者打電話,說(shuō)有人利用用戶的網(wǎng)絡(luò)銀行帳號(hào)進(jìn)行洗錢活動(dòng),公安機(jī)關(guān)要求該用戶協(xié)助調(diào)查,給出其帳號(hào)的具體信息,包括密碼。如果用戶上當(dāng),交出了密碼等信息,那么犯罪分子就可以利用這些信息洗劫賬戶內(nèi)的資金。這就是一種典型的中間人攻擊。
下面是一個(gè)Web環(huán)境下的中間人攻擊示意圖。
![]() |
圖1 中間人攻擊示意圖 |
首先,在IE瀏覽器的地址欄輸入登錄地址,如下圖所示:
![]() |
圖2 登錄網(wǎng)絡(luò)銀行 |
然后,利用代理篡改返回的數(shù)據(jù)包,讓它返回502錯(cuò)誤(或其他錯(cuò)誤),并插入一個(gè)iframe,讓瀏覽器請(qǐng)求真實(shí)地址,同時(shí)插入一段如下所示的腳本:
![]() |
圖3 插入的腳本 |
這樣就能讀取iframe的內(nèi)容,如下圖所示:
![]() |
圖4 讀取的iframe內(nèi)容 |
實(shí)際上,攻擊者不僅能夠讀取該iframe的內(nèi)容,還能夠向該域進(jìn)行提交。在真實(shí)的攻擊環(huán)境中,攻擊者可以讀取防止跨站請(qǐng)求偽造令牌,實(shí)施跨站請(qǐng)求攻擊,甚至截獲用戶名和密碼。 #p#
四、白盒測(cè)試
對(duì)于提供https服務(wù)的web服務(wù)器,要仔細(xì)檢查其配置;如果Web應(yīng)用程序提供了其他使用SSL/TLS封裝的服務(wù),也應(yīng)當(dāng)對(duì)其進(jìn)行仔細(xì)檢查。例如,以下Microsoft Windows 2003的注冊(cè)表路徑定義了服務(wù)器可用的加密技術(shù):
EY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\ |
五、測(cè)試SSL證書(shū)的有效性
通過(guò)https協(xié)議訪問(wèn)Web應(yīng)用程序時(shí),就會(huì)在客戶端(通常為瀏覽器)和服務(wù)器之間建立一個(gè)安全信道。然后,通過(guò)數(shù)字證書(shū)為通信的一方(服務(wù)器)或雙方(客戶和服務(wù)器)建立身份標(biāo)識(shí)。為了進(jìn)行通信,這些證書(shū)需要通過(guò)多道檢測(cè)?;赟SL和證書(shū)的身份驗(yàn)證超出了本文的范圍,我們這里主要探討證書(shū)有效性的主要標(biāo)準(zhǔn):檢查認(rèn)證中心是否是可信的機(jī)構(gòu);檢查證書(shū)當(dāng)前的有效性;站點(diǎn)名稱和證書(shū)中所聲稱的是否一致。要經(jīng)常升級(jí)您的瀏覽器,因?yàn)镃A證書(shū)也會(huì)過(guò)期,在瀏覽器的不同版本中,CA證書(shū)會(huì)重新生成。另外,因?yàn)樵絹?lái)越多的網(wǎng)站要求強(qiáng)度高于40或者56位的加密,這時(shí)也需要更新瀏覽器,因?yàn)橐恍├习姹静恢С诌@些高強(qiáng)度加密。下面我們做進(jìn)一步的解釋。
1.每個(gè)瀏覽器都帶有一個(gè)預(yù)裝的受信CA列表,當(dāng)我們收到證書(shū)時(shí),可以到簽發(fā)該證書(shū)的認(rèn)證中心CA去驗(yàn)證一下。當(dāng)然,這個(gè)列表是可以隨意定制和擴(kuò)展的。 在與https服務(wù)器的初步磋商期間,如果服務(wù)器證書(shū)是瀏覽器不了解的認(rèn)證中心簽發(fā)的,那么就會(huì)拋出一個(gè)警告。出現(xiàn)這種情況,一般是因?yàn)閃eb應(yīng)用程序的證書(shū)是由一個(gè)自建的認(rèn)證中心所簽發(fā)的。 對(duì)于內(nèi)部網(wǎng)環(huán)境來(lái)說(shuō),自建認(rèn)證中心是比較合適的,因?yàn)槠髽I(yè)web電子郵件是通過(guò)https傳輸?shù)?,同時(shí),企業(yè)內(nèi)的所有用戶都會(huì)信任這個(gè)內(nèi)部認(rèn)證中心。但是,當(dāng)通過(guò)Internet向公眾提供服務(wù)時(shí),則需要使用一個(gè)所有公共用戶都信任的認(rèn)證中心。
2.證書(shū)都有一個(gè)有效期,因此,它也是會(huì)過(guò)期的。同樣,如果證書(shū)過(guò)期的話,瀏覽器也會(huì)拋出一個(gè)警告。公用服務(wù)需要一個(gè)暫時(shí)有效的證書(shū);否則,當(dāng)我們跟一個(gè)服務(wù)器通信時(shí),只要它的證書(shū)是受信任的認(rèn)證中心頒發(fā)的,即使過(guò)期也無(wú)需重新生成。
3.如果證書(shū)中的名稱跟服務(wù)器的名稱不相配怎么辦呢?如果出現(xiàn)這種情況,就說(shuō)明很可疑。一個(gè)系統(tǒng)可以托管許多基于名稱的虛擬主機(jī),這些虛擬主機(jī)共享同一個(gè)IP地址,彼此靠HTTP 1.1的Host:頭部相互區(qū)別。在這個(gè)例子中,因?yàn)樵谔幚鞨TTP請(qǐng)求之前,SSL握手時(shí)會(huì)檢查服務(wù)器證書(shū),所以它不可能為每個(gè)虛擬服務(wù)器分配不同的證書(shū)。因此,如果站點(diǎn)的名稱和證書(shū)中所指出的名稱不匹配,那么我們?yōu)g覽器就會(huì)發(fā)出通知。為了避免這種情況,必須使用基于IP的虛擬服務(wù)器。 RFC2817(http://www.ietf.org/rfc/rfc2817.txt)和RFC3546(http://www.ietf.org/rfc/rfc3546.tx)這兩個(gè)文檔描述了處理這個(gè)問(wèn)題并允許正確引用基于名稱的虛擬主機(jī)的方法。
證書(shū)有效性的黑盒測(cè)試
下面介紹如何檢查應(yīng)用程序使用的證書(shū)的有效性。當(dāng)瀏覽器遇到過(guò)期的證書(shū)、由不可信的認(rèn)證中心簽發(fā)的證書(shū)以及證書(shū)上的名稱跟服務(wù)器名稱不一致時(shí),它就會(huì)發(fā)出一個(gè)警告。 訪問(wèn)https站點(diǎn)的時(shí)候,我們只要單擊在瀏覽器窗口中的“鎖”圖標(biāo),就能看到與證書(shū)有關(guān)的信息,如證書(shū)簽發(fā)機(jī)構(gòu)、有效期、加密特性等。
如果應(yīng)用程序要求客戶端證書(shū),那也不要緊,因?yàn)樵L問(wèn)該程序之前我們很可能已經(jīng)安裝過(guò)證書(shū),所以可以通過(guò)查看瀏覽器證書(shū)列表中已安裝的的相關(guān)證書(shū)來(lái)獲得必要的證書(shū)信息。
對(duì)于應(yīng)用程序所用的所有SSL通信信道,必須進(jìn)行上述檢查。雖然https服務(wù)通常運(yùn)行在443端口上,但還可能有依賴這個(gè)Web應(yīng)用程序的其它服務(wù),從而導(dǎo)致https管理端口一直打開(kāi),或者在非標(biāo)準(zhǔn)的端口上運(yùn)行https服務(wù),等等。 因此,要對(duì)所有已經(jīng)發(fā)現(xiàn)的使用SSL進(jìn)行封裝的端口進(jìn)行檢查,比如,nmap掃描程序提供了一個(gè)掃描模式——需要在命令行中加上–sV選項(xiàng)來(lái)啟用該模式 ——專門用來(lái)查找使用SSL進(jìn)行封裝的服務(wù)。安全漏洞掃描程序Nessus也能對(duì)所有使用SSL/TLS封裝的服務(wù)進(jìn)行檢查。
以下截屏取自一個(gè)公司的站點(diǎn)。它是一個(gè)Microsoft IE發(fā)出的警告,呵呵,我們要訪問(wèn)的是一個(gè).it站點(diǎn),而該證書(shū)卻是發(fā)給一個(gè).com 站點(diǎn)的?! IE警告說(shuō),證書(shū)上的名稱與站點(diǎn)的名稱不匹配。
![]() |
圖5 證書(shū)有效性黑盒測(cè)試舉例 |
證書(shū)有效性的白盒測(cè)試
在服務(wù)器和客戶端級(jí)別都檢查應(yīng)用程序所用的證書(shū)的有效性。證書(shū)最初是應(yīng)用在Web 服務(wù)器級(jí)別的,然而,SSL還可能用來(lái)保護(hù)其它通信路徑,例如DBMS使用的路徑。您應(yīng)該檢查應(yīng)用程序體系結(jié)構(gòu)來(lái)尋找所有的SSL保護(hù)的通道。
六、測(cè)試工具
下面介紹在測(cè)試加密信道的安全性的時(shí)候,可能有到的測(cè)試工具:
安全漏洞掃描器可以檢查證書(shū)的有效性,包括名稱匹配情況和過(guò)期情況。此外,它們通常還報(bào)告其他信息,諸如頒發(fā)證書(shū)的機(jī)構(gòu)等等。 請(qǐng)記住,哪些CA是可信的,完全取決于人們的觀念和軟件的配置;不過(guò),瀏覽器通常帶有一組預(yù)設(shè)的可信認(rèn)證中心。 如果您的Web應(yīng)用程序使用的CA沒(méi)有位于這個(gè)列表中的話,例如依靠一個(gè)自建的認(rèn)證中心,那么您應(yīng)該讓用戶重新配置他們的瀏覽器,讓瀏覽器認(rèn)可這個(gè)認(rèn)證中心。
掃描程序Nessus有一個(gè)插件可以用來(lái)檢查已經(jīng)過(guò)期的證書(shū)、或者在60天內(nèi)將過(guò)期的證書(shū)。該插件的id為15901,名字為SSL certificate expiry。 這個(gè)插件將檢查安裝在服務(wù)器上的證書(shū)。
有的安全漏洞掃描器也能檢查弱密碼,比如,掃描程序Nessus,它就能指出存在的SSL弱密碼。
此外,我們還可能需要一些特殊的工具,例如SSL Digger(http://www.foundstone.com/resources/proddesc/ssldigger.htm);或者Openssl工具,它能直接從UNIX命令行下訪問(wèn)Openssl加密函數(shù),該工具的下載地址為www.openssl.org。 為了識(shí)別基于SSL的服務(wù),可以使用具有服務(wù)識(shí)別能力的安全漏洞掃描程序或者端口掃描程序。掃描程序nmap具有一個(gè)-sV掃描選項(xiàng),用以識(shí)別服務(wù);安全漏洞掃描程序Nessus則能識(shí)別在任意的端口上的基于SSL的服務(wù),并對(duì)這些服務(wù)進(jìn)行安全漏洞檢查——不管它們是在標(biāo)準(zhǔn)端口還是非標(biāo)準(zhǔn)的端口上。
如果需要與SSL服務(wù)交互但是您喜愛(ài)的工具卻不支持SSL的話,可以求助于SSL代理,例如stunnel,它能在底層協(xié)議中打通隧道跟SSL服務(wù)進(jìn)行通信。
最后,盡管人們樂(lè)于使用常規(guī)瀏覽器來(lái)檢查證書(shū),但是瀏覽器通常具有許多漏洞,此外瀏覽器進(jìn)行檢測(cè)時(shí)可能受到許多不易察覺(jué)的配置設(shè)置的影響。相反,依靠安全漏洞掃描器或者專門的工具來(lái)進(jìn)行檢查則要好得多。
七、小結(jié)
如果Web服務(wù)中的SSL和TLS協(xié)議出現(xiàn)安全問(wèn)題,后果會(huì)如何?很明顯,這樣的話攻擊者就可以擁有你所有的安全信息,包括我們的用戶名、密碼、信用卡、銀行信息……所有的一切。本文向讀者詳細(xì)介紹了如何針對(duì)Web服務(wù)中的SSL和TLS協(xié)議進(jìn)行安全滲透測(cè)試:我們首先對(duì)這兩種協(xié)議進(jìn)行了概述,然后詳細(xì)介紹了針對(duì)加密信道安全性的黑盒測(cè)試和白盒測(cè)試。最后還列出了一些常用的安全測(cè)試工具。
【51CTO.COM 獨(dú)家特稿,轉(zhuǎn)載請(qǐng)注明出處及作者!】