Explanation of various 'exit node'-attacks

Most of my work is towards Tor exit nodes so this article will focus on those. The purpose of this article is to give the reader a better understanding on how exit nodes works and how they can attack the user, and also a few ways to protect oneself.

Tor has an good doc about bad relays which you can read here: https://trac.torproject.org/projects/tor/wiki/doc/badRelays and basically a node gets flagged as bad if its tampering with exit traffic, filter/censors content and/or collecting data and later uses it(sniffing).

EDIT: The below listed attacks are not specific to Tor, they are just attacks that an exit operator can perform against an user.


Sniffing



This is were most of my research has been focused on because I found it rather lacking of focus and there are really a lot of things you can do to detect sniffing nodes. The main problem with sniffing nodes is that they can look completely normal on the outside so you can't really detect them using stand-alone tools.

Some of my methods for detecting sniffing nodes are:

  • Login over plain text with unique credentials and sees if they have been logged in multiple times
  • POST and GET data(exe, PDF..) over plain text and when opened they make an unique connection
  • POST and GET data containing unique links from big sites(pornhub, reddit...) over HTTP
  • Visit unique URLs and sees if they have been visited multiple times
  • Make unique SQL-injections against a phishing site and sees if the same payload has been used multiple times
  • and more....

It's a really fun area to work with. If you haven't, please read my previous blog post about trying to detect sniffing exit nodes: here and here for some better context.

The protection from (most) of these sniffing-attacks is using an encrypted connection(e.g HTTPS, SMTPS, IMAPS, SFTP...).

MITM attacks



MITM stands for Man in The Middle and in this case it means that there's a part between the client and the server that can manipulate the traffic. You could say that all attacks in this blog post are MITM but I wanted to be more specific.

There are so many different things you can do so I can't really name them all, but I can name the most common and maybe effective:

  • Change all links containing https:// to http:// (so the node can sniff)
  • Inject javascript into websites(e.g advertisement, BeeF, CSRF, exploit kits...)
  • SSH-MITM so the node force the user to login into an SSH-server that log keystrokes
  • Inject backdoors in executables using BDFactory
  • and many more...

MITM-attacks can very often be detected fairly easily and people constantly working to fins nodes that actively do MITM-attacks.

The solution once again is to use an encrypted connection. In the case of SSH-MITM you'll need to know the correct fingerprint you trust.

DNS attacks



Tor exit nodes handles DNS-requests so this means they also can control them. I've not seen many (if none) DNS-attacks occurring in the Tor-network in a long time but I know the've been done like this:

  • Give an incorrect response for domain lookups(e.g wrong IP for facebook.com)
  • Simply denying or censor domains

Attacks against SSL/TLS



You may already know that SSL is broken and can be exploited so of course this has happened in the Tor-network also. Attacks against SSL and TLS are actually one of the most sophisticated because they break protection that we rely on(but we shouldn't!). Anyway, here are some attacks against TLS/SSL I've seen and heard:

  • Down grade-attacks - force the user to use weaker ciphers(BEAST, POODLE, CRIME, Logjam)
  • Use a self-signed certificate for domains
  • Use a 'shared' rootcert(e.g Kaspersky, Superfish...)
  • SSLstrip - not really an attack against SSL but is still relevant because it's highly effective
  • Have port 443 open but closes connections and force the user to port 80

Rewriting onions and bitcoin addresses



By rewriting I mean that the exit node is configured to manipulate specific strings - in this case onion URLs. So if a user is visiting a site over HTTP and this site list some onions the node just rewrite some onion URLs to a look-a-like and this onion is a copy of the original but the purpose is to steal credentials or other information.

This is a kinda common attack but is fairly easy to detect. To detect this attack you can serve a huge list of onion URLs and download it over every exit node and see if its changed by controlling it with a local copy using algoritmic hashes/ssdeep or diff if you so like.

The solution is to always double check if you got the right address or bitcoin address by searching for it using a search engine. Or you can visit the page over HTTPS, but if the site does not offer HTTPS you must double check using a search engine or a trusted source via another encrypted channel(XMPP, IRC using SSL and so on...)

Not using ´MyFamily' option(Sybil attack)



The 'MyFamily'-option is used to identify nodes that are maintained by the same owner, in the same network or on the same machine. This is not something an exit operator needs to do but it's highly recommended because a client actually respect the 'MyFamily'-option by not trying to build a circuit containing any family members.

This is not an attack but it could be signs of an ongoing Sybil attack.

We actually try to find signs of Sybil attacks by checking how many new nodes that have been deployed in a short amount of time. There are many things you can look for also, like how many of the same operating system with the same Tor version has been deployed in the past X days and so on.

Of course very advanced Sybil attacks are made slowly and more spread. A well-thought-out Sybil attack will only use unique data centers, operating systems, Tor versions, nicknames, 'contactinfo' and deployed over a long period of time.

Timing attacks



This not an attack I've heard been used in Tor the way I'll explain it but it is possible but probably not effective. Maybe some of you will roll your eyes at this, but I think it's very fun to explore new possibilities so please don't take this section to serious.

The attack can work on mostly any protocol and its easy to understand how it works. It works by taking the time on how long it takes for the user to perform certain tasks.

This attack can also be used to identify users. If you have enough data and algorithms you can come a long way.

I'll make up a scenario because it makes it easier to understand(User A is target):

(0.) A drug dealer named user A is very paranoid so he always uses TBB for kiwiirc. The exit operator is also active on the same IRC-channel.

  1. A (new) request is made to irc.kiwiirc.com over SSL.
  2. At the same time user A enters the IRC.
  3. The exit operator now links to a legit site that is served over HTTP and short after he sees trafic going through his exit node so he injects spoofed "sign in with facebook/twitter to watch" kind of thing that he controls. A user gets fooled and does this.
  4. He has now deanonymized user A and also has his credentials.
  5. Because of the timing attack he can link user A to the matched twitter-credentials.

This attack is very hard to perform but is possible. It's easier to perform if the attacker owns several exit nodes(exit probability will be higher) and want to attack several users.

So let's say that this attack would work, it would be very hard to detect because it's only active a short amount of time.

Passive timing attacks



While I'm still writing about timing attacks I should name passive ones and how they can work also.

Passive attacks can be were an attacker collects data and later on analyses it. This could be used to see how long a user took to sign in and later analyses the results. For example - if a user takes 4.7 seconds to sign into a website the attacker could determine the size and/or length of the sent credentials.


How you can protect yourself



The majority of the above attacks are due to plain text so the best you can do is using encryption as much as you can. Many websites uses HTTPS these days and if they're not you should email the responsible and tell them to implement HTTPS as soon as possible.

But in cases were you have no choice to use HTTP you should take extra precautions. You need to keep in mind that Tor is a set of public proxy-servers so there will always be bad guys. Also make sure to google and/or check with a friend if you have an onion-domain to see if it's legit.