关于SSL?POODLE漏洞

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

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

如何检测漏洞

? ? ??一种方式是通过我们在线检测工具http://www.601869.cn/tools/ssl-poodle-checker/

? ? ??另一种方式，使用我们SSLCloud?云监控系统持续监测?https://sslcloud.cn

?

应对措施

?禁用sslv3协议

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

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

?apache

SSLProtocol all -SSLv2 -SSLv3

1. ?

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

?Tomcat 5 and 6 (prior to 6.0.38)

? ? ??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

???

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

???????????????clientAuth="false"?sslEnabledProtocols?=?"TLSv1,TLSv1.1,TLSv1.2"?/>

使用apr的tomcat

<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"?/>

对于其他平台的修复方式 可以参考其官方文档，或者联系我们。

?＊注意事项：

Windows XP 系统下的 IE6 或以IE6作为内核的浏览器，默认不支持?SSL3.0以上的 加密协议。

若服务端关闭SSL3.0协议，需在此类客户端启用TLS 协议。

?SSL?POODLE原理

?0x01?细节

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

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

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

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

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

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

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

? ? ??作为中间人，我们可以看到任何一段密文，所以?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。