新闻报道

联系我们

  • 联系人:北京炼石网络技术有限公司
  • 电话:010-88459460
  • 地址:北京市海淀区人民大学南路大华天坛大厦二层
  • 邮编:100097

您现在的位置: 新闻报道»CGLab技术文章

针对DROWN溺水攻击的紧急修正说明

浏览:242   日期: 2016-03-29

在3月28日发出的关于DROWN溺水攻击的分析文章中,由于小编对专家观点的理解偏差,结论部分的表述可能会引起读者的误解,在此郑重声明致歉。本着严谨认真的态度,经过紧急研究和调研,我们将在此短文中从与应用场景结合的角度给出针对DROWN攻击的真正可行的应对方式。


一前文回顾在文章《DROWN—TLS-SSLv2跨协议攻击分析》(阅读该文章请点击文末左下角“阅读原文”)中,我们介绍了对SSL/TLS的跨协议攻击DROWN [2],通过将DROWN攻击所依赖的各项技术具化为五种工具详细介绍了DROWN攻击的技术细节。随后我们探讨了DROWN攻击得逞的本质以及一个治本的应对方法——RSA Optimal Asymmetric Encryption Padding(RSA-OAEP)方法。从理论角度来讲RSA-OAEP抵抗CCA2攻击的安全性是可形式化证明的,对Bleichenbacher攻击具有天然的免疫性,因此RSA-OAEP是解决Padding Oracle的治本方案,同时TLS 1.2的RFC5246中的相关描述也支持该观点,本文附录一对此有进一步展开说明。但是面对SSL/TLS标准既定的事实,RSA-OAEP的解决思路在生产实践中的可操作性仍待商榷。另一方面,虽然OpenSSL中提供了RSA-OAEP相关功能的API接口,但它并不是SSL/TLS已有协议的一部分,同时TLS涉及到大量已经部署的设备和协议本身无法被修改,从眼前来看如何将受影响的服务器尽可能快速可实现的补洞才是出路。


二结合应用场景的应对方式经过研讨,炼石网络CGLab认为,不能以一刀切的方式去处理,而是要结合不同的应用场景选择适合的方式来解决这个问题。当然,必须指出像在上一篇文章中提到的Export这种特殊时期留下的明显不安全的密码算法要全部关闭。


接下来,我们结合企业的业务场景来分析,先判断您的业务系统是否仍然依赖SSLv2。当然,这里的业务系统不局限于浏览器(注:未打补丁的IE6只支持SSLv2),或许还包括smtp、pop3等和与SSLv2绑定的遗留业务系统。场景1企业业务系统不依赖SSLv21.1 如果服务器支持重新配置或重新编译,则建议参考社区最佳实践关闭SSLv2配置或打补丁修复。


1.2 如果服务器难以重新编译或配置、或者难以定位还有哪些服务器开着与SSLV2相关的服务,则建议在防火墙或IPS直接对SSLv2阻断。以开源IPS软件Snort为例,把官方发布的规则Sid 1-38060在IPS部署模式下定制,可以达到阻断效果 [9] 。场景2企业业务系统依赖SSLv2 2.1 如果服务器支持重新编译,则建议参考社区最佳实践打补丁修复 [10] 。


2.2 如果服务器难以通过重新编译升级、或者难以定位还有哪些服务器开着与SSLV2相关的服务,同时业务系统不得不使用SSLv2,则建议企业在防火墙这一层增加安全策略,例如先使用IPS或防火墙先将不该连接SSLv2的场景进行阻断,然后使用SOC对SSLv2的大量失败连接进行统计,再手动或SOC自动联动IPS做出阻断。另外笔者经过咨询,支持用户自定义规则或策略的NGFW产品,也可以统计SSLv2的大量失败连接,触发规则并做出阻断。从纵深防御的角度看,IPS或防火墙上的附加安全策略也能应对服务器的修复失效。


进一步的思考,随着POODLE、CRIME到DROWN的一系列SSL/TLS协议或实现漏洞利用攻击的出现,包括更直接的Heartbleed漏洞,在IPS或防火墙这一层对于443等端口的流量异常监控是否应该成为企业安全体系的常态?



附录1:对RSA-OAEP的补充


DROWN攻击成功的两大因素在于古老的SSLv2协议仍然被众多服务器所支持以及SSL/TLS协议中采用的不具有CCA2安全特性的PKCS#1v1.5中的RSA算法。SSLv2协议被DROWN攻击利用的协议缺陷在于SSLv2协议中服务器接收到ClientMasterKey消息后总是解密RSA-PKCS#1v1.5密文,计算相应的server_write_key并立即发送ServerVerifyMessage。SSLv2协议中服务器端的这一连串的举动为后来的Bleichenbacher攻击得逞埋下了伏笔。于是1998年的CRYPTO会议上Bleichenbacher Daniel利用RSA-PKCS#1v1.5的缺陷并借助SSLv2的错误消息从而给出了Bleichenbacher攻击[1]。现有的SSL/TLS实现中抵抗Bleichenbacher攻击的方法——用随机数充当会话密钥来完成握手的方法是由Klíma等人在CHES 2003上提出的并得到广泛认可[3],这一点可从TLS 1.2的规范中RFC 5246看出。虽然RSA-OAEP早在1994年就已经提出[4]并在后来被证明具有CCA2安全特性,而且TLS协议的设计者也知晓RSA-OAEP的优势,但是囿于历史的泥沼以及“No variants of the Bleichenbacher attack are known to exist ”的论断TLS1.2仍然继续采用了RSA-PKCS#1v1.5的方式。DROWN攻击的出现证伪了这一论断,而TLS1.2的安全性也因此大打折扣。是的,过时的东西真的很难消失!Old things really die hard!面对这样的现实,虽然我们上一篇文章中的采用RSA-OAEP的建议在现有系统的维护方面并不具有太多实操性,但是作为对未来的工作的启示却仍具有启发意义。这方面的反例则是XML加密标准以及JSON Web Encryption(JWE)。XML加密标准于2002年发表,虽然早在4年前Bleichenbacher攻击就已经发表并获得广泛关注,XML加密标准仍然采用了RSA-PKCS#1v1.5标准[5]。而现在仍处于开发阶段的JSON Web Encryption(JWE)也仍然采用了RSA-PKCS#1v1.5标准[6]。而Jager等人用实际攻击展示了两种方案中采用RSA-PKCS#1v1.5所带来的安全隐患[7]。


附录2:参考文献


[1] Bleichenbacher, Daniel. "Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS# 1." Advances in Cryptology—CRYPTO'98. Springer Berlin Heidelberg, 1998.


[2] Aviram, Nimrod, Sebastian Schinzel, Juraj Somorovsky, Nadia Heninger, Maik Dankel,et al. "DROWN: Breaking TLS using SSLv2." http://www.lemarson.com/assets/upload/whitepaper/DROWN_SSL.pdf, 2016.



[3] Klima, Vlastimil, Ondrej Pokorný, and Tomáš Rosa. "Attacking RSA-based sessions in SSL/TLS." Cryptographic Hardware and Embedded Systems-CHES 2003. Springer Berlin Heidelberg, 426-440, 2003.


[4] Bellare, Mihir, and Phillip Rogaway. "Optimal asymmetric encryption."Advances in Cryptology—EUROCRYPT'94. Springer Berlin Heidelberg, 1994.


[5] Donald Eastlake, Joseph Reagle, Takeshi Imamura, Blair Dillaway, and Ed Simon. XML Encryption Syntax and Processing. W3C Recommendation, http://www.w3.org/TR/xmlenc-core, 2002.


[6] Hildebrand, Joe, and Michael Jones. "JSON Web Encryption (JWE).", https://tools.ietf.org/html/rfc7516, https://tools.ietf.org/html/rfc7516, 2015.


[7] Jager, Tibor, Sebastian Schinzel, and Juraj Somorovsky. "Bleichenbacher’s attack strikes again: breaking PKCS# 1 v1. 5 in XML Encryption." Computer Security–ESORICS 2012. Springer Berlin Heidelberg, 752-769, 2012.


[8] Drown跨协议攻击TLS漏洞分析 http://blog.baidu.com/archives/243,2016.


[9] https://snort.org/rule_docs/1-38060


[10] https://www.openssl.org/blog/blog/2016/03/01/an-openssl-users-guide-to-drown/


附录3:鸣谢


感谢Joe对上一篇文章的问题反馈以及对本文的指导。感谢华三公司侯叶飞、飞塔公司岑义涛对NGFW规则支持情况的反馈,也感谢HardenedLinux社区Shawn的反馈意见。