Introduction
When looking at how Tor works, we’ve looked at the various types of nodes that make up the Tor network. However, you’ll notice that we haven’t dealt too much with exit nodes. Exit nodes are the final link in a Tor “circuit”, or path from the client to the server. Since exit nodes send data to the final destination, they can see the data as if it had just left the device.
This visibility puts quite a bit of trust in exit nodes and, for the most part, they tend to act responsibly. However, this isn’t always the case. This post will take a look at what happens when a Tor exit node operator decides to “break bad” and wreak havoc on Tor users1.
A Case of the Sniffles
Tor exit nodes are the definition of a man-in-the-middle (MitM). This means that any unencrypted protocols (e.g. FTP, HTTP, SMTP, etc.) can be seen by the exit node operator. This includes things like usernames, passwords, session cookies, or even file uploads/downloads.
To be clear: Tor exit nodes can see traffic as if it were just leaving your device.
The unfortunate part about this is that there is nothing (aside from using encrypted protocols… more on this later) we can do about this. Sniffing is a completely passive operation, so the only protection is to be aware of the risks and avoid passing any sensitive data over Tor unencrypted.
But let’s say you’re an exit node operator trying to break bad, not break slightly-inconvenient. Sniffing is for chumps. Let’s turn it up a notch and start modifying some traffic.
Turn it up to 11
Remember - as an exit node operator, we’re responsible for passing traffic to and from the client unmodified, right? Yeah, right.
Let’s take a look at just a few of the ways we can modify traffic:
SSL MiTM & sslstrip
SSL rains on our parade if we’re trying to cause havoc for our users. Fortunately for us as attackers, many sites have issues that allow us to force the user through unencrypted connections. Examples include redirects from HTTP to HTTPS, including HTTP content on an HTTPS site, and more.
A nifty tool to take advantage of this is called sslstrip. All we have to do is proxy the traffic leaving our exit node through sslstrip and it’s game over in many scenarios.
Of course, if we want to be less sneaky, we can just straight up terminate the SSL connections with a self-signed cert. Then we have insight into all the SSL traffic crossing our exit node. Piece of cake.
Hooking Browsers with BeEF
Now that we have insight into more traffic than before, we can start doing some damage. One example of this would be to use the BeEF framework to automatically “hook” browsers so they are under our control. Then, we can leverage Metasploit’s “browser autopwn” function to compromise the end host and drop a reverse shell. Game over.
Backdoor Binaries
Let’s say that we see binaries being downloaded through our exit nodes. These can be full software downloads, or even updates to existing software that’s happening in the background that the user isn’t even aware of.
All we have to do to transparently backdoor binaries would be to proxy the Tor traffic through something like The Backdoor Factory. Then, as the software is executed, the end host is compromised. Game over.
Catching Walter White
While most Tor exit nodes (from what we can tell) play nice, it’s not terribly uncommon to find some that don’t. Remember all those theoretical attacks we just talked about? They actually happened.
Fortunately, the Tor Project thought of this and designed a safeguard to prevent bad exits from being used by clients. This comes in the form of a flag in the consensus. Not surprisingly, the flag is called BadExit.
To address the problem of hunting down bad exit nodes, a slick system called exitmap was created.
Exitmap works like this:
- For each exit node:
- Run Python module (file upload/download, login, etc.)
- Record the results
Exitmap leverages the awesome Stem library to do most of the heavy lifting for building circuits to each exit node. Pretty basic, but effective.
Back in 2013, exitmap was created as part of the Spoiled Onions project. The authors of the paper found 65 exit nodes that were tampering with traffic. This shows that, while the problem isn’t rampant (there were about 1000 exit nodes when they wrote the paper), it’s bad enough to warrant a sheriff to make sure exits are playing nice, which is why exitmap is still up, running, and actively maintained.
In another example, a researcher basically set up a fake login page and logged in through every exit node (similar to exitmap). Then, the HTTP logs were watched for any further login attempts. Multiple nodes tried to break in to the site using the same credentials the author used.
This Isn’t Just Tor’s Problem
It’s important to note that this isn’t just Tor’s problem. There are a substantial number of hops along any given path, including the normal path between you, your ISP, and the cat picture you’re trying to look at. All it takes is one operator with malicious intent to cause serious harm.
The best thing you can do is to enforce encryption wherever possible. If the traffic can’t be seen, it can’t (feasibly) be modified.
Finally, keep in mind this is just an example of what happens when Tor operators act irresponsibly. This is not the norm. In fact, a vast majority of exit node operators take their role very seriously and deserve a major “thank you” for all the risk they assume to keep information flowing freely.
1 Actual image of evil Tor exit node operator. Not really.