漏洞分析---SSLv3降级加密协议Padding Oracle攻击（POODLE）技术分析

SSLv3降级加密协议Padding Oracle攻击（POODLE）技术分析

 

转自爱毒霸社区，原文链接：http://bbs.duba.net/thread-23222323-1-1.html

 

一、漏洞概述

        SSL 3.0的历史非常久远，已经有将近15年了，现今几乎所有的浏览器都支持该协议。今天该协议爆出了一个漏洞，该漏洞由谷歌公司率先发现，下面是此漏洞的大致描述。
        攻击者可利用该漏洞获取安全连接当中某些是SSLv3加密后的明文内容。因为兼容性问题，当浏览器进行HTTPS连接失败的时候，将会尝试使用旧的协议版本，这其中就包括SSL 3.0，于是加密协议由更加安全的协议（比如：TLS 1.0）降级成SSL 3.0。
        攻击者在此漏洞利用中扮演一种中间人的角色，比如A，C进行通信，B（攻击者）在中间作为一个代理，B截获A，C之间的通信后经过SSLv3加密后的数据包，利用SSLv3中存在的漏洞，解密得到其数据包的明文信息，而这些明文信息极有可能是用户的隐私数据，比如cookie，这样攻击者就可以拿到这些隐私数据，进行更深层次的攻击
        由此可见此，黑客们可以利用此漏洞。截获用户的隐私数据，进而造成了用户隐私的泄漏，危害较大，应当引起我们的高度重视，而现今唯一解决该问题的方式就是禁用SSLv3加密协议。
 

二、漏洞细节

        以下是一个会受到Padding Oracle影响的信道：

1. A和C沟通，其中含有敏感数据使用SSLv3加密；
2. 有一个中间人B代理A和C的通信，其中A和B采用明文传输例如http协议（但A不会发送任何敏感数据到B）；
3. B可以让A对C发出多次请求（比如通过脚本化）并且可以通过控制脚本来控制A发出的请求包的长度和敏感信息的位置（请见技术分析中阐述的一个web请求实例）；
4. B可以截获并修改A发送到C的SSL记录（如果B本身既是代理也是A的出口网关）。

        目标是通过Padding Oracle攻击拿到SSLv3所加密的敏感信息的明文，下面给出一个不安全的web请求场景并对其做技术分析。

(1).场景描述：

        假定A要访问C并且通过B，而B是一个基于Java Script 的代理请求引擎，B可以指定Java Script 的内容但B绝对不会收集任何敏感信息。但B的脚本可以让A使用SSL3.0发送多个HTTPS请求到C并且B可以截获并修改由A发送到C的SSL记录。在SSLv3工作在CBC（cipher-block chaining密文块串联）加密模式的情况下会受到Padding Oracle攻击方式的影响而还原加密包中的明文例如web cookie。

(2).技术分析：

图1： CBC加密过程

         为了保证数据流按加密块粒度对齐，CBC模式下的SSLv3采用末尾填充机制，填充数据长度为1到L中的任意一个值，L为块粒度，以字节为单位，一般是8或者16。在填充数据长度为L时攻击最易于实现，其中填充数据为含有L-1个字节的任意数据加上最后一个字节其值一定为L-1。处理这样一个由n+1个密文块组成的加密请求C0C1 ... Cn（其中C0是起始块）的过程是首先依据解密算法

 

Pi = Dk(Ci) ⊕ Ci-1（Dk是使用连接key解密的函数）

 

算出P1 ... Pn然后检测Pn末尾字节是否为L-1，然后去除该填充验证并移除MAC（Message Authentication Code信息授权码）后接受数据。

         问题出现在SSLv3协议只验证填充块Pn最后一个字节的值是否为填充块长度减1。在填充块大小为L时Pn[L-1]的值如果为L-1则授权通过。这为攻击者提供了一个窥探C1 ... Cn中Ci的一个明文字节即Ci[L-1]的方法那就是强行将Cn块替换为Ci然后发给目标服务器，有1/256的可能性会通过服务器的验证。只要通过服务器验证，则可以通过以下公式反推明文块中Pi[L-1]的值：

Pi[L-1] = (L-1) ⊕ Cn-1[L-1] ⊕ Ci-1

可以看到L和C0C1 ... Cn都为已知值。如此一来黑客通过发送大量请求（平均256*n个包）并且改变数据包数据的相对位置可以通过密文块逐字节推断出数据包中长度为n的明文，以上提到的基于Java Script的网关可以实现上述攻击。

(3).构造一个SSLv3的web中间人攻击：

 

        如果B服务器上的Java Script可以让A发送大量带 cookie 的请求，例如让A去访问一个社交网站而A本身保存有那个社交网站的cookie（根据cookie机制每次请求肯定会使用同样的cookie）。通过构造大量SSLv3请求再结合截包替换SSL数据可以做到逐字节还原cookie字段，而在这种情况下cookie作为敏感信息，地位和用户名+密码 是相同的。
 

下面假设填充粒度为8字节，某社交网站的cookie为abcdefgh。

 

• 首先Java Script 可以让用户A生成一个图中第一行所示的明文web请求包...

 

B服务器拿到使用CBC模式下的SSLv3数据然后将最末尾块替换为左起第四个块的密文然后反复发送这个包直到解密后的Cn[7]碰巧为7（因为每次连接key都不同），收到连接成功信息。使用之前介绍的反推公式（L为8代入）可以反推出cookie字段第8字节为’h’

• 然后通过填充请求路径字段让A生成一个图中第二行所示的“右移1字节”的请求包...

同样方法可以推算出cookie字段第7字节’g’。

• 依此类推直到获取整个cookie值”abcdefg”。此时黑客通过中间人攻击已经获得用户cookie，用户隐私暴露无遗。

 

 

三、解决方案

 

 

        目前解决该问题可以禁用SSL3.0，或者SSL3.0中使用的CBC模式加密，但是有可能造成兼容性问题。建议支持TLS_FALLBACK_SCSV，这可以解决重试连接失败的问题，从而防止攻击者强制浏览器使用SSL3.0。 它还可以防止降级到TLS1.2至1.1或1.0，可能有助于防止未来的攻击。

3.1 网站管理员 

(1).Apache

(2).Nginx

 

 

3.2 普通用户

 

(1) Firefox用户

 

(2) Chrome用户

• 编辑/usr/share/applications/google-chrome.desktop文件
• 编辑所有Exec=的行，并在后 面 加入--ssl-version-min=tls1。比如：

将

 

Exec=/usr/bin/google-chrome-stable %U

 

修改为：

Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U

 

• 最后重启您的Chrome浏览器

 

 

(3) IE浏览器用户：

       Internet选项--> 高级 --> 使用SSL 3.0 （去除多选框）

 

 

 

 

 

四、相关文章

 

1. tech2ipo：《Google 披露 SSL 3.0 安全漏洞（附修复方法）》
2. imperialviolet：《POODLE attacks on SSLv3 (14 Oct 2014)》
3. FreeBuf：《SSL v3 Poodle安全漏洞修复建议》
4. 知乎：《Bash 漏洞是什么级别的漏洞，有什么危害，具体如何修复？》