Tor安全公告:”relay early”流量确认攻击

2014年8月4日 | 分类: Network | 标签:

Tor security advisory: “relay early” traffic confirmation attack

Tor安全公告:”relay early”流量确认攻击

原文:https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack

译文:http://xautlinux.net/blog/20140804/000930.htm

关键词:in           

This advisory was posted on the tor-announce mailing list.

本公告发布在Tor-Announce邮件列表上。

SUMMARY / 摘要:

On July 4 2014 we found a group of relays that we assume were trying to deanonymize users. They appear to have been targeting people who operate or access Tor hidden services. The attack involved modifying Tor protocol headers to do traffic confirmation attacks.

在2014年7月4日,我们发现了一组中继节点正在试图使用户失去匿名性。他们似乎已经瞄准那些经营或访问Tor隐匿服务的人。这种攻击涉及修改Tor协议头,从而实现流量确认攻击。

The attacking relays joined the network on January 30 2014, and we removed them from the network on July 4. While we don’t know when they started doing the attack, users who operated or accessed hidden services from early February through July 4 should assume they were affected.

这些实施攻击的中继节点是2014年1月30日加入了网络,我们在7月4日把他们清理出网络。虽然我们不知道他们是什么时候开始做攻击的,也不知道从从二月上旬到7月4日期间,有哪些用户操作或访问隐藏的服务,从而受到了影响。

Unfortunately, it’s still unclear what “affected” includes. We know the attack looked for users who fetched hidden service descriptors, but the attackers likely were not able to see any application-level traffic (e.g. what pages were loaded or even whether users visited the hidden service they looked up). The attack probably also tried to learn who published hidden service descriptors, which would allow the attackers to learn the location of that hidden service. In theory the attack could also be used to link users to their destinations on normal Tor circuits too, but we found no evidence that the attackers operated any exit relays, making this attack less likely. And finally, we don’t know how much data the attackers kept, and due to the way the attack was deployed (more details below), their protocol header modifications might have aided other attackers in deanonymizing users too.

不幸的是,目前还不清楚影响”包括什么。我们知道该攻击在寻找有哪些用户请求获取隐藏服务描述符,但攻击者可能未能看到任何应用级流量(如加载或哪些页面,甚至他们所寻找的用户是否访问了隐藏服务)。该攻击可能还试图了解谁发布的隐藏服务描述符,这将使攻击者能够得知隐藏服务的位置。理论上,该攻击也可以用于通过正常的Tor电路,将用户链接到其目的地,但我们没有证据表明攻击者操作任何出口中继节点,所以这种攻击的可能性较小。最后,我们不知道攻击者获得了多少数据,并且由于这样的攻击被公开了(更多详情如下),其协议报头修改的手法可能会在指导其他攻击者去破坏用户的匿名性

Relays should upgrade to a recent Tor release (0.2.4.23 or 0.2.5.6-alpha), to close the particular protocol vulnerability the attackers used — but remember that preventing traffic confirmation in general remains an open research problem. Clients that upgrade (once new Tor Browser releases are ready) will take another step towards limiting the number of entry guards that are in a position to see their traffic, thus reducing the damage from future attacks like this one. Hidden service operators should consider changing the location of their hidden service.

中继节点应该升级到最新的Tor版本(0.2.4.23和0.2.5.6-α),以便关闭攻击所涉及的协议漏洞 – 但请记住,要阻止普遍的流量确认攻击,仍然是一个开放性的研究问题。客户端升级(新的Tor浏览器版本已经准备好了)将采取另外的步骤,以便限制能查看流量的节点监视器的数量,从而降低日后这种攻击的破坏。隐藏服务经营者应该考虑改变自己的隐藏服务的位置。

THE TECHNICAL DETAILS / 技术细节:

We believe they used a combination of two classes of attacks: a traffic confirmation attack and a Sybil attack.

我们相信,攻击者组合使用两种攻击方法:流量确认攻击女巫攻击

A traffic confirmation attack is possible when the attacker controls or observes the relays on both ends of a Tor circuit and then compares traffic timing, volume, or other characteristics to conclude that the two relays are indeed on the same circuit. If the first relay in the circuit (called the “entry guard”) knows the IP address of the user, and the last relay in the circuit knows the resource or destination she is accessing, then together they can deanonymize her. You can read more about traffic confirmation attacks, including pointers to many research papers, at this blog post from 2009:
https://blog.torproject.org/blog/one-cell-enough

流量确认攻击出现的时候,攻击者会控制或观察Tor电路两端的中继节点,然后比较流量的时间、数量或其他特性,从而确认这两个中继节点确实是属于同一电路。如果在电路中的第1个中继节点(称为“入口警卫”)知道用户的IP地址,并且电路中的最后一个中继节点知道要访问的资源或目标地址,那么两者结合起来就能使用户失去匿名性。你可以从2009年这个博客帖子中,获得更多关于流量确认攻击的信息,包括许多研究论文的链接:https://blog.torproject.org/blog/one-cell-enough

The particular confirmation attack they used was an active attack where the relay on one end injects a signal into the Tor protocol headers, and then the relay on the other end reads the signal. These attacking relays were stable enough to get the HSDir (“suitable for hidden service directory”) and Guard (“suitable for being an entry guard”) consensus flags. Then they injected the signal whenever they were used as a hidden service directory, and looked for an injected signal whenever they were used as an entry guard.

他们所使用的确认攻击是一种主动攻击,在其中一端的中继节点上,向Tor的协议头注入一个信号,然后在另一端的中继节点读取该信号。这些被攻击的中继节点是很稳定的,足够让HSDir(用于提供隐藏服务的目录”)和警卫(用于作为入口警卫),共同取得协商一致的标志。然后,无论何时该中继节点被用作隐藏服务目录时,就插入该信号;无论何时该中继节点被用来作为入口警卫时,就寻找被注入的那个信号。

The way they injected the signal was by sending sequences of “relay” vs “relay early” commands down the circuit, to encode the message they want to send. For background, Tor has two types of cells: link cells, which are intended for the adjacent relay in the circuit, and relay cells, which are passed to the other end of the circuit. In 2008 we added a new kind of relay cell, called a “relay early” cell, which is used to prevent people from building very long paths in the Tor network. (Very long paths can be used to induce congestion and aid in breaking anonymity). But the fix for infinite-length paths introduced a problem with accessing hidden services, and one of the side effects of our fix for bug 1038 was that while we limit the number of outbound (away from the client) “relay early” cells on a circuit, we don’t limit the number of inbound (towards the client) relay early cells.

他们注入信号的方式是:通过发送“relay”和“relay early命令,使电路发生延迟,以便编码加入他们要发送的消息。相关的背景知识是:Tor的有两种类型的信元:链路信元,用于电路中的邻近中继节点。第二个是中继信元,被传递到电路的另一端。在2008年,我们增加了一个新的中继信元,称为“relay early”信元,用来防止用户在Tor网络中创建太长的路径。(太长的路径可以被用来诱发拥堵,从而破坏匿名性)。但对于无限长路径的修复,却对访问隐藏服务造成了新的问题,我们对bug 1038的修复,所产生的副作用之一是:虽然我们限制了在Tor电路中,出站的(离开客户端)“relay early信元,但是我们没有限制入站的(进入向端)“relay early信元

So in summary, when Tor clients contacted an attacking relay in its role as a Hidden Service Directory to publish or retrieve a hidden service descriptor (steps 2 and 3 on the hidden service protocol diagrams), that relay would send the hidden service name (encoded as a pattern of relay and relay-early cells) back down the circuit. Other attacking relays, when they get chosen for the first hop of a circuit, would look for inbound relay-early cells (since nobody else sends them) and would thus learn which clients requested information about a hidden service.

总而言之,当Tor客户连接到一个被攻击的中继节点时,该中继节点的功能是承担隐藏目录服务的角色,用来发布或索取一个隐藏服务描述符(步骤2和3参见隐藏服务协议图),该中继节点将发送隐藏服务名称(被编码成relay和relay-early信元的一个模板)返回给电路。对于其他被攻击的中继节点来说,当它们被选为电路的第一跳时,就会寻找出站的relay-early信元(然而此时还没人发送该信元),这将使得客户所请求的隐藏服务信息被发现了。

There are three important points about this attack:

这种攻击有三个显著的特点:

A)   The attacker encoded the name of the hidden service in the injected signal (as opposed to, say, sending a random number and keeping a local list mapping random number to hidden service name). The encoded signal is encrypted as it is sent over the TLS channel between relays. However, this signal would be easy to read and interpret by anybody who runs a relay and receives the encoded traffic. And we might also worry about a global adversary (e.g. a large intelligence agency) that records Internet traffic at the entry guards and then tries to break Tor’s link encryption. The way this attack was performed weakens Tor’s anonymity against these other potential attackers too — either while it was happening or after the fact if they have traffic logs. So if the attack was a research project (i.e. not intentionally malicious), it was deployed in an irresponsible way because it puts users at risk indefinitely into the future.

攻击者将隐藏服务的名称编码后,包含在注入信号中(并没有采用,发送一个随机数,并保留一个本地列表,把随机数映射到隐藏服务名称)。被编码后的信号是加密的,通过TLS通道在中继节点之间传送。不过,这个信号很容易被任何运维中继节点并收到这种被编码的流量的人,所读取并解析。我们也可能会担心一个全球性的对手(如一个大的情报机构),记录互联网流量的入口警卫,然后试图打破Tor的链路加密。这次攻击的手法削弱了Tor的匿名性,超过了其他潜在的攻击者 – 无论是当它发生,或者如果他们有流量记录之后所发生。因此,如果这次攻击是一个研究项目(即不是有意的恶作剧),它的部署是一种不负责任的做法,因为它使用户在不可预知的一段时间内处于危险之中。

(This concern is in addition to the general issue that it’s probably unwise from a legal perspective for researchers to attack real users by modifying their traffic on one end and wiretapping it on the other. Tools like Shadow are great for testing Tor research ideas out in the lab.)

(这个重大事件衍生出一般性的问题,从法律的角度来看,可能是不明智的研究人员攻击了真正的用户,修改用户某一端的流量,然后再窃听另一端的流量。像Shadow这样的工具非常适用于在实验室内,测试Tor的研究思路。)

B)   This protocol header signal injection attack is actually pretty neat from a research perspective, in that it’s a bit different from previous tagging attacks which targeted the application-level payload. Previous tagging attacks modified the payload at the entry guard, and then looked for a modified payload at the exit relay (which can see the decrypted payload). Those attacks don’t work in the other direction (from the exit relay back towards the client), because the payload is still encrypted at the entry guard. But because this new approach modifies (“tags”) the cell headers rather than the payload, every relay in the path can see the tag.

这种协议头信号注入攻击,从研究的角度来看实际上是非常灵巧的,因为它与之前那些针对应用层负载所进行的标记攻击有点不同。以前的标记攻击,是在入口警卫处修改了有效载荷,然后在出口中继节点寻找修改后的有效载荷(可以看到解密后的有效载荷)。这些攻击不能工作在其他方向(从出口中继节点返回客户机),因为在入口警卫处,有效载荷仍然是被加密的。但是,因为这种新的攻击方法对信元头部进行了修改(打上标签),而不是在有效载荷上,在该路径中的每个中继节点都可以看到标签。

C)   We should remind readers that while this particular variant of the traffic confirmation attack allows high-confidence and efficient correlation, the general class of passive (statistical) traffic confirmation attacks remains unsolved and would likely have worked just fine here. So the good news is traffic confirmation attacks aren’t new or surprising, but the bad news is that they still work. See https://blog.torproject.org/blog/one-cell-enough for more discussion.

我们要提醒读者,虽然这次特定的变异的流量确认攻击具有高可信度和高相关性,一般被动(统计)流量攻击攻击仍然没有解决方法,很可能仍然能有效的工作因此,好消息是流量确认攻击不是新的或者令人惊讶的,但坏消息是,他们仍然可以工作。请参见更多的讨论https://blog.torproject.org/blog/one-cell-enough

Then the second class of attack they used, in conjunction with their traffic confirmation attack, was a standard Sybil attack — they signed up around 115 fast non-exit relays, all running on 50.7.0.0/16 or 204.45.0.0/16. Together these relays summed to about 6.4% of the Guard capacity in the network. Then, in part because of our current guard rotation parameters, these relays became entry guards for a significant chunk of users over their five months of operation.

他们所使用的第二类攻击,配合流量确认攻击共同使用的,是一个标准的“女巫攻击”——他们登记注册了大约115台快速的非出口中继节点,全部运行在IP地址50.7.0.0/16 或者 204.45.0.0/16 网段。在网络中,这些中继节点加起来占有大约6.4%的警卫节点的容量。然后,某种程度上因为我们目前的警卫节点轮换参数的缘故,这些中继节点变成了入口警卫,在它们五个月的运行中,为大批的用户服务

We actually noticed these relays when they joined the network, since the DocTor scanner reported them. We considered the set of new relays at the time, and made a decision that it wasn’t that large a fraction of the network. It’s clear there’s room for improvement in terms of how to let the Tor network grow while also ensuring we maintain social connections with the operators of all large groups of relays. (In general having a widely diverse set of relay locations and relay operators, yet not allowing any bad relays in, seems like a hard problem; on the other hand our detection scripts did notice them in this case, so there’s hope for a better solution here.)

事实上,在这些中继节点加入网络的时候,我们已经注意到了,因为DocTor扫描器生成了报告。我们那时候考虑了这一套新的中继节点,认为那只不过是网络中的一小部分。很明显我们有改进余地,关于如何让Tor网络增大,同时确保我们与大规模中继节点的所有经营者,都能保持社会联系。 一般来说,中继节点的位置和经营者,有广泛的多样性,同时不允许任何不良中继节点加入,似乎是一个很难的问题;而另一方面,我们的检测脚本在那时候确实发现了他们,所以有希望找到更好的解决方案。

In response, we’ve taken the following short-term steps:

作为应对措施,我们采取了下列短期步骤:

1) Removed the attacking relays from the network.

将被攻击的中继节点清理出网络。

2) Put out a software update for relays to prevent “relay early” cells from being used this way.

对中继节点部署软件更新,阻止 “relay early”信元,被用于这种攻击。

3) Put out a software update that will (once enough clients have upgraded) let us tell clients to move to using one entry guard rather than three, to reduce exposure to relays over time.

部署软件更新(一旦足够多的客户端被更新了),能让我们告诉客户端,只使用一个入口警卫,而不是三个,以便减少日后曝光给中继节点。

4) Clients can tell whether they’ve received a relay or relay-cell. For expert users, the new Tor version warns you in your logs if a relay on your path injects any relay-early cells: look for the phrase “Received an inbound RELAY_EARLY cell”.

客户端能够报告它们接收到的是一个中继节点,还是一个中继信元。对于专家级用户来说,新的Tor版本将会在日志中发出警告,只要在你的路径上有一个中继节点插入了任何relay-early信元:查找关键词“接收到一个入站的RELAY_EARLY信元”。

The following longer-term research areas remain:

接下来的长期研究领域包括:

5) Further growing the Tor network and diversity of relay operators, which will reduce the impact from an adversary of a given size.

进一步扩大Tor网络和relay提供者的多样性,这将把敌对者造成的影响降到一定的范围。

6) Exploring better mechanisms, e.g. social connections, to limit the impact from a malicious set of relays. We’ve also formed a group to pay more attention to suspicious relays in the network:

探索更好的机制,例如社会连接,以便限制从一个恶意设置的中继节点所带来的影响。我们已经成立小组关注网络中的可疑中继节点:
https://blog.torproject.org/blog/how-report-bad-relays

7) Further reducing exposure to guards over time, perhaps by extending the guard rotation lifetime:

未来将减少警卫节点随时间推移而暴露,也许通过扩大警卫节点的循环生命周期:
https://blog.torproject.org/blog/lifecycle-of-a-new-relay
https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard…

8) Better understanding statistical traffic correlation attacks and whether padding or other approaches can mitigate them.

更好的理解流量相关攻击的统计特征,还有是否流量填充或其他方法能够减缓这种攻击。

9) Improving the hidden service design, including making it harder for relays serving as hidden service directory points to learn what hidden service address they’re handling:

优化隐藏服务的设计,包括对于那些作为隐藏服务目录接入点的中继节点,使得要想获取它们所掌握的隐藏服务的地址,会变得更难。
https://blog.torproject.org/blog/hidden-services-need-some-love

OPEN QUESTIONS / 公开提问:

Q1) Was this the Black Hat 2014 talk that got canceled recently?

在Black Hat 2014会议上提到的话题被放弃了吗?

Q2) Did we find all the malicious relays?

我们是否找出了所有恶意的中继节点?

Q3) Did the malicious relays inject the signal at any points besides the HSDir position?

除了隐藏服务目录以外,这些恶意节点是否在其他节点也插入信号?

Q4) What data did the attackers keep, and are they going to destroy it? How have they protected the data (if any) while storing it?

攻击者都保留了哪些数据,他们打算销毁它吗?他们在保存这些数据时,如何保护数据的安全?

Great questions. We spent several months trying to extract information from the researchers who were going to give the Black Hat talk, and eventually we did get some hints from them about how “relay early” cells could be used for traffic confirmation attacks, which is how we started looking for the attacks in the wild. They haven’t answered our emails lately, so we don’t know for sure, but it seems likely that the answer to Q1 is “yes”. In fact, we hope they *were* the ones doing the attacks, since otherwise it means somebody else was. We don’t yet know the answers to Q2, Q3, or Q4.

问得好。我们花了几个月的时间,试图从那些Black Hat话题的研究者那里获取更多信息,幸运的是我们已经从他们那里得到了一些提示,关于如何使用“relay early”信元来进行流量确认攻击,使得我们开始大范围寻找这种攻击。他们还未回复我们最新的邮件,所以我们不确定能对问题一回答“yes”。实际上,我们希望他们是实施攻击的一员,否则就意味着是其他人所为。我们还不知道如何回答问题二、三、四。

 

翻译完)

 

目前还没有任何评论.