zoukankan      html  css  js  c++  java
  • [译]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预测漏洞。除非协议降级漏洞被修复,更新的协议仅仅对被动攻击者有效,对主动的攻击者则无效。

    本博客内容,除了标记为“转载”的之外,均为本人原创或翻译,欢迎转载,但不得用于各种商业培训和各种赚积分类站点,转载请标明出处。如您有任何疑问或者授权方面的协商,请给我留言。
  • 相关阅读:
    使用 asp.net mvc和 jQuery UI 控件包
    ServiceStack.Redis 使用教程
    HTC T8878刷机手册
    Entity Framework CodeFirst 文章汇集
    2011年Mono发展历程
    日志管理实用程序LogExpert
    使用 NuGet 管理项目库
    WCF 4.0路由服务Routing Service
    精进不休 .NET 4.0 (1) asp.net 4.0 新特性之web.config的改进, ViewStateMode, ClientIDMode, EnablePersistedSelection, 控件的其它一些改进
    精进不休 .NET 4.0 (7) ADO.NET Entity Framework 4.0 新特性
  • 原文地址:https://www.cnblogs.com/likefrank/p/is-beast-still-a-threat.html
Copyright © 2011-2022 走看看