POODLE漏洞分析

一、漏洞背景

10月14号由Google发现的POODLE漏洞(Padding Oracle On Downloaded Legacy Encryption vulnerability)，可被攻击者用来窃取采用SSL3.0版加密通信过程中的内容，又被称为“贵宾犬攻击”。虽然该攻击利用有一定的难度，需要完全控制网络流量，但在公共wifi遍地都是和强调国家之间对抗的APT背景下，该漏洞仍有不小的影响，我们的小伙伴也紧急分析了漏洞原理，poc仍在验证中，稍后放出。

二、SSLv3.0协议基础

协议协商数据

在协议握手阶段，协商的数据包括：

明文/密文分组长度：长度一般为16字节。

初始化向量IV：根据SSLv3.0协议定义的算法生成，要求随机性较高，与明文/密文分组长度相同(16字节)。

对称密钥Key：即SSLv3.0协议中定义的主密钥(the Master Secret)，用于数据加密。

加密模式：常见的加密模式有多种，本漏洞本质就是SSLv3.0协议推荐的CBC加密模式可能泄露信息。

数据填充与分组

明文加密之前和密文解密之前需要分组，每个分组长度为128比特，即16字节。

对于待加密的明文数据，分组处理过程为：

(1)计算明文签名MAC(Message Authentication Code，消息验证码)序列，长度为20字节。

(2)将MAC序列附在明文数据之后组成平文(Plaintext)，将Plaintext的长度填充至16字节的整数倍。

填充方式为：如果原始Plaintext长度不是16字节的整数倍，再其后附加零个、一个或多个Padding字节，再附加1个字节，其值为Padding长度;如果原始Plaintext长度正好是16字节的整数倍，则在其后附加15字节长度的Padding序列，再附加1个Padding长度，其值为15。

(3)将填充后Plaintext每16字节分为一组，称为平文块(Plaintext Block)，使用符号P1 , P2 … Pn 表示。

初始化向量IV用于首次加密，此时使用P0表示。

对于待解密的密文数据，由于数据长度肯定为16字节的整数倍，所以其直接按照16字节长度分组，每个分组称为密文块(Cipher Block)，使用符号C1 , C2 … Cn表示。

初始化向量IV用于首次解密，此时使用C0表示。

CBC模式原理

在CBC模式中，每个平文块(Plaintext Block，即明文分组块)先与前一个密文块(Cipher Block)进行异或后，再进行加密。在这种方法中，每个密文块都依赖于它前面的所有平文块。同时，为了保证每条消息的唯一性，在加解密过程初期需要使用初始化向量IV。

基于CBC加密模式的对称加密流程如下图：

即，对于每一个平文块Pi，得到密文块Ci：

换个角度考虑，平文中的微小改变会导致其后的全部密文块发生改变。

基于CBC加密模式的对称加密流程如下图：

即，对于每一个密文块Ci，得到平文块Pi：

因此，如果密文块Ci被修改，不会影响对密文块Ci-1的解密结果，而Ci及Ci之后的解密结果Pi’，Pi+1’ … Pn’ 将与原始的Pi，Pi+1 … Pn不同。

从密文得到平文后，服务端会立即验证明文的MAC以确保数据有效性，根据前述的平文填充方式，SSLv3.0协议定义的验证原理为：

(1)根据平文数据最后一个字节的得到Padding序列长度，移除该字节以及Padding序列后，平文的最后20字节数据是客户端计算得到的MAC序列。

(2)移除该MAC序列得到的数据是明文数据，服务端重新计算该段数据的MAC序列并与客户端MAC序列对比，即可确定数据是否有效。

三、POODLE漏洞分析

根据之前所述，如果明文数据的长度加20字节的MAC序列长度正好为16字节的整数倍，平文Padding算法会在Plaintext的最后附加15字节的Padding序列和1字节的Padding序列长度(值15)，即最终的平文的最后16字节属于附加部分，加密后对应密文分组的最后一个密文块Cn。该在这种情况下，如果使用密文中的某一个密文块Ci替换密文块Cn并发送给服务端，服务端有可能认为数据是有效的，满足这种可能性必须要求解密后的数据最后一个字节值是15，这样恰好既不影响原始明文序列，也不影响MAC序列，从而通过服务端对MAC序列的验证。

定义密钥为k的对称加密算法的加密过程和解密过程分别为Dk( )和Ek( )。

此时：

Pn’= Dk(Cn’)⊕Cn-1 = Dk(Ci)⊕Cn-1

且

Pn’[15] = 15

即：

Dk(Ci)[15]⊕Cn-1 [15]= 15

由于：

Pi[15] = Dk(Ci)[15]⊕Ci-1[15]

所以：

Pi[15] = 15⊕Cn-1 [15]⊕Ci-1[15]

很明显，此时密文块Ci对应的平文块Pi的最后一个字节可以通过计算得到。

四、POODLE漏洞利用

到此，在前述假定的条件下仅仅解密一个字节的数据并无任何实际意义，然而，Google安全研究员在其发布的分析报告This POODLE Bites: Exploiting The SSL 3.0 Fallback 中考虑了这样一个针对HTTPS协议的攻击场景：

(1)攻击者可以实施中间人攻击，控制用户流量以及控制客户端发送AJAX请求;

(2)攻击者的目标是获取用户的cookies;

(3)攻击者已经知道cookies数据长度。

对于(3)条假设并不一定完全成立，这里首先假定在其成立的条件下考虑POODLE漏洞的利用方式。

假设请求明文的Plaintext如下：

POST /path Cookie:…\r\n\r\nbody ‖ 20­bytes-MAC ‖ 15-bytes-padding || 15

攻击者可以控制path和body的长度使上述Plaintext的长度为16字节的整数倍，并且，由于已知cookies的长度，控制欲解密的cookies字节位于某个平文块Pi的最后一个字节上。

首先，设置客户端请求使P5[15] = ‘e’，请求加密前的Plaintext为：

图 计算第一个数据

中间人截获密文Ciphertext之后使用C5代替C11后传递请求，如果发现服务端解密后验证失败，控制客户端变换请求的path内容再发送，一般经过不超过256次变换，可能会有一次使服务器解密后验证成功，即中间人可以根据上面介绍过的方式计算得出该处明文字节数据。

然后，控制客户端请求的path长度和body长度，比如path长度加1同时body长度减1：

图 计算第二个数据

继续发送请求、中间人拦截替换再发送等操作，依次可以分析出整个cookies数据。

在cookies长度不确定的情况下，可以通过控制增加客户端的path长度并对比密文Ciphertext长度，基本在16个请求以内就可以确定其实际长度。比如：

第一次请求的Plaintext为：

GET /\r\nCookie: n1=v1\r\n\r\n || 20­bytes-MAC ‖ padding

即：

图 计算cookies长度的第一次Plaintext

此时，Ciphertext的总长度为48字节。

第二次请求的Plaintext为：

GET /A\r\nCookie: n1=v1\r\n\r\n || 20­bytes-MAC ‖ padding

图 计算cookies长度的第二次Plaintext

此时，Ciphertext的总长度为48字节。

第三次请求的Plaintext为：

GET /AA\r\nCookie: n1=v1\r\n\r\n || 20­bytes-MAC ‖ padding

图 计算cookies长度的第三次Plaintext

此时，Ciphertext的总长度为48字节。

第四次请求的Plaintext为：

GET /AAA\r\nCookie: n1=v1\r\n\r\n || 20­bytes-MAC ‖ padding

图 计算cookies长度的第四次Plaintext

此时，Ciphertext的总长度为48字节。

第五次请求的Plaintext为：

GET /AAAA\r\nCookie: n1=v1\r\n\r\n || 20­bytes-MAC ‖ padding

图 计算cookies长度的第五次Plaintext

此时，Ciphertext的总长度为64字节，从而知道第一次的Ciphertext的总Padding长度为4字节(3字节Padding序列和1字节的Padding序列长度)，而Ciphertext总长度为48字节，“GET /\r\n”序列长度7字节，MAC序列长度为20字节，所以“Cookie: n=v\r\n\r\n”长度为15字节。

参考：

[1] RFC6101： http://tools.ietf.org/html/rfc6101

[2] Google分析报告：https://www.openssl.org/~bodo/ssl-poodle.pdf

[3] 块密码的工作模式：

http://zh.wikipedia.org/wiki/%E5%9D%97%E5%AF%86%E7%A0%81%E7%9A%84%E5%B7%A5%E4%BD%9C%E6%A8%A1%E5%BC%8F

分享名称：POODLE漏洞分析
网页URL：http://www.shufengxianlan.com/qtweb/news0/432450.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联