InspecTor is a .onion page that kept track of bad exit nodes on the network. And it did a pretty good job. It looked for things like:

• SSL Stripping: Replacing HTTPS links with HTTP
• JavaScript injection
• iFrame injection
• Exit nodes that have no exit policy (black holes)

Those are the easy to quantify bad properties. We can compare the results of connecting to a bad Exit Node and a good one and diff the results. These are some of the grey areas it also tries to look for:

• Warning about similar nodes in the same netblock
• Watch for similar named nodes spinning up hundreds of instances
• Look at the names of the nodes and conclude that they’re bad (e.g. NSAFortMeade)

The worst case scenario for a service like this, is that first, they’re wrong and kick off a perfectly good Exit Node. Second, they make users use custom routes to evade the bad nodes. Doing so means that your network traffic has a fingerprint. “He’s the guy that never users Iranian exits” for example.

And that’s kind of what happened with InspecTor – now celebrating the anniversary of it’s retirement a year ago. He went Judge Dredd on Tor and started making broad conclusions on what nodes were evil. For example, he said that NSAFortMeade is obviously an Exit Node owned by the NSA assumedly to catch the traffic of Americans (because they can’t do that already?). Other conclusions stated that a family of Tor nodes were from Washington DC. One of them was malicious so the conclusion was that it was probably the Government keeping an eye on us.

Tor’s Controls

What does Tor have as a control mechanism if they do somehow come across a bad exit node? The protocol has a “bad-exit” flag in it so that authorities can let Tor users that this Exit-Node should be avoided. That flag is set by The Tor Project admins as far as I know and you have to be blatantly offensive to cause this to happen. Here is the _total_ list  of nodes that are blocked today:

http://torstatus.blutmagie.de/index.php?SR=FBadExit&SO=Desc

This says that there are four bad nodes (one’s a bad directory server) on the network right now. I think most people would agree that is a bit low. You can take a look at this link for a complete list of the nodes they’ve blocked in the past. You should notice that a bad-exit flag doesn’t kick them off the network, it just tells the client to never use them as an exit. So these nodes can stay online as long as they want but they’ll never be used.

The Point

The point is not to just say everything sucks. How Tor isn’t doing a good job at monitoring for Exit Nodes or how InspecTor was doing too good of a job for it’s own good. It’s to highlight the real-world problem in Tor. Unlike the sexy theoretical attacks we like to wrap our heads around like global adversaries correlating your traffic back to an individual IP by statistically analyzing your web history patterns, the most likely thing to happen to you is that some douche nuckle is running dsniff and ulogd. And the point is also to highlight a need for a replacement of Snakes On A Tor. You can tell by it’s name, it’s a bit outdated. That is something actively being worked on but it may be a while before something reliable comes out of it.

Let me start by answering the short version of the question: Tor usually performs DNS requests using the exit node’s DNS server. Because Tor is TCP, it will only be able to handle TCP based DNS requests normally. Hidden services though are very different and rely on Hidden Service Directory Servers that do not use DNS at all. Read on if you don’t believe me or want more information.

Here’s a reference from an old mailing list entry:

Section 6.2 of the tor-spec.txt[5] outlines the method for connecting to a specific host by name. Specifically, the Tor client creates a RELAY_BEGIN cell that includes the DNS host name. This is transported to the edge of a given circuit. The exit node at the end of the circuit does all of the heavy lifting, it performs the name resolution directly with the exit node’s system resolver. …For the purposes of DNS, it’s important to note that a node does not need to be marked as an exit in the network consensus to perform resolution services on behalf of a client. Any node that doesn’t have an exit policy of ‘reject *:*’ may be used for DNS resolution purposes. [1]

Pudding for the Proof:

Don’t believe me? Let’s test it out. If I run an exit node and then try to use it for a circuit, my DNS requests should go through it right? I’ve spun up an exit node named “BrianCranston” and I’ll setup a client (who I’m calling Aaron Paul)  to only use this box as it’s exit node. You can do this by adding the following to your TORRC file:

And on my exit node, I do a tcpdump of all traffic on port 53. On my client I start looking for BrianCranston’s websites at briancranston.com and briancranston.org. Lets see what it looks like:

You’ll notice that Tor is being a little cheeky with the way it resolves DNS records.  briancranston.org turns into bRiancRAnsTON.org. I don’t know if this is just a nice way to let Exit Node operators know which hosts are being resolved by Tor or what.

UDP:

Tor is a TCP only network so what happens when it you need to use UDP services like DNS? The answer is pretty simple, it just doesn’t do it. Colin Mulliner and came up with a solution to this which was to relay UDP based DNS requests using a tool he wrote called TTDNS.(If you’ve ever used TAILS, this is what it uses.) In short, it takes a UDP based DNS query, converts it to TCP, sends it out over Tor, and converts the reply back to UDP once it’s been received.

Tor doesn’t natively support UDP based DNS queries, but Tor also only does two types of DNS queries: A records, and PTR records. It skips around needing to use CNAME by converting them to A records but officially, those are the only two supported.

Tools:

There are a couple of other items to note related to DNS. One is that there is a built-in tool called “tor-resolve.” Guess what it does… make DNS queries over the Tor network. This is useful for command-line scripts that are trying to resolve a host.

The other, is a TORRC option that will open up a port to provide DNS resolution over Tor. Once enabled, you can use the local host as a DNS resolver on the port you specify. Again, this is how TAILS handles DNS resolution.

What about Hidden services?

This is fine and dandy to resolve google.com, but what about a hidden service with a .onion address. Connecting to google.com goes out an Exit Node, but connecting to an .onion address never leaves the Tor network. In fact, Tor doesn’t even use DNS to resolve .onion addresses at all. Here’s how that works.

The names generated for .onion addresses are not just random values unique to your host, they are a base32 encoded version of the public key associated to your hidden service. When you create a hidden service, you generate a priv/pub key pair. This .onion address, the port it’s listening on, some other useful classifiers, and a list of “rendezvous points” are published to Tor hidden service directory nodes. The rendezvous points are locations on the Tor network where a client can initiate a connection to the hidden service.

So, following our Breaking Bad theme, if we had Brian (Cranston) and Aaron (Paul) wanted to exchange a secret web page that keeps track of all the meth they’ve sold, this is what the flow looks like:

1. Brian modifies the TORRC to offer a service on an IP address and port (127.0.0.1:443)
2. Brian creates a keypair for the service and the .onion address is saved (briancranston.onion)
3. Brian’s Tor client sends a RELAY_COMMAND_ESTABLISH_INTRO to start creating rendezvous points
4. Brian’s client sends the descriptors (rendezvous points, port, etc) to the Hidden Service Directory Servers
5. Brian then sends Aaron his .onion address (briancranson.onion)
6. Aaron’s client checks the Hidden Service Directory Server to see if the address exists
7. Aaron’s Tor client makes a circuit to one of the rendezvous points
8. Aaron connects to the rendezvous point and tells it about _his_ rendezvous point.
9. This rendezvous point is passed to Brian
10. Brian connects to Aaron’s rendezvous point
11. The rendezvous point lets Aaron know that Brian’s service has been forwarded at that point
12. Aaron finally makes a connection to Brian’s service

So in short, hidden services are resolved using Hidden Server Directory Servers and the Tor client. There currently is no way (AFAIK) to manually just resolve onion addresses. That means, if you’re trying to connect to a hidden service using a script, you’ll have to properly tunnel the requests through Tor. That’ll be for another day. 

If you need more information, check out these links:

http://archives.seul.org/or/talk/Jul-2010/msg00007.html - old mailing list message about DNS. A bit out dated but very useful

https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=rend-spec.txt - discusses the rendezvous protocol specification that is the basis of hidden services.

Browser fingerprint tactics, like the ones demonstrated in Panopticlick have been used by marketing and website analytic types for years. It’s how they track a user’s activities across domains. Just include their piece of JavaScript at the bottom of your page and poof, you’re able to track visitors in a variety of ways.

I don’t care much about using this technology for marketing, but I do care about using this type of activity for operational security purposes. Imagine using this technique as a counter-intelligence tactic. You don’t want to prevent someone from accessing information, but you do want to know who is doing it, especially if they have ill intentions in mind. IP addresses are adorable but hardly reliable when it comes to anyone that knows how to use a proxy, so using a fingerprint application, like Panopticlick, we can see who is visiting the site no matter what their locations appears to be.

Here’s a simple way of using Panopticlick’s JavaScript for your own purposes to gather fingerprint information about your browser. I’ll leave it up to you to figure out what you can do with this.

“More Worser”

Panopticlick’s informatino gathering techniques are very similar (see the same) as Browserspy except that they correlate the results to a dataset. If you really wanted to do all the browser fingerprinting without any of the reporting, you can take a look at the BrowserSpy code.

I’ve also worked on a technique years ago that attempts to verify your IP address using DNS. This was a pretty good technique especially for third party plugins like Flash and Java which were inconsistent when it comes to using proxies correctly. For more information about using DNS to extract an IP address and further gather information about a user, check out HD Moore’s now decommissioned Decloak project.