Rizzo/Duong CBC BEAST 攻击的安全影响

第一次翻译英语的技术文章，有些词还把握的不准，于是，就直接使用原单词替换，如有错误还望指正！

原文链接地址： http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html

译文如下：

如果你熟悉网络安全,并且没有与世隔绝的话，你可能已经看过最近的关于Rizzo和Duong关于SSL / TLS攻击的实现的报道。他们已经做了攻击的演示，而且，相关信息已经逐渐传出，我们可以开始评估这个攻击的影响。（可以参考AGL's post）。不幸的是，没有公开的有效的论文，而且通过在线的聊天提出的问题也大多没有答案。

首先，最基本的底线是：不要恐慌。是的，这是有趣的工作，没有SSL/TLS被完全破解。特别是，你和你银行的通讯是很可能是没有问题的。尤其，AGL表明Chrome是好的。

 

背景：CBC加密

为了理解接下来的内容，你需要一些背景知识。SSL/TLS能用两种加密方式加密数据：一种方式是块加密,像AES和DES；另外一种加密方式是流加密，像RC4。你现在不用担心流加密，SSLBeast攻击只适用于块加密。块加密的方式是基于密钥的将明文块（典型的是128位）映射到同样大小的密文块。因此，这就好像有了一个巨大的有2^128个条目的表格显示每个明文块M和它相应的密文块C。每一个密钥代表一个不同的表格。我们用方程式C=E（Key,M）表示我们计算Key和明文M的加密，结果是密文。

使用块加密的一个常用的方法就是将明文分成128位的块，然后，独自加密每一个块（这是ECB模式）。这得到的结果是：如果两个明文块的内容是一样的，那么加密的内容也是一样的，这是不好的。可以通过Wikipedia article了解这种方式是多么的不好。为了避免这个问题，其他的加密模式已经被开发出来。被SSL/TLS使用的（至少是TLS1.2以前的版本）是叫做CBC模式。CBC模式工作的方法是当加密第i块的时候，和第i-1块的密文异或。更正式地表达如下：

C_i= E(Key, C_i-1 ⊕ M_i)

很显然，当你加密第一块的时候，没有前一块的密文和它异或，因此，标准的做法是产生一个随机的初始化向量（IV），并且用它和第一块明文异或。第一块M0的加密如下:

C₀= E(Key, IV ⊕ M₀).

然后，接着第一块M₁加密如下：

C₁= E(Key, C₀ ⊕ M₁).

现在，除非C₀ 碰巧和IV一样（这是非常不可能的），那么，即使M₀ = M_1，对于加密函数来说，两个输入是不同的，因此，C₀≠ C_1， 这样就可以打破ECB的模式。

 

SSL/TLS是如何使用CBC的？

我上面描述的CBC就像你只是加密单个二进制大数据（例如一个文件）包含一些数据块。然而，SSL/TLS是一个加密协议通道，因此它需要加密的不是一个单独的文件，而是一系列的通讯的记录。例如，你可能用一个SSL/TLS链接传输一连串的HTTP请求，每一个请求被分成一个或者多个记录，可能会花上几秒钟到几分钟的时间发送完。所有的记录（在每一个方向上）是用一个密钥加密的。

 

在这种环境上，CBC有两种的基本的使用方法：

          1.        对于每条记录都认为是独立的；为每一个记录产生一个IV

          2.        把所有的记录当作一个链接在一起的大对象，并且在记录之间继续使用CBC的状态。这意味着最后一条记录n的IV是n-1条记录的密文。

SSLV3和TLS1.0选择的是第二个用法。这好像本来就是个错误，有两种原因可以说明，第一个原因（比较琐碎），它是的TLS很难用于数据报传输（hence DTLS），第二个原因，它有安全问题。

 

最初的可预测的IV问题

让我们回到2004年，Moeller [*]发现在一定的环境下可以利用这种行为。（最初观察到这种攻击类型的似乎应归功于Rogaway[*] 并且后来又扩展到SSH by Wei Dai.) 想像一下,你是一个攻击者，你可以使SSL/TLS的一端加密一些你选择的数据。这样的话，即使通常不允许看的其他部分的明文，你也可以推测出它的内容。

举一个实例，在Alice和Bob之间有一个链接，你观察到一个记录，你知道这条记录包含Alice的密码在i块，例如，M_i 是Alice的密码，假设你猜测Alice的密码可能是P。现在，如果你知道下一个记录将会用IV X加密，你可以注入一个选择的记录，注入如下：

X ⊕ C_i-1 ⊕ P

当这个注入的内容被加密，X会被异或，结果传给加密算法的明文块如下：

C_i-1 ⊕ P

如果P==M_i ， 新的密文块将和C_i一样，这意味着，你的猜测是正确的。

 

问题变成攻击者是如何知道下一个IV的呢？然而，因为记录j的IV是记录j-1的密文，所有的攻击者需要做的事情就是观察数据流，并且确认所注入的作为下一个记录的数据，使用前一个记录的密文作为IV。

 

可以看出这样攻击很麻烦，但不是一个了不起的攻击。第一，攻击者需要能够在相同的SSL/TLS链接上，以某种方法将他能够控制的通讯内容和他不能控制、不能看到的通讯内容混合在一起。这不是不可能；例如他有可能发生在SSL-VPN，但是，这也不常见。第二，他一次只能让你猜测整个明文块，因此，即使你猜测一个非常低entropy的值，需要大量的猜测来搜索整个空间。

 

这仍然是一个足够严重的问题使得IETF觉得值得修复，并且TLS工作组按时地开发了TLS1.1，TLS1.1使用第一个策略（标准称为“explicit IV”）。[技术要点:需要的防御实际上稍微复杂，因为，你需要在揭漏IV之前，使用TLS的应用提交整个明文块。]TLS1.1在2006年开发的，但是部署一直很有限([*])。虽然我们不知道为什么，但是我认为安全团体普遍认为此威胁没有足够严重到促使大家升级。

 

Rizzo/Duong攻击：

Rizzo/Duong的论文从两方面改进了这个攻击：

1.  他们开发了一种更有效的攻击，可以使攻击者一次猜测一个字节，而不是整个块。

2.  他们观察到一个特定的网络技术的使用（cross-origin请求，特别是Web Sockets）允许攻击者以上面所说的方式混合通讯。

 

改变边界  Shifting the Boundary

在Beast攻击中的改进是很容易懂的。想象一下，攻击者有一些控制数据分块的方式。因此，考虑到我们猜测Alice的密码的例子，（为了不失去共性）我们假设密码是8个字符。如果攻击者能够将密码分开在不同的记录里，第一个字节在一个可以预知的内容的记录里，剩下的7个字节在下一个记录里，然后，攻击者仅仅需要猜测第一个字符即可。

例如，如果用户名/密码以 user:alice password:********的方式发送，********是密码本身。因此，如果攻击者能够将上面的内容分开为：alicepassword:* | *******……,那么他们能够单独地猜测密码的第一个字符。而且，如果他们知道第一个字符，他们能够改变记录的一个字节的边界，来猜测下一个字符。通过这种方式，攻击者可以搜索到所有的字符。

 

利用WebSockets

以前的最好的攻击都涉及到VPN，而Rizzo和Duong提出了一种不同的思路。基本的思想是：Web是固有的多站点的环境，而且，站点A通过Javascript访问站点B也是非常普遍的（例如：为了混搭网站mashups）。一个典型的例子，如果你在网页里嵌入一个从站点www.example.com的图片，浏览器将会发送一个请求到www.example.com。重要的是，这个请求可能包含你的www.example.com的cookie。这个特性是各种攻击的基础，包括CSRF和cross-origin请求（例如，那些站点A通过脚本访问站点B），因此，为了限制这些攻击这些能力被严格的限制。

然而，这些限制是不方便的，并且这么多的Web技术都要转向基与origin同意的安全模型。这里的思想是：当一个cross-origin的请求从站点A发到站点B，浏览器会问站点B是否允许站点A访问，这样可以使站点B有选择地允许一些安全的资源被访问。这种技术叫WebSockets，他是设计用于允许一个Client/Server对，它们通过发起HTTP 事务，然后升级到一个透明的通道（非HTTP通道），这个通道可以传输任意的非HTTP格式的消息。WebSockets工作的方式是初期有一个初始化的HTTP握手（包括Cookie），这个握手可以允许客户端查证Server是否准备好WebSockets。握手协议看起来像下面的例子：

Client->Server:

        GET /chat HTTP/1.1

        Host: server.example.com

        Upgrade: websocket

        Connection: Upgrade

        Sec-WebSocket-Key:dGhlIHNhbXBsZSBub25jZQ==

        Origin: http://example.com

        Cookie: 0123456789abcdef

        Sec-WebSocket-Protocol: chat, superchat

        Sec-WebSocket-Version: 13

 

Server->Client:

        HTTP/1.1 101 Switching Protocols

        Upgrade: websocket

        Connection: Upgrade

        Sec-WebSocket-Accept:s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

        Sec-WebSocket-Protocol: chat

在握手之后，客户端的Javascript就被允许发送任意的数据到服务器端，尽管他被一些框架的数据所包着。

很明显在这一点上,可以使用WebSockets作为载体来发动Rizzo/Duong攻击。假设一个攻击者想拿到https://www.google.com的Cookie。他可以在他可以控制的任何origin创建一个网页,例如：http://www.attacher.com/,这个网页有JS脚本发起一个WebSockets链接到https://www.google.com。 因为WebSockets允许cross-origin请求，如果目标服务器允许的话，他可以发起一个HTTPS链接到目标服务器，（例如，他想允许mash-ups）。由于URL（/chat）是攻击者提供的，他能够使它任意长，因此可以将cookie放在关于CBC块边界的任意位置。一旦他抓住了含有cookie的加密的块，它可以通过WebSockets发送任意新的包，这些包经过适当地构造的明文块，正如上文中所说的一样。通过framing做到这一点只有一些小小的障碍，但是Rizzo和Duong声称这些是能够克服的，并且他们的声明起来是可行的。

 

Masking的影响

总之，想法是这样的。幸运的是，我遗漏了一个细节：我在WebSocketsdraft -76刚描述的。 这个版本已经被一些浏览器所安装，而且，大部分都没有启动这个功能（例如：here)），是因为David Huang，Eric Chen，AdamBarth Collin Jackson和我发表的一个弱点（vunerability）。这个版本的WebSockets，IETF正在准备标准化一个叫做masking的feature，这个feature要求浏览器产生一个32位的mask，在传输（在SSL/TLS加密之前）之前用这个mask和包的内容异或。这个改变使得攻击者想用WebSoclets攻击，他们只有2^-32的机会来产生正确的输入发动攻击。很显然，这没有任意的IV（它可以产生2^128  种可能）好，尽管如此，它也是一个很重大的障碍。

 

请注意，我并不是说我的合著者和我知道这个攻击或者我们把它当作一个应对方法。而是，我们关心一个不同种类的攻击，而这种攻击可以控制位，并且Masking的意图是可以阻止攻击者进行控制。然而，由于为了发动攻击类必须要有似级别的控制，这里，Masking似乎是一个有效的对策。

 

基于以上的讨论，应该很清楚的是：我不认为在新版本里的WebSockets这还是个问题（意思是说最新的版本的浏览器，除了Safari）。当然，老版本的浏览器也根本没有实现WebSockets。即使你的浏览器有弱点，你需要和你的目标站点通讯（该站点确实接受cross-originWebSockets请求），据我所知，对于一些高附加值的站点还是很少的，例如：金融站点。

 

利用Java

今天的演示中，Rizzo和Duong用Java来产生vector来攻击。据我所知，他们的展示（注意我没有他们的关于他们如何使用Java的具体细节论文的复制，而只是知道他们使用的版本也就是24/9更新的URLConnection。他们说他们不需要任何提升的Java权限。我有点困惑的是他们是如何通过同源问题的。特别是，他们使用的是哪些API，以及这是不是预料的或者已知的关于SOP的Java行为，或者他们是否已经发现一种接近SOP的方法，这些都是个未知数。重要的是我们知道，它告诉我们他们是否已经发现了过去的HTTPS的一个威胁。特别是，如果有一个明显的违反SOP的行为（例如inthis exploit），那么，无论用什么加密魔法，都有一个严重的问题。

成功攻击的要求

这篇报道确实很长，但是我想说的最后的事情是使用这种类型的技巧发动成功攻击需要有什么条件。据我所知，我们需要一个允许cross-origin请求的域：

1．  在一个可以预测的位置，包含一些用户的秘密（例如：cookie）

2．  允许脚本从攻击者的origin能在同传输用户秘密的同样的HTTPS连接上控制额外的数据。

就是这种混合攻击者的控制的数据和应该对攻击者保密的数据构成了威胁。这在Web背景下是一个很自然的事情；总是mashingup从一个站点数据到其他站点的数据。Web的安全模式被设计用于保护你不受此攻击，但是这里的教训是实际上正确的预防还是有点棘手的。

 

我很想得到更多的关于这个攻击是如何攻击的具体的细节。目前，我的建议是不要启用Java—无论如何这是我的建议。

相关链接：  http://vnhacker.blogspot.com/2011/09/beast.html