[译]BEAST还是一个威胁吗？

原文链接：https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat

原文发表时间：2013.9.10

本博文仅仅是上述原文的翻译，仅供研究参考，本人不对准确性作任何保证，侵立删，如有转载，需自行承担所有责任。如有翻译不准确的地方，欢迎指教。

昨天，我改变了 SSL Labs 的打分规则（译者注：SSL Labs是一个在线检测SSL站点安全性的网站），停止检测站点是否启用了服务端的BEAST缓解措施。这表示我们现在认为这种可以从客户端进行缓解，但是有一些事情你还是要了解的。

什么是BEAST？

TLS 1.0和更早版本的协议中有一个严重的漏洞：分组密码中在加密前用于混淆明文的初始化向量（IV）可以通过中间人攻击（MITM）预测到。IV是用来避免加密陷入定式，没有它们，你每次使用相同的密钥加密相同的分组时，你将得到相同的加密结果。这可不太好。一个聪明的攻击者可以通过如下三个步骤来猜测加密的原文是什么：1）猜测IV；2）看看加密结果是什么；3）改变加密原文（译者注：也就是“选择明文攻击”）。从技术的角度来看，攻击者并未解密任何数据，但是可以验证自己的猜测是否正确，但是如果没有足够多次的猜测，并不能发现任何明文信息。

这只是该问题的一个超级浓缩版本，如果你对详细情况感兴趣，建议您参看我之前写的一篇文章，并且参考那篇文章中推荐的链接。

因为猜测并不是非常有效的，因此在实践中BEAST攻击只能获取一小段数据。这听起来好像没什么卵用，但是我们使用的很多高价值的信息都是不大的数据段，例如：HTTP session cookie，认证凭证集（许多协议中都在用，而不仅仅是HTTP），基于URL的session token等等。因此，BEAST是一个很严重的问题。

缓解措施现状

BEAST是纯粹的客户端脆弱性。因为这种攻击已经被公开，许多主流的浏览器厂商都通过一种称为1/n-1 split的技术解决了这个问题。这种技术通过阻止攻击者猜测IV从而有效的从根本上解决了这个问题。

但是有一个平台拖了后腿 -- 苹果家的。我们对他们是怎么想的一无所知，因为他们没有就此问题进行过官方的说明。我的理解是Mountain Lion的发布版中会包含1/n-1 split，但是默认是禁用的。另外，据我所知，IOS中并未使用该防范技术。

因为苹果没有解决BEAST攻击，因此用户仍然潜在的面临着威胁。考虑到这个原因，今年年初，SSL Labs开始检测站点是否使用了服务端的缓解措施以对抗这种攻击。

不幸的是，TLS1.0和更早期协议（当前使用协议的大多数）对抗BEAST唯一有效的方法是使用RC4算法。之所以说“不幸”，是因为我们刚开始服务端缓解措施检测后不久，一项关于RC4的研究发现这种算法比我们之前认为的更弱。这种脆弱性虽然不会立即带来危害，但很显然RC4算法正在走向不归路。

情况变得有些不妙，因为我们无法同时解决两个问题。但是因为两个问题大致可认为同样是低风险，最终的策略也是很明显的：RC4影响所有人，并且无法缓解；BEAST仅仅影响一部分人，并且不再有可利用的方法（希望吧）。另外，我们知道针对RC4的攻击正变得更为有效，针对BESAT的攻击似乎变得更少了。

BEAST还是一个威胁吗？

从目前的情况看，剩下的唯一工作就是证明利用BEAST的路径都被切断了。但是我们并没有有关这点的可信信息，因此我打算测试一些运行在脆弱性平台的浏览器，如果可能的话阅读它的源代码，并且尝试利用BEAST。

这项研究需要大量的精力和时间，主要是因为我不想只是运行现有的利用工具，我想完全理解这种攻击，并且发掘其他可能的攻击方法。Juliano和Thai（BEAST作者）对我的问题给了很多有用的回答。我曾走了一些弯路，一部分是因为现实的问题，一部分是因为我的错误。我认为BEAST在很长一段时间里仍旧是可利用的，因为我发现在BEAST里使用的同源策略绕过仍旧存在，这点令我很是惊讶。很显然，针对那个问题（译者注：应是指针对同源策略绕过的修复）的修复搞砸了。使用该漏洞，MITM仍能使用Java applet控制受害者的浏览器加密任意明文并发送到任意主机。

幸运的是，自从BEAST被公开之后，applet的运行机制已经发生了很多改变。例如：现在在运行applet前总会有一个警告。在我的测试中，Java插件无法获取HttpOnly的cookie，也无法在任何请求中发送或接收它。更为重要的是，由applet发出的HTTPS请求使用了Java的TLS协议栈，而不是宿主浏览器的。因为Java实现了1/n-1 split，因此BEAST无法发威。

结语

虽然SSL Labs对未实现服务端BEAST缓解措施的站点进行惩罚（打低分），但这个问题还会长期存在，因为还有大量的浏览器尚未进行修复。虽然我不认为现在这个问题已经被利用了，但是或许有我们不知道的一些攻击方式。Safari新添加的一项特性会使得该项漏洞再次可被利用，或者有时间进行测试的人可能会证明我是错的。由于这个原因，我们需要一个良好的安全保证，我们需要Safari默认的实现1/n-1 split。

另外，支持TLS1.1和1.2在现在及不远的未来并不能真正的解决BEAST，即使这些协议并不包含这种攻击所利用的IV预测漏洞。第一个问题当前网络还主要是依赖TLS1.0，在SSL Pulse检测的服务器中只有大约18%支持TLS1.2。因此，即使下一代的web浏览器都支持TLS1.2，服务完成升级仍旧需要一段时间。

还有第二个问题，所有主流浏览器都容易遭受协议降级攻击，主动的MITM可以模拟失败场景，迫使浏览器从TLS1.2回退至SSL3.0，从而利用IV预测漏洞。除非协议降级漏洞被修复，更新的协议仅仅对被动攻击者有效，对主动的攻击者则无效。