SSL POODLE漏洞修复

发布时间:2018-01-11 16:13:42

关于SSL POODLE漏洞

POODLE = Padding Oracle On Downgraded Legacy Encryption,是最新安全漏洞(CVE-2014-3566)的代号,俗称贵兵犬漏洞。 此漏洞是针对SSL3.0CBC模式加密算法的一种padding oracle攻击,可以让攻击者获取SSL通信中的部分信息明文,如果将明文中的重要部分获取了,比如cookie,session,则信息的安全出现了隐患。

从本质上说,这是SSL设计上的缺陷,SSL先认证再加密是不安全的。

如何检测漏洞

一种方式是通过我们在线检测工具https://myssl.com/ssl_poodle.html

另一种方式,使用我们云检测工具https://www.sslcloud.cn/#/login

1.jpg

应对措施:

禁用sslv3协议

不同的web server不尽相同。这边列举主流的服务器的禁用方式:

  • Nginx

ssl_protocols TLSv1 TLSv1.1 TLSv1.2

  • apache

SSLProtocol all -SSLv2 -SSLv3

  • IIS

使用我们的套件工具http://www.trustasia.com/down/ssltools.zip

2.jpg

  • Tomcat

  • Tomcat 5 and 6 (prior to 6.0.38) 


            <Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"

                             maxThreads="150" SSLEnabled="true" scheme="https" secure="true"

                             clientAuth="false" sslProtocols = "TLSv1,TLSv1.1,TLSv1.2" />


  • Tomcat 6 (6.0.38 and later) and 7


            <Connector port="8443" 

protocol="org.apache.coyote.http11.Http11Protocol"

                      maxThreads="150" SSLEnabled="true" scheme="https" 

secure="true"

                      clientAuth="false" sslEnabledProtocols = 

"TLSv1,TLSv1.1,TLSv1.2" />


  • 使用aprtomcat


<Connector port="443" maxHttpHeaderSize="8192"

                       maxThreads="150"

                       enableLookups="false" disableUploadTimeout="true"

                       acceptCount="100" scheme="https" secure="true"

                       SSLEnabled="true" 

                       SSLProtocol="TLSv1"

SSLCertificateFile="${catalina.base}/conf/localhost.crt"

SSLCertificateKeyFile="${catalina.base}/conf/localhost.key" />


其余不常见可以去对应的官方主页检索资料,对于这次的漏洞,有竞争力的组织一定会做出应对的更新。

SSL POODLE原理

0x01 细节


首先考虑这个明文HTTP请求,它分成了 8字节的块,就像3DES加密,但是这个方法对16字节的AES块加密一样适用:

4.jpg

最后一个块里包含了7个字节的填充(padding),·来表示,最后一个字节7是填充长度,我用了虚构的8字节MAC校验码。在传输前,这些数据都会被3DES或者AES加密。现在来回顾下CBC解密的过程,这张图来自wikipedia:

3.jpg

攻击者可以控制HTTP请求中的路径和主体,从而让请求的内容满足如下条件:

后面的padding填充部分填充了一整个block。

cookie的第一个字节正好在某个块的末尾的字节。

攻击者需要做的是把包含cookie第一个字节(出现在这个块的末尾,例如块中的内容是 Cookie:aa正好在8字节块的末尾)的那个块,替换padding的那个块发送给接收者(服务器)

一般来说,服务器会拒绝这段密文,因为CBC校验失败了,攻击者需要重新发送,平均来说,每256个请求中有一个会被服务器接受,只要服务器接受了,根据CBC的解密过程,攻击者就知道了cookie的第一个字节(明文)的和上一个块最后一个字节的密文 XOR 后是 7或者15(分别对应块长度816)

作为中间人,我们可以看到任何一段密文,所以:

P XOR K = C

C XOR K = P

三个变量我们只要知道了两个就可以解密出另一个,所以 Cookie第一字节 XOR 密文最后一个字节 = 15。

我们只要把 15 XOR 密文最后一个字节就知道了cookie的第一个字节。

因为可以解密的窗口大小只有1字节(前面任意一个块的最后一个字节),所以需要通过js控制HTTP请求路径的长度,比如 GET/, GET /A, GET /AA...把需要解密的cookie的位置逐渐顶到解密窗口中,每次解密一个字节平均需要256次请求,攻击者就可以用256*n次构造的请求来解密SSLv3中任意位置的明文。

这个漏洞的主要成因是因为SSLv3没有规定padding填充块字节的内容,只校验填充块最后一个字节,因为TLS会检查填充块的内容所以在TLS上同样的攻击方式成功率只有2^-64或者2^-128

上一篇:  Exchange邮件服务器证书的导入及使用 下一篇:  什么是CSR以及CSR的作用和生成