HTTP压缩仍让加密连接处于风险之中
作者: 日期:2016年04月06日 阅:4,929

安全研究人员近期改进了一项已有三年历史的攻击方法:

640.webp

这种攻击类型被称为 BREACH ,是“利用超文本自适应压缩算法,进行浏览器侦查和信息窃取”(Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext)的简称。许多 Web 服务器使用 gzip 和 DEFLATE 算法来减少 HTTP 的响应延迟,然而,这两种加密算法会泄露关于加密连接的信息,使得中间人攻击成为可能。一旦中间人介入,就可以恢复认证 cookie 等敏感信息。

3年前美国举行的 Black Hat 大会上,安杰洛 普拉多(Angelo Prado)、尼尔 哈里斯(Neal Harris)、约尔 古拉克(Yoel Gluck) 这三位研究人员首次展示了这种攻击方式。从理论上讲, BREACH 攻击有可能影响所有 SSL 和 TLS 加密方案,但研究人员当时提出的方法对于利用 RC4 等数据流加密处理的连接最为有效。

来自雅典国家技术大学(National Technical University of Athens)的迪米特里  卡拉考斯塔和雅典大学(University of Athens)的狄奥西斯 乾罗斯(Dionysis Zindros)是另外一组研究人员。他们改进了 BREACH 攻击,让其更适用于攻击如今更加常用的 AES 等 TLS 分组密码。

卡拉考斯塔和乾罗斯在亚洲上周举行的 Black Hat 大会上展示了对 BREACH 技术的改进,并发布了一份名为 Rupture 的开源框架,可用于发动这类与加密相关的攻击。

640.webp (1)

Rupture 压缩边信道攻击框架

他们展示了两种针对 Gmail 和 Facebook Chat 的概念验证攻击,以证明很多网站都存在这一漏洞,即使是那些最注重安全的也不例外。

BREACH 要求攻击者处于能够拦截受害者 Web 流量的网络位置上。做到这一点的方式有不少:连接到同一无线网络、入侵路由器,或者从网络架构的更高位置来发动攻击,比如通信运营商和美国国安局。

不过,攻击者还需要找到存在漏洞的应用,它们能够接受 URL 参数,并将输入反射到加密响应消息中去。

比如研究人员演示的 Gmail 入侵: Gmail 的移动网页版支持输入反射,响应页面上包含通过 URL 参数传递的搜索字符串,比如有些信息会显示没有搜索到特定字符串。此外,如果请求来自经过认证的合法会话,响应中还会带有标明本次会话的认证令牌。

gzip 压缩在 HTTP 中的工作方式是这样:如果在响应中有同一个字符串的多个实例,第一个实例将被保留,而其余实例将被替换成指向第一个实例位置的短引用,以减少响应消息的体积。

因此,对于 Gmail 而言,如果用户搜索的刚好是认证令牌完全一致的字符串,哪怕是它的一部分,在响应消息中也将相同字符序列的两个实例。由于压缩的存在,响应将比使用其它字符串进行搜索时的体积更小。

就像在 Gmail 攻击过程中显示的那样,攻击者使用 BREACH 技术的目标如下:诱使用户的浏览器向存在漏洞的应用发送大量请求信息,猜测认证令牌的内容。响应中的认证令牌可能受到加密保护,但每当搜索字符串与认证令牌的一部分契合时,攻击者观察到的响应消息都会比正常情况要小一点。

通过将新确认的字符添加到已有结果中,持续改变新请求中的搜索字符串,最终将获得认证令牌中的每个字符。这种方法将每次 HTTP 压缩的结果作为确认标识,实际上是针对各个字符的暴力破解攻击。

Rupture 框架可以帮助攻击者在用户浏览器打开的每个 HTTP 连接中注入恶意代码。这段代码可以强制浏览器向后台存在漏洞的 HTTPS 应用发出请求。分组密码和数据流加密有所不同,它会在每个响应中加入噪声:在加密过程之前添加被称为“填充”(Padding)的冗余比特,让响应可以被分割成相等大小的区块。要想利用 BREACH 技术过滤掉噪声,恢复加密数据,需要比应对数据流加密方式时多得多的请求次数才能做到。

乍看起来,这让 BREACH 攻击更难实现了。然而,卡拉考斯塔和乾罗斯设计了一种基于统计学的方法,通过计算请求同一个字符时多组响应的平均长度,过滤掉噪声。两位研究人员还进行了其它改进,并引入了搜索引擎平行化技术,大大提升了攻击使用分组密码的 TLS 的效率。

研究人员在发布的技术论文中写道, BREACH 攻击技术发布三年之后, RC4 已被公认为不安全的,如今大多数站点使用 AES 分组密码。“脸书等一些服务也整合了防止 BREACH 攻击的机制。然而, BREACH 的基本攻击机制仍旧有效,而包括脸书在内的大多数流行站点依旧支持存在漏洞的端点。”

研究人员总结称:“我们的研究证明,通过改进 BREACH ,能够攻击主流 Web 应用。这也同时说明, TLS 流量在实务层面上仍可以被视为不安全的。”

最近提出的一项互联网标准被称为第一方/同站点 cookie ,它可以保护站点免遭 BREACH 攻击。如果浏览器也采取该机制,可以防止来自其它站点的请求响应信息中包含 cookie 。

也就是说,如果 A 站点的代码指示浏览器向 B 站点发起请求, 即使浏览器已经和 B 站点之间有了活动的、经认证的会话,该请求也不会包含用户面向 B 站点的认证 cookie 。设计这一机制的初衷是防止跨站请求伪造(Cross-site Request Forgery,CSRF)攻击,但由于 BREACH 也采取了与 CSRF 类似的方式来发起恶意跨站请求,该机制对后者也将有效。

谷歌 Chrome 在版本号51中将启用对同站点 cookie 的支持,该版本将在今年五月发布稳定版。然而,如果还有许多浏览器并未采取该机制,网站管理者将很难产生对 cookie 添加“同站点”标识的动力。

 

申明:本文系厂商投稿收录,所涉观点不代表安全牛立场!


相关文章