Anonymous Living

A paper technical paper released in February by UColorado/Boulder outlines how to attack Tor using a few evil servers. A spokesperson for the Tor-project was quick to respond, saying that they are aware of the problem and that nothing indicates that such an attack has been launched “in the wild” yet.Yesterday “respectable” publication ZDNet repored that “Hacker builds tracking system to nab Tor pedophiles“. Such tracking has nothing to do with nabbing pedophiles and everything to do with compromizing the security of the entire Tor-network and all it’s users. So this article should be very alarming.

However. A close inspection of the “tracking measures” outlined in the article indicates that the supposed “tracking” is no threat at all.

Here’s why:

The supposed tracking method what ZDNet calls “über-hacker HD Moore” proposes is:

1. Run a patched TOR server. The patches embed a Ruby interpreter into the TOR connection engine and allow arbitrary Ruby scripts to process data before sending it back to the client.

2. When child porn-related keywords are seen (either the Web request, or the response), inject a little extra HTML code into the response going back to the Web browser. This HTML code would connect to my decloaking engine.

3. The decloak engine is based on the following techniques:

Now. 1). Running a patched Tor-server is a bad thing and a threat to the network. Depending on patch. This patch, however, as described in 2), would have to be used on a Tor exit server and all it would do is to modify the HTML file passed back to the client. This, on it’s own, doesn’t do any kind of traffic, it only means that you would get a modified page back. Tor-exits modifying the traffic would on it’s own be a very bad thing, such servers mean that you would have to reload the page from another exit node if it comes back modified, but that alone is no security threat and doesn’t do any tracking.

The tracking would be done by the users browser, triggered by the extra HTML code. This concept could just as easily be done with anyone with a webserver, now can’t it? You’re reading this page, which means that I’m in control of the HTML your browser got. Pretty much the same situation of a patched Tor-exit node giving you “tracking” HTML, don’t you think? So the “Tor-server-patch” described would – at best – only be somewhat annoying.

But wait. It this kind of HTML tracking possible?

Let’s take a close look at ZDNet story regarding the actual tracking described.

a) A unique identifier is created to track this user.

b) The browser is asked to resolve a unique host name, containing the identifier, that is part of a special domain hosted on my server. I run a modified DNS server that updates a database with the address from which the DNS request is received. The goal of this step is to determine the ISP of the user.

As people who have any idea what they are talking about are aware, Tor resolves hostnames through the Tor-network. Thus; b) would determine that Someone used the patched Tor-exit, and then resolved the identifier domain using another Tor-exit. This does not reveal anything about the users ISP, it reveals.. that the same user is (still) using the Tor-network. This information is useful because..? Well, you already know the person in question is using the Tor-network, don’t you, how else would someone have fetched the page using Tor, eh?

And then there’s this:

c) The browser is asked to load a Java applet. This applet uses two different techniques to obtain information about the user.

d) The first method uses the Java API to determine the local IP address of the user. This value is then passed back to the JavaScript code in the Web HTML snippet hosting the applet. The goal of this step is to get the real *internal* IP address of the user.

e) The second method involves the applet sending a raw DNS packet, directly to my server. Since this is UDP, it does not pass through TOR, and since it is sent by the Java code, it does not go through the ISP. This packet contains the unique identifier and if received, gives away the real *external* IP of the user. The goal of this step is to get the address of the user’s NAT gateway.

Now. This information is true. Java does allow tracking of Tor users. This is true regardless of someone running a patched Tor-server. Any website with a Java-applet can track users who browse with Java enabled. This information is in every Tor-howto. You have to disable Java when you’re using Tor. You should also disable Javascript and disable Active X.

So. Tracking is still possible if you have Java enabled in your browser. And every Tor-user who even glanced at the documentation knows this. Yes, c), d) and e) are possible if the Tor-user haven’t read the fine manual, but it simply won’t work on Tor-users who have disabled Java – which is about 99.99% of Tor-users.

Oh. There’s a claim f) after e). It’s..

f) At this point, my server is able to determine the internal address of the user, the external address from which they access the internet, and the ISP they use to provide DNS resolution, as well as the IP address they come from through the TOR network. This information, along with the unique tracking ID, allows me to identify a specific workstation within an organization or residence.

Again, true for the 0,01% percent of Tor-users who browse with Java enabled.

I don’t.

So, at this point, Mr. Moore, your server still has no idea what my address is, which ISP I use for DNS resolution or the IP address I came through the Tor network, and since your server has none if this information except some tracking ID which is useless you still can’t identify me, my organization or residence.

In bullet summary:

• Yes, you should disable Java when you’re using Tor – and the Internet in general – because Java doesn’t respect – or even care about – the web browsers proxy settings.
• The supposed tracking system does work for the 0.01% of Tor-users who never bothered to read the documentation.

Technorati Tags: Tor, security, anonymity, internet