当前位置:文档之家› 详述SSL和TLS的Web安全渗透测试

详述SSL和TLS的Web安全渗透测试

详述SSL和TLS的Web安全渗透测试
详述SSL和TLS的Web安全渗透测试

如果Web服务中的SSL和TLS协议出现安全问题,后果会如何?很明显,这样的话攻击者就可以拥有你所有的安全信息,包括我们的用户名、密码、信用卡、银行信息……所有的一切。本文将向读者详细介绍如何针对Web服务中的SSL和TLS协议进行安全渗透测试。我们首先对这两种协议进行了概述,然后详细介绍了针对加密信道安全性的黑盒测试和白盒测试。最后列出了一些常用的安全测试工具。

一、简介

目前,许多重要的Web服务都使用了SSL和TLS协议对通信进行保护。我们知道,http协议是使用明文进行传输的,但是像网络银行之类的web应用如果使用http协议的话,那么所有的机密信息都会暴露在网络连接中,这就像银行用一个透明的信封给我们邮寄信用卡帐号和密码一样,在从银行到达用户之间任何接触过这封信的人,都能看到我们的帐号和密码。为了提高其安全性,经常需要通过SSL或者TLS隧道传输这些明文,这样就产生了https通信流量。例如网络银行之类的应用,在服务器和客户端之间传输密码,信用卡号码等重要信息时,都是通过https协议进行加密传送的。

SSL和TLS是两种安全协议,它们通过加密技术为传输的信息提供安全信道、机密性和身份验证等安全功能。我们知道由于对高级密码技术的出口限制,会造成遗留系统使用的是弱加密技术。如果系统采用了弱密码,或者说密码强度过低的话,攻击者可以在有效的时间内破解密钥,而攻击者一旦得到了密钥,就像小偷得到了我们家的钥匙一样,所有的锁都会形同虚设。但是,新Web服务器就不会使用弱加密系统了吗?答案是否定的,因为许多新Web服务器也经常被配臵成处理虚密码选项。为了实现这些安全特性,协议必须确保使用的密码算法有足够的强度,并且密码算法得到了正确的实现。即使服务器安装使用了高级的加密模块,但是如果配臵不当的话,也有可能为安全特性要求较高的通信信道的设臵了较弱的加密技术。下面,我们将详细介绍如何对这两种协议的配臵进行安全审计。

二、测试SSL/TLS的密码规范

我们知道,http协议是使用明文进行传输的,为了提高其安全性,经常需要通过SSL或者TLS隧道传输这些明文,这样就产生了https通信流量。除对传输的数据进行加密处理之外,https(安全超文本传输协议,HTTPS)还能利用数字证书为服务器或客户端提供身份标识。

过去,美国政府对加密系统的出口有许多限制,如密钥长度最大为40位,因为密钥长度越短,它就越容易破解。后来,密码出口条例已经放宽了许多,但是,检查服务器的SSL配臵仍然十分重要,因为它有可能配臵使用了弱加密技术。基于SSL的服务不应该提供选择弱密码的机会。

注意,我们这里所说的弱密码,指的是加密强度不够、容易破解的加密系统。不同的加密算法具有不同的密码强度,但是在算法一定的情况下,密钥的长度越长,加密强度越高。

技术上,选择加密技术的过程如下所示:在建立SSL连接的初期,客户端向服务器发送一个Clien t Hello消息,以告知服务器它支持哪些加密技术等。一般情况下,客户端通常是一个Web浏览器,所以浏览器是目前最常见的SSL客户端;然而,任何支持SSL的应用程序都可以作为SSL客户端使用。比如,有时候SSL客户端是些SSL代理(如stunnel),它们使得那些不支持SSL的工具也能与SSL服务通信。同理,SSL服务器端通常为Web服务器,但是其他应用程序也可以充当SSL服务器端。加密套件规定了具体的密码协议(DES、RC4、AES)、密钥长度(诸如40、56或者128位)和用于完整性检验的散列算法(SHA、MD5)。收到Client Hello消息后,服务器以此确定该会话所使用的加密套件。当然,通过配臵可以规定服务器能够接受哪些密码套件,这样的话,我们就能够控制是否跟仅支持40位加密的客户端通话

三、黑盒测试

为了检测可能支持的弱密码,必须找出与SSL/TLS服务相关的端口。通常情况下,要检查端口443,因为它是标准的https端口;不过运行在443端口上的却未必是https服务,因为通过配臵,https服务可以运行在非标准的端口上,同时,Web应用程序也许使用了其它利用SSL/TLS封装的服务。一般而言,为了找出这些端口,必须找出使用了哪些服务。

利用扫描程序nmap时,加上扫描选项–sV,就能用来识别SSL服务。实际上,安全漏洞扫描器除了可以显示使用的服务之外,还能用来检查弱密码,比如,Nessus就能检查任意端口上的SSL服务,并报告弱密码。

如果攻击者在您修复弱密码之前发现了它们的话,那么您的处境可就不妙了——利用当前强大的桌面计算力,例如借助GPU的并行运算,他们能够在有效的时间内破解出密钥,然后就能解密出https信道中加密过的机密信息,如口令,用户名,如果您在使用网络银行,还能获得他们的帐号和口令,等等。所以,我们一定要在攻击者下手之前发现并修复存在的弱密码配臵。

例1. 通过nmap识别SSL服务

[root@test]# nmap -F -sV localhostStarting nmap 3.75

( https://www.doczj.com/doc/5f386666.html,/nmap/ ) at 2009-07-28 13:31 CESTInteresting ports on

localhost.localdomain (127.0.0.1):(The 1205 ports scanned but not shown below are

in state: closed)PORT STATE

SERVICE VERSION443/tcp open ssl OpenSSL901/tcp open http Samba

SWAT administration server8080/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.0Nmap run completed -- 1 IP address (1 host up) scanned

in 27.881 seconds[root@test]#

例2. 利用Nessus识别弱密码。

下面内容摘自Nessus扫描程序生成的报告,它发现了一个允许弱密码的服务器证书(黑体字部分)。

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:2e:50:c8:a7:16:6e:c9:4e:76:cc:fd:69 :ae:4f:12:b8:e7:01: 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-MD5EXP-RC4-MD5RC2-CBC-MD5EXP-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

https://www.doczj.com/doc/5f386666.html,/default.aspx?scid=kben-us216482 or

https://www.doczj.com/doc/5f386666.html,/docs-2.0/mod/mod_ssl.html#sslciphersuite This SSLv2 server also accepts SSLv3 connections.This SSLv2 server also accepts TLSv1 connections. Vulnerable hosts (以下从略)

例3. 利用OpenSSL以手工方式审计SSL的弱密码

这里我们试图通过SSLv2连接到https://www.doczj.com/doc/5f386666.html,:

[root@test]# openssl s_client -no_tls1 -no_ssl3 -connect

https://www.doczj.com/doc/5f386666.html,:443CONNECTED(00000003)depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=https://www.doczj.com/doc/5f386666.html,verify error:num=20:unable to get local issuer certificateverify return:1depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=https://www.doczj.com/doc/5f386666.html,verify error:num=27:certificate not trustedverify return:1depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=https://www.doczj.com/doc/5f386666.html,verify error:num=21:unable to verify the first certificateverify return:1---Server certificate-----BEGIN

CERTIFICATE-----MIIDYzCCAsygAwIBAgIQYFbAC3yUC8RFj9MS7lfBkzANBgkqhkiG9w0BAQQFADCBzjELMAkGA 1UEB

hMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYDVQQ

KExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaX

Zpc2lvbjEhMB8GA1UEAxMYVGhhd3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlw cmVtaXVtLXNlcnZlckB0aGF3dGUuY29tMB4XDTA2MDQyMTAxMDc0NVoXDTA3MDQyMTAxMDc0NVow

aDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDU1vdW50YWluIFZpZX cxEzARBgNVBAoTCkdvb2dsZSBJbmMxFzAVBgNVBAMTDnd3dy5nb29nbGUuY29tMIGfMA0GCSqGSIb3D QEBAQUAA4GNADCBiQKBgQC/e2Vs8U33fRDk5NNpNgkB1zKw4rqTozmfwty7eTEI8PVH1Bf6nthocQ9d9SgJ

AI2WOBP4grPj7MqOdXMTFWGDfiTnwes16G7NZlyh6peT68r7ifrwSsVLisJp6pUf31M5Z3D88b+Yy4PED

7BJaTxq6NNmP1vYUJeXsGSGrV6FUQIDAQABo4GmMIGjMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr BgEFBQcDAjBABgNVHR8EOTA3MDWgM6Axhi9odHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUHJlbWl1bV NlcnZlckNBLmNybDAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLnRo

YXd0ZS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQADlTbBdVY6LD1nHWkhT

admzuWq2rWE0KO3Ay+7EleYWPOo+EST315QLpU6pQgblgobGoI5x/fUg2U8WiYj1I1cbavhX2h1hda3FJW

nB3SiXaiuDTsGxQ267EwCVWD5bCrSWa64ilSJTgiUmzAv0a2W8YHXdG08+nYcX/dVk5WRTw==-----END CERTIFICATE-----subject=/C=US/ST=California/L=Mountain View/O=Google

Inc/CN=https://www.doczj.com/doc/5f386666.html,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@https://www.doczj.com/doc/5f386666.html,---No client certificate CA names sent---Ciphers common between both SSL endpoints:RC4-MD5 EXP-RC4-MD5 RC2-CBC-MD5EXP-RC2-CBC-MD5 DES-CBC-MD5 DES-CBC3-MD5RC4-64-MD5---SSL handshake has read 1023 bytes and written 333 bytes---New, SSLv2, Cipher is DES-CBC3-MD5Server public key is 1024 bitCompression: NONEExpansion: NONESSL-Session: Protocol : SSLv2 Cipher : DES-CBC3-MD5Session-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

例4.中间人攻击

为了帮助读者理解中间人攻击,我们举一个现实例子。罪犯冒充公安人员给受害者打电话,说有人利用用户的网络银行帐号进行洗钱活动,公安机关要求该用户协助调查,给出其帐号的具体信息,包括密码。如果用户上当,交出了密码等信息,那么犯罪分子就可以利用这些信息洗劫账户内的资金。这就是一种典型的中间人攻击。

下面是一个Web环境下的中间人攻击示意图。

图1 中间人攻击示意图

首先,在IE浏览器的地址栏输入登录地址,如下图所示:

然后,利用代理篡改返回的数据包,让它返回502错误(或其他错误),并插入一个iframe,让浏览器请求真实地址,同时插入一段如下所示的脚本:

这样就能读取iframe的内容,如下图所示:

图4 读取的iframe内容

实际上,攻击者不仅能够读取该iframe的内容,还能够向该域进行提交。在真实的攻击环境中,攻击者可以读取防止跨站请求伪造令牌,实施跨站请求攻击,甚至截获用户名和密码。

四、白盒测试

对于提供https服务的web服务器,要仔细检查其配臵;如果Web应用程序提供了其他使用SSL/TL S封装的服务,也应当对其进行仔细检查。例如,以下Microsoft Windows 2003的注册表路径定义了服务器可用的加密技术:

EY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\

五、测试SSL证书的有效性

通过https协议访问Web应用程序时,就会在客户端(通常为浏览器)和服务器之间建立一个安全信道。然后,通过数字证书为通信的一方(服务器)或双方(客户和服务器)建立身份标识。为了进行通信,这些证书需要通过多道检测。基于SSL和证书的身份验证超出了本文的范围,我们这里主要探讨证书有效性的主要标准:检查认证中心是否是可信的机构;检查证书当前的有效性;站点名称和证书中所声称的是否一致。要经常升级您的浏览器,因为CA证书也会过期,在浏览器的不同版本中,CA证书会重新生成。另外,因为越来越多的网站要求强度高于40或者56位的加密,这时也需要更新浏览器,因为一些老版本不支持这些高强度加密。下面我们做进一步的解释。

1.每个浏览器都带有一个预装的受信CA列表,当我们收到证书时,可以到签发该证书的认证中心C A去验证一下。当然,这个列表是可以随意定制和扩展的。在与https服务器的初步磋商期间,如果服务器证书是浏览器不了解的认证中心签发的,那么就会抛出一个警告。出现这种情况,一般是因为Web 应用程序的证书是由一个自建的认证中心所签发的。对于内部网环境来说,自建认证中心是比较合适

的,因为企业web电子邮件是通过https传输的,同时,企业内的所有用户都会信任这个内部认证中心。但是,当通过Internet向公众提供服务时,则需要使用一个所有公共用户都信任的认证中心。

2.证书都有一个有效期,因此,它也是会过期的。同样,如果证书过期的话,浏览器也会抛出一个警告。公用服务需要一个暂时有效的证书;否则,当我们跟一个服务器通信时,只要它的证书是受信任的认证中心颁发的,即使过期也无需重新生成。

3.如果证书中的名称跟服务器的名称不相配怎么办呢?如果出现这种情况,就说明很可疑。一个系统可以托管许多基于名称的虚拟主机,这些虚拟主机共享同一个IP地址,彼此靠HTTP 1.1的Host:头部相互区别。在这个例子中,因为在处理HTTP请求之前,SSL握手时会检查服务器证书,所以它不可能为每个虚拟服务器分配不同的证书。因此,如果站点的名称和证书中所指出的名称不匹配,那么我们浏览器就会发出通知。为了避免这种情况,必须使用基于IP的虚拟服务器。 RFC2817(http://www.ietf. org/rfc/rfc2817.txt)和RFC3546(https://www.doczj.com/doc/5f386666.html,/rfc/rfc3546.tx)这两个文档描述了处理这个问题并允许正确引用基于名称的虚拟主机的方法。

证书有效性的黑盒测试

下面介绍如何检查应用程序使用的证书的有效性。当浏览器遇到过期的证书、由不可信的认证中心签发的证书以及证书上的名称跟服务器名称不一致时,它就会发出一个警告。访问https站点的时候,我们只要单击在浏览器窗口中的“锁”图标,就能看到与证书有关的信息,如证书签发机构、有效期、加密特性等。

如果应用程序要求客户端证书,那也不要紧,因为访问该程序之前我们很可能已经安装过证书,所以可以通过查看浏览器证书列表中已安装的的相关证书来获得必要的证书信息。

对于应用程序所用的所有SSL通信信道,必须进行上述检查。虽然https服务通常运行在443端口上,但还可能有依赖这个Web应用程序的其它服务,从而导致https管理端口一直打开,或者在非标准的端口上运行https服务,等等。因此,要对所有已经发现的使用SSL进行封装的端口进行检查,比如,nmap扫描程序提供了一个扫描模式——需要在命令行中加上–sV选项来启用该模式——专门用来查找使用SSL进行封装的服务。安全漏洞扫描程序Nessus也能对所有使用SSL/TLS封装的服务进行检查。

以下截屏取自一个公司的站点。它是一个Microsoft IE发出的警告,呵呵,我们要访问的是一个. it站点,而该证书却是发给一个.com 站点的?! IE警告说,证书上的名称与站点的名称不匹配。

图5 证书有效性黑盒测试举例

证书有效性的白盒测试

在服务器和客户端级别都检查应用程序所用的证书的有效性。证书最初是应用在Web 服务器级别的,然而,SSL还可能用来保护其它通信路径,例如DBMS使用的路径。您应该检查应用程序体系结构来寻找所有的SSL保护的通道。

六、测试工具

下面介绍在测试加密信道的安全性的时候,可能有到的测试工具:

安全漏洞扫描器可以检查证书的有效性,包括名称匹配情况和过期情况。此外,它们通常还报告其他信息,诸如颁发证书的机构等等。请记住,哪些CA是可信的,完全取决于人们的观念和软件的配臵;不过,浏览器通常带有一组预设的可信认证中心。如果您的Web应用程序使用的CA没有位于这个列表中的话,例如依靠一个自建的认证中心,那么您应该让用户重新配臵他们的浏览器,让浏览器认可这个认证中心。

扫描程序Nessus有一个插件可以用来检查已经过期的证书、或者在60天内将过期的证书。该插件的id为15901,名字为SSL certificate expiry。这个插件将检查安装在服务器上的证书。

有的安全漏洞扫描器也能检查弱密码,比如,扫描程序Nessus,它就能指出存在的SSL弱密码。

此外,我们还可能需要一些特殊的工具,例如SSL Digger(https://www.doczj.com/doc/5f386666.html,/resource s/proddesc/ssldigger.htm);或者Openssl工具,它能直接从UNIX命令行下访问Openssl加密函数。为了识别基于SSL的服务,可以使用具有服务识别能力的安全漏洞扫描程序或者端口扫描程序。扫描程序nmap具有一个-sV扫描选项,用以识别服务;安全漏洞扫描程序Nessus则能识别在任意的端口上的基于SSL的服务,并对这些服务进行安全漏洞检查——不管它们是在标准端口还是非标准的端口上。

如果需要与SSL服务交互但是您喜爱的工具却不支持SSL的话,可以求助于SSL代理,例如stunn el,它能在底层协议中打通隧道跟SSL服务进行通信。

最后,尽管人们乐于使用常规浏览器来检查证书,但是浏览器通常具有许多漏洞,此外浏览器进行检测时可能受到许多不易察觉的配臵设臵的影响。相反,依靠安全漏洞扫描器或者专门的工具来进行检查则要好得多。

相关主题
文本预览
相关文档 最新文档