Exposing Malicious Tor Exit Relays | Hacker News Reader

Exposing Malicious Tor Exit Relays

cs.kau.se

121 pointsmusty14 comments

You can include or exclude particular exit nodes in your torrc file, syntax is:

   ExcludeExitNodes <node>, <node>, <node> ..

to exclude. to only use particular nodes:

   ExitNodes <node>, <node>, <node> ..

where <node> can be a fingerprint, IP address (CIDR), country code.

Examples:

Use only US exit nodes:

   ExitNodes {us},

Block the nodes listed in this report (we block all of Russia, since listing each node slows down the matching):

   ExcludeExitNodes {ru}, 8F9121BF, 229C3722, 5A2A51D4, E455A115, 02013F48, 02013F48, 02013F48

edit: blocking by IP/range might be a better idea since fingerprints are easy to regenerate:

   ExcludeExitNodes {ru}, 64.22.111.168/29, 121.54.175.51/32, 111.240.0.0/12, 89.128.56.73/32, 117.18.118.136/32, 178.211.39.0/24, 24.84.118.132/32

edit 2: also make sure strictnodes is set to true:

   StrictNodes 1

That's not necessary. Most of the relays in the report were already BadExited by the Tor Project. That means that the network consensus has the "BadExit" flag set which tells Tor clients not to select a particular relay as the last hop in its circuit. In fact, by interfering with your path selection algorithm, you reduce your anonymity over time.

Could you elaborate on why manually blocking known bad exits is worse for anonymity than letting the network decide this?

Manually blocking known bad exits won't really hurt your anonymity but it's also not really necessary as the Tor Project does that for you.

I was actually objecting to stuff like this: ExitNodes {us}. By interfering with your path selection algorithm in such a strong way, you make it easier for attackers to narrow down your path over time (which gives them an idea of which exit relays to monitor) and intersection attacks also become easier. Then again, you might have good reasons to do exactly that. It depends on your threat model, of course.

First thing I did is to check the directory, there are 6 nodes that i've checked so far (starting from the bottom) that are still listed :

http://82.94.251.203/tor/status-vote/current/consensus

I see no problem with running this automated test and adding these nodes yourself once you find them since BadExiting is a non-transparent process that appears to have delays in it.

edit: as an aside, using country codes as I listed "ExitNodes {us}" is nothing more than an example to express the syntax options.

It is good to know incase you need to get a particular exit point for geo-restrictions, etc. and your adversary isn't the NSA.

That is interesting. Most exit nodes that were tampered with are in Russia. I wonder why that is so. I expected that it would more or less mirror the geographical distribution of exit nodes.

I'm one of the authors. We believe that the Russian relays are actually controlled by the same person/group. More details are in Section 4.2 of the paper.

So what's next - how do users of Tor protect themselves from these malicious exit relays?

First of all, it's not that big of a problem. While our list looks long and scary, there are around 1,000 exit relays, so the chance of selecting a bad one in your circuit is not high. Furthermore, Tor's path selection algorithm is weighted by a relay's bandwidth for load balancing (one of the many performance/anonymity trade-offs). Many of the fastest relays of the network are run by well-respected people and organisations such as the CCC. Also, the Tor Project "removes" malicious relays from the network (see Section 1.1 in the paper).

Finally, we published our scanner for a good reason: to crowd-source the hunt for more malicious relays :)

I've only glanced at the paper and haven't looked at the code at all so forgive me if I'm asking something that's easily answered in one of the two.

Regarding your scanner, is it possible to "set it up and forget it"? I work for an ISP and have plenty of machines and bandwidth available. If I can set this up on a box and let it do its thing without needing to babysit it or look after it constantly, it makes it much easier for others (like me) to help out with the "crowd sourcing".

That's a good point. It's not possible right now (unless you wrap it into a shell script) but we want to add some sort of "continuous scanning" option over the coming days/weeks.

Some of the attacks might actually be due to ISP misconfiguration or legal (court order) compliance. For instance, The Pirate Bay is blocked by several ISPs and exit nodes in their network would inadvertently be unable to route traffic to that site.

Most of the attacks such as HTTPS MitM are not ISP misconfigurations ;)

Indeed, they list the DNS censorship separately:

> We also found exit relays which were unintentionally interfering with network traffic because they were subject to DNS censorship.

Great article!

Always mind that Tor relays can harm you [1].

[1] https://www.eff.org/pages/tor-and-https

Reply on news.ycombinator.com