犯罪-如何击败BEAST后继者？

#1 楼

本次攻击应该在10天后进行，但是我猜测他们使用压缩。

SSL / TLS可选地支持数据压缩。在ClientHello消息中，客户端声明其知道的压缩算法列表，然后服务器在ServerHello中响应将使用的压缩算法。压缩算法由一字节的标识符指定，并且TLS 1.2（RFC 5246）仅定义null压缩方法（即完全没有压缩）。其他文档指定了压缩方法，特别是基于DEFLATE定义压缩方法1的RFC 3749，LZ77衍生物是GZip格式的核心，也是现代Zip档案的基础。使用压缩时，它将作为长流应用于所有传输的数据。特别是，当与HTTPS一起使用时，压缩将应用于流中所有后续的HTTP请求（包括标头）。 DEFLATE通过查找重复的字节子序列来起作用。浏览器将发送这些请求以及该银行的用户cookie，即攻击者所追求的cookie值。另外，让我们假设攻击者可以观察到用户机器与银行之间的流量（可能是，攻击者与受害者相比可以访问同一Wi-Fi热点的LAN；或者他在路径上的某个地方劫持了路由器，可能是

对于此示例，我们假设每个HTTP请求中的cookie如下所示：


Cookie：secret = 7xc89f + 94 / wa


攻击者知道Cookie: secret=的一部分，并希望获取秘密值。因此，他指示他的JavaScript代码发出一个请求，该请求在主体中包含序列Cookie: secret=0。 HTTP请求将如下所示：

POST / HTTP/1.1
Host: thebankserver.com
(...)
Cookie: secret=7xc89f+94/wa
(...)

Cookie: secret=0

当DEFLATE看到时，它将识别重复的Cookie: secret=序列，并用一个非常短的令牌表示第二个实例（其中一个表明“先前序列的长度为15，并且位于过去的n个字节中）； DEFLATE将必须发出一个额外的令牌为“ 0”。

请求发送到服务器。从外部，攻击者的窃听部分看到一个不透明的Blob（SSL加密数据），但他可以看到Blob的长度（连接使用RC4时的字节粒度；使用块密码时会有一些填充，但是攻击者可以调整其请求的内容，以便可以与块边界定相，因此，在实践中，攻击者可以知道密钥的长度。

现在，攻击者再次尝试，在请求正文中使用Cookie: secret=1。然后是Cookie: secret=2，依此类推。所有这些请求都将压缩到相同的大小（几乎-有一些细微之处使用DEFLATE中使用的霍夫曼代码），但包含q431207的代码除外9q，压缩效果更好（16个重复子序列而不是15个字节），因此压缩时间更短。攻击者看到了。因此，在几十个请求中，攻击者已经猜出了秘密值的第一个字节。

他只需要重复此过程（Cookie: secret=7，Cookie: secret=70等），然后逐字节获取字节，是完整的秘密。



我上面描述的是我读这篇文章时的想法，该文章谈到了“可选功能”中的“信息泄漏”。我不能确定将作为CRIME攻击发布的内容确实基于压缩。但是，我看不到如何对压缩进行攻击。因此，无论CRIME是滥用压缩还是完全不同，都应从客户端（或服务器）关闭压缩支持。

请注意，我在谈论SSL级别的压缩。 HTTP还包括可选的压缩，但是此压缩仅适用于请求和响应的正文，不适用于标头，因此不覆盖Cookie: secret=71标头行。 HTTP级压缩很好。

（必须删除SSL压缩是很可惜的，因为它对降低带宽要求非常有用，尤其是当站点包含许多小图片或Ajax繁重的站点包含许多小请求，所有请求都以极其类似的HTTP标头版本开头。如果固定JavaScript的安全模型以防止恶意代码向银行服务器发送任意请求会更好；我不确定这很容易，不过。）


编辑2012/09/12：可以通过二分法对上述攻击进行一些优化。假设秘密值在Base64中，即每个未知字符有64个可能的值。攻击者可以发出包含32个Cookie:副本的请求（用于Cookie: secret=X字符的32个变体）。如果其中之一与实际cookie匹配，则总压缩长度将比其他情况短。一旦攻击者知道未知字节属于字母表的哪一半，他就可以尝试以16/16的比例再次尝试，依此类推。在6个请求中，该位置为未知字节值（因为26 = 64）。如果秘密值为十六进制，则6个请求变为4个请求（24 = 16）。二分法解释了朱利安诺·里佐（Juliano Rizzo）的最新观点。


编辑2012/09/13：确认。 CRIME攻击滥用压缩，其方式与上文所述类似。攻击者在其中插入假定的cookie副本的实际“主体”实际上可以是简单请求中的路径，该路径可以由最基本的X标签触发；无需对原产地政策进行花哨的攻击。<​​br />

#2 楼

为了补充托马斯·珀金（Thomas Pornin）的出色答案，我想指出一些有关压缩和密码学的先前工作。请看以下研究论文：


John Kelsey。明文的压缩和信息泄漏。 FSE2002。

该论文描述了针对系统的选择明文攻击，该系统（a）在加密数据之前先对其进行压缩，并且（b）窃听可以观察所得密文的长度。
从概念上讲，这些攻击与Thomas Pornin所描述的相似。该文件甚至提到TLS在加密之前使用可选压缩。但是，当时我认为没有人意识到这可以通过TLS对HTTP发起攻击，或者攻击者可以了解通过TLS加密的连接发送的秘密Cookie的价值。该论文主要从抽象的角度而不是在Web的特定上下文中着眼于压缩攻击，这是理论上的。因此，CRIME（或Thomas Pornin的攻击）仍然是这些想法的重要新颖扩展。认识到网络安全的后果。有趣的是，一般性问题是10年前在研究文献中首次描述的，但是安全界花了很长时间才完全意识到这项工作的实际后果。加密肯定不容易吗？

#3 楼

只是为了增加Thomas的回答，似乎要成功泄漏cookie值，发送的实际POST正文不仅应为：

Cookie: secret=....

，还应包含更多POST标头中的文本，例如：

POST / HTTP/1.1
Host: thebankserver.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/22.0.1207.1 Safari/537.1
Accept: */*
Referer: https://thebankserver.com/
Cookie: secret=...

可以使用Java脚本轻松构造此POST内容（例如，他将通过navigator对象检索用户代理），因此在攻击场景中不是问题。

实际上，攻击者可以使身体变异更多，例如通过多次放置Cookie值，放置多个Cookie标头，仅使用正文中的POST标头的一部分等。

基于@xorninja代码，我构建了自适应算法，该算法重复了整个请求标题中的标题，如果下一个Cookie字符的结果不清楚，则尝试迭代地缩短该标题。结果是有希望的，现在至少检测到8个字符。如果无法通过这种方式检测到字符，则通过删除一个标头来缩短请求正文，然后过程继续进行。它可以成功泄漏任意cookie值。随时改进。