Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

SSL/TLS的近年相关攻击研究综述(五)

0
0
SSL/TLS的近年相关攻击研究综述(五) 协议实现不足的漏洞

作者:韦俊琳 清华大学

简介:SSL/TLS协议的设计是非常复杂的,其中在一些RFC的定义并没有被很好的实现,或者说在实现过程中存在偏差,导致存在着一些致命的漏洞。近几年有很多研究人员对TLS的实现做了深入的研究,如OpenSSL,MatrixSSL等,发现了一些比较有意义的漏洞,如HeartBleed,FREAK等。在发现漏洞的工程中,研究人员开发了很多新的方式,其中利用自动状态机来发现漏洞的方式就具有很强的影响力。

利用状态 检测漏洞 在TLS实现中,还存在着很多细节的问题需要解决。在[1]中,作者研究TLS握手的可验证安全性。通过mi TLS验证了许多协议版本,配置和密码套件的主流浏览器和服务器的互操作性,并为其提供了在应用层可证明的安全性。在TLS协议的实现中,必须处理各种版本协议和相关的扩展,认证模式和密钥交换的方法,而不同的组合在客户端和服务器端之间又形成了不同的消息序列。作者在[2]中设计复合状态机来解决不同协议模式之间的细节问题,通过系统测试一些流行的开源TLS,发现了多年来隐藏在这些库里面的几个关键性安全漏洞。自动状态机是第一个用C语言写的,进行过验证的TLS状态机综合实现,并且可以嵌入到OpenSSL中进行使用。利用论文中的方法可以对密码协议库的核心组件进行形式化验证。

经过20年的演变,TLS具有很多版本,扩展和密码套件,而且其中的一些已经不被使用或者已经被确认为不安全。但是,客户端和服务器端的实现要保证具有灵活性,互操作性,导致它们的部署中通常会支持不安全的密码套件。当然握手期间的TLS会话的特定参数会通过MAC来验证,确保不会被篡改,而且如果客户端或者服务器端仅支持安全协议版本,那不管对等方支持什么不安全的套件,也只能和安全方保持一致。而在具体实现中,就TLS1.0~TLS1.2而言,有一些细节地方不能被忽视。首先,协议中消息顺序是精心设计的,从互操作性和安全性的角度是不能随意更改的,比如ServerCCS消息就必须在ServerFinished消息之前发生。其次,客户端和服务器端必须要能区分真正可选的消息,而不是简单的线性接收和发送,类似于区分ServerNewSessionTicket和当前密钥交换消息。然后,不能过早地计算会话参数和秘钥,客户端应该在接收到服务器的消息后才确认握手过程。还有一些版本的协议,如SSLv23,DTLS都存在一些细节问题,在SSLv3中,客户端可能根本不发送ClientCertificate消息,而DTLS则允许服务器使用新的HelloVerifyRequest消息来响应ClientHello。在TLS库中,还实现了许多在网络上不常用的密码协议,如PSK,DHanon/ECDHanon,DHE PSK等,使用这些密钥套件时需要一些额外的协商参数。而对于重协商,在同一个连接上建立多个TLS握手,从逻辑上看,非常清晰,但是实现起来就相当棘手,也就导致了很多利用重协商漏洞的攻击。

作者利用[3]中开发的FLEXTLS工具来验证这些实现中的漏洞,该工具是建立在miTLS上,经过验证的TLS实现。利用强大的消息传送和密码库,FLEXTLS能够用来评估协议的漏洞。使用该工具,发现最近的对TLS实现的攻击,如SKIP和FREAK,以及为FREAK和Logjam提供第一个验证演示。在[2]中,作者也应用了FLEXTLS工具来进行评估验证,测出很多细节漏洞。如OpenSSL中EarlyCCS(CCS严格意义上不是handshake message,不出现handshake log中,不受客户端或服务器端状态机控制,可以出现在ServerHello后的任意位置,中间人通过在ServerHello之后向对方注入CCS消息,提前设置弱记录密钥,然后让他们完成握手,拦截合法的CCS消息), DH Certificate(client忽略ClientKeyExchange,可能导致client impersonationattack), Server-Gated Crypto(SGC允许客户端收到serverhello后重新握手,但是表明某些extension是否被使用的信息会在新握手中消失), Export RSA(512位弱签名),Static DH(使用DHE或者ECDHE时,如果证书包含ECDH公钥,而且客户端不接受ServerKeyExchange,则会回滚到static ECDH,用服务器证书的公钥,导致前向安全性丢失)。还有JSSE相关问题,如Client flaws(处理特定于某些密码的可选消息,客户端和服务器状态机都允许跳过消息,导致serverimpersonation attack), Server flaws(JSSE 服务器类似的允许客户端跳过消息)。还有一些关于NSS,Mono,CyaSSL和GnuTLS相关漏洞。这个状态机发现了很多实现过程中存在的漏洞,作者也对大部分漏洞进行了测试,验证漏洞的存在,并针对性的提出改进建议。 出血 Heartbleed是OpenSSL实现上存在的漏洞,通过发送特殊信号Heartbeat 给服务器,来查看服务器是否在线,当服务器在线时,会发送回复信息给主机,然后允许进行安全通信,服务器和主机会间断性的发送这个信号确保对方是否在线。心跳包设计之初是为了能够解决及时检测连接状态问题,相比TCP的keepAlive机制具有更大的灵活性,可以自己来控制检测的间隔和检测的方式。[4]

心脏出血漏洞最先是被谷歌安全中心的Neel Mehta提出来的,代码实现中没有对内容分配的限制,攻击者能够利用Heartbeat发送恶意信息给服务器,强制OpenSSL服务器读取任意内存位置,攻击者还能够控制心跳的大小和结构,然后利用TCP协议,在443端口接收请求,一次可以收到64kb的服务器内存数据,多次请求,攻击者能够得到更多的服务器内存信息,有可能包括大量的邮件地址,密码等信息。OpenSSL从1.0.1版本到1.0.1f版本都广泛存在心脏出血漏洞,可想而知,数量巨大的服务器都会受到影响,根据Netcraft估计,17%的服务器都受到了影响,大约在50万台。

当然最致命的是攻击者可以用这种方式来获取加密密钥,泄漏的密钥允许攻击者解密过去和未来的相关流量,并且可以随意假冒服务。而且X.509证书中的加密和签名提供的保护都可以被绕过,那么从此泄漏中恢复需要修补漏洞,并撤销被泄漏的密钥,重新发布和重新分发新密钥。即使这样做,攻击者仍然可以解密过去拦截的流量,这些都必须由服务的业主来完成。

对该问题的解决最有效的方式是打补丁,可以选择升级OpenSSL版本,也可以配置OpenSSL协议来删除对心跳协议的支持。由于攻击者可能获取到密钥,所以最好替换私钥,并且要想保证过去的加密信息无法被泄漏的服务器私钥影响,可以部署具有前向保密性的加密方式。

Freak Logjam 继Heartbleed后,OpenSSL又被公布了Freak(Factoring RSAExportKeys)漏洞,虽然这个漏洞的影响没有Heartbleed影响力那么大,但是很容易被中间人利用遭受中间人攻击。该漏洞源自于20世纪90年代,美国限制出口高强度的加密算法,限制加密强度最大为40位,密钥交换强度最大为512位。从现在的计算速度来看,这中出口密码套件的安全强度是非常弱的,任何人都可以在几小时内完成破解。进行FREAK攻击,需要克服两个障碍,首先被注入的消息需要被目标服务器上的强RSA签名,然后为了修改TLS握手的消息,攻击者需要伪造Finished消息,使得对消息的修改变得合法化。完成这个中间人攻击[2]: 在ClientHello 中要求一个标准的RSA密码套件 MITM攻击者将服务器消息改为“export RSA” 服务器使用512位export RSA进行响应,并使用其长期密钥进行签名 根据OpenSSL 的漏洞,客户端会接收这个弱键 攻击者对这个弱RSA进行破解,恢复RSA解密密钥 当客户端将发送预主密钥给服务器时,攻击者变可以解密它,恢复出TLS主密钥 攻击完成,可以注入任意内容

实际上不仅仅是OpenSSL收到这个攻击的影响,Android系统很多使用的OpenSSL库都存在了风险,而且随着攻击面的扩大,Apple的SSL/TLS(Secure Transport)和Microsoft的SSL/TLS库(Schannel)也收到了影响。对于Freak漏洞,只有建议各服务移除对出口密码套件的支持,因为这是这个攻击的必要条件。

在FREAK攻击之后,人们就把注意力集中到存在类似问题的Diffe-Hellman密钥交换算法上,把弱密钥交换机制进行移植,从而发布了新的漏洞Logjam。这个攻击复制了Freak攻击的原理,把RSA_export 替换成DHE_export。和FREAK不同的是服务器要愿意使用不安全的DH参数,还需要缓存临时的DH密钥,最后还要求客户端能够愿意接受这些弱DH参数。所以最重要的原因就是浏览器能够接受不安全的DH参数。实际上,攻破1024位参数的攻击者能够对6.56%的HTTPS服务器进行被动攻击,攻破了10个通用组的攻击者能够对约10%的服务器进行攻击。对于SSH,攻破一个标准组,能够使用被动攻击约360万的服务器,而IPsec则能攻击超过60%的服务器,影响力非常巨大。

缓解这个攻击其实也不难,首先禁用出口套件,然后升级DHE的套件,确保使用的是2048位,而不是1024位,或者完全禁用DHE算法。

总结

SSL/TLS协议设计是比较复杂的,在实现过程中很难全部参照RFC的标准,导致在实际应用中存在着很多的问题。随着近几年对TLS研究的深入,很多以前隐藏在实现中的问题,隐藏在库中的漏洞正在逐步被发现。通过不断的进行发掘,改进,升级,TLS也越来越能够被大众更加放心的使用。

参考文献: [ 1 ] K. Bhargavan, C. Fournet, M. Kohlweiss. Proving the TLS Handshake Secure (As It Is). In CRYPTO, 2014 [ 2 ] B. Beurdouche, K. Bhargavan, A. Delignat-Lavaud. A Messy State of the Union: Taming the Composite State Machines of TLS. In IEEE Symposium on Security and Privacy (Oakland), 2015 [ 3 ] B. Beurdouche, A. Delignat-Lavaud, N. Koberssi. FLEXTLS: A Tool for Testing TLS Implementations. In USENIX Workshop on Offensive Technologies (WOOT), 2015 [ 4 ] Z. Durumeric, J. Kasten, F. Li. The matter of Heartbleed. In ACM, 2014

Viewing all articles
Browse latest Browse all 12749

Latest Images

Trending Articles





Latest Images