POODLE攻击是针对SSLv3中CBC模式加密算法的一种padding oracle攻击。这个攻击方式和之前的BEAST攻击方式很像,可以让攻击者获取SSL通信中的部分信息的明文,比如cookie。和BEAST不同的是,它不需要对明文内容的完全控制,所以操作起来更加贴近实战。
从根本上说,这是SSL设计上的问题,就像 Lucky13 和 Vaudenay's two atacks 这些漏洞里面描述的一样,SSL的加密和认证过程搞反了,SSL先进行认证之后再加密。
首先考虑这个明文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。
把SSLv3关了,SSLv3已经过期用了15年了。
参考: a54K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2A6L8i4m8W2M7X3W2S2L8s2k6A6L8$3I4W2N6q4)9J5k6h3!0J5k6#2)9J5c8U0t1H3x3e0c8Q4x3V1j5I4x3q4)9J5c8U0p5@1i4K6u0r3M7r3!0G2k6r3I4W2i4K6u0W2K9s2c8E0L8l9`.`. dbcK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2G2M7r3g2F1M7%4y4D9i4K6u0W2L8%4u0Y4i4K6u0r3i4K6N6q4j5X3!0V1L8#2)9J5c8Y4y4K6L8q4)9J5k6s2m8G2L8$3c8D9k6g2)9J5k6i4m8V1k6R3`.`.