Nathan Evans did the last talk on the first night of Defcon called De-TOR-iorate Anonymity. It had a lot of people sweating on the Tor mailing list and even generated a huge debate about whether Tor should even be attempted to be used on a multi-purpose system versus a dedicated machine or virtual machine like JanusVM or AnonymOS. The information was pretty thick to process at the time, but a few minutes later, it finally sunk in. Here's how it works.

Overview of Tor

A quick review of how Tor works. Tor is a anonymity tool that creates a circuit of proxy servers to relay connections through. For instance, in the figure below we see Alice trying to connect to Bob. Alice sends traffic to node 1, node 1 relays that traffic to node 5, node 5 relays that traffic to node 8 and node 8 finally sends the request to Bob. If Bob replies, the data travels back the direction that it came. Simple enough?

Overview of Attack

Nathan's attack would fall under the "partitioning" label as the goal of the attack is to partition the Tor network smaller and smaller until it can find the entry node the user is coming from. Because this attack assumes you have control of the exit node, obtaining the entry node confirms the second node used as a relay thus showing every node in a user's circuit. This makes Tor as anonymous as a single proxy.

Circular Circuits

Nathan found that an attacker can create looped circuits. That is Node 1 relays to Node 2 and then relays to Node 3 but at Node 3 an EXTEND command is issued so the circuit length is increased infinitely. This causes the queue of traffic waiting to be relayed to fill up and the latency to increase by a large amount.

Why it works

Doing a DoS attack and measuring the latency is not new. It was actually talked about at last year's Defcon. The difference with this attack is the attacker actually creates circular circuits so nodes are actually looping traffic back to the beginning instead of relaying properly.

This is why the attack worked:

• Tor is hard coded to only uses 3 nodes in a circuit(debatable whether or not to change)
• Tor does not provide padding to keep latency at the same rate (and never will)
• Tor allows for infinite circuit lengths (to be fixed in proposal 110)

The Attack

To attack the network, he used the following environment

1. a "Bad Exit Node" owned by the attacker
2. Tor client used to generate circular circuits (Defined as "DoS Client")
3. Web server to act as the destination and to keep track of latency (Defined as "DoS Server")
4. Normal user that is using the Bad Exit Node ("Alice")

The attack is done by a denial-of-service attack on many nodes using circular circuits discussed above. If the user's latency stays low during a circular circuit creation, then the attacker knows that the entry node is NOT one of the DoS'd relays and tries different nodes. In this case, latency is measured by injecting a javascript command to ping a web server collecting stats. The process of generating circular circuits and recording the results is repeated until the user's latency increases substantially at which time the attacker knows that the entry node is one of the three nodes used in the last DoS attack.

Example

In this figure, you can see that Alice is trying to connect to Bob via nodes 1, 5, and the Bad Exit Node that is owned by the attacker. During this time the attacker is creating circular circuits between 1, 2, and 3 which generate large amounts of traffic causing a slow down.

The Fix

Tor has been been updated at least 3 times since writing this blog. Among many other bug fixes and feature additions are the changes related to Proposal 110. This is the proposal to change Tor to handle circular circuits. The proposal splits up relay requests into "Relay" and "Relay_Early." Relay requests do not have the ability to issue the EXTEND command that is used to generate the circular circuits and Relay_Early can as these would be the beginning of the circuits.

The 0.2.0.30 version also makes an addition to block "risky" extend cells.

Relays now reject risky extend cells: if the extend cell includes a digest of all zeroes, or asks to extend back to the relay that sent the extend cell, tear down the circuit. Ideas suggested by rovv.

The fix is not complete. They are still implementing parts of proposal 110. They have to maintain backwards compatibility in case a version 1 circuit is created.

External Links

http://www.torproject.org - Tor Project Website
https://www.torproject.org/svn/trunk/doc/spec/proposals/110-avoid-infinite-circuits.txt - Details of the proposal for the fix
http://archives.seul.org/or/talk/Aug-2008/msg00148.html - just for accuracy's sake, Roger Dingledine's follow up to my explanation on the or-talk list
http://web.cs.du.edu/~natevans/ - Nathan Evan's website. Nothing there really
https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-evans-grothoff.pdf - Original powerpoint presentation called De-Tor-iorate Anonymity
https://www.torproject.org/svn/trunk/ChangeLog - the always updating changelog of Tor

I was kind of excited about this years Tor talks because it was almost skipping over the details of what is Tor and going strait to some more advanced subjects. Roger Dingledine made a great presentation about the vulnerabilities of Tor where he went through each major security bug that was ever discovered. He is very honest about some of the future attacks like Latency Tables, SSL Website Fingerprinting, automatic control port authentication problems, attackers buying old certificate authorities so that SSL MITM attacks would be available anytime, and even how governments are starting to make laws forcing Tor admins to have an real time access to current Tor nodes.

Latency Tables

This was actually pretty interesting to me. Roger made a comment about how an attack would be easier if the attacker had access to a latency table which would keep track of the latency between one point to another on a global scale. This is a theoretical attack as no one has been able to do this effectively.

SSL Website Fingerprinting

This is the theory that it would be possible to document the size of an SSL encrypted web site request so that although an attacker cannot see the data going over the connection, it is possible to see what website the user is visiting. It could even be taken one step further where the table could not only have the initial website size but the first page, and then the redirected page after login. For instance, if someone visits their bank, they first get an initial login, and then a secondary authentication screen, and finally their actual online banking information. Each of those pages have a size that when put together, makes a pretty unusual fingerprint. If you tie this fact together with Mike Perry's SSL cookie exploit, one can imagine a situtuation where an attacker finds the website the user is visiting, inject an <img src="http://www.visitedwebsite.com"> where the cookie is sent in clear text and then a session hijack occurs.

Automatic Control Port Authentication

There has been an addressed issue that shows how an attacker could gain control of a Tor client's control port (which is what's used to generate tunnels) thereby granting the ability to redirect the tunnel or something even more malicious. The work around for this was to provide authentication done either by a password or by a session cookie. Clients like Vidalia now support the authentication mechanism but the problem currently is how is the authentication done at the boot time when a user installs Tor as a Windows Service. Roger didn't have an answer yet to this issue besides that it was currently being worked on.

Purchasing Old CA's

If you look in Firefox or IE or Opera or whatever, you'll see a pretty long list of pre-trusted certificate authorities that come when you install the browser. These are some of the most popular ones that have been trusted for years and come with the browser itself. It just so happens that a lot of these CA's are not even in business anymore but they're still in the browsers in case someone has purchased a certificate that extends through 2020. So what? Well the issue is what if an attacker purchased one of those old CA's, if they wanted to do a MITM attack with SSL, they could and the browser would have no problem with it. There was even a comment about how China is interested in purchasing one to help out with deep packet inspection even on SSL connections.

Governments and Law Enforcement

The last big issue that I thought was interesting to bring up was how some governments (see Germany and others) are pressuring Tor to provide "real time access to law enforcement." Whatever real time and law enforcement really ends up being. Roger makes the point that if it becomes this hard and this illegal, it may not be possible to run a Tor server in that country and it may be difficult to do so in the future.

External Links

http://www.torproject.org - Tor Project Website
http://www.kreativrauschen.com/blog/2007/11/09/german-bundestag-decides-to-implement-data-retention/ - Blog about the new German data retention logs
http://en.wikipedia.org /wiki/Data_retention - Wikipedia entry about data retention laws in other countries