Topic: How to locate a Tor Hidden Service ? (Read 1141 times)

As a Tor user and Tor Rely operator for a number of years now I have decided to make this post. I think both anonymity and privacy on the internet is increasingly important in today's world. I personally do not conduct any 'illegal' activities when using the Tor network. I make this open post to help ensure the future security of all Tor users.

Tor Hidden Services are just that i.e. 'hidden' and thus they are not totally invisible or anonymous.

- http://www.bbc.co.uk/news/technology-29987373

- https://blog.torproject.org/blog/thoughts-and-concerns-about-operation-onymous

Browsing via Tor does provide improved privacy, security and anonymity for most internet users and further protects against traffic analysis, in the main.

This is not a software bug report. This is out-of-the-box reverse engineering, of sorts...

"How did they locate the hidden services?

So we are left asking "How did they locate the hidden services?". We don't know.    In liberal democracies, we should expect that when the time comes to prosecute some of the seventeen people who have been arrested, the police would have to explain to the judge how the suspects came to be suspects, and that as a side benefit of the operation of justice, Tor could learn if there are security flaws in hidden services or other critical internet-facing services. We know through recent leaks that the US DEA and others have constructed a system of organized and sanctioned perjury which they refer to as "parallel construction."

Unfortunately, the authorities did not specify how they managed to locate the hidden services. Here are some plausible scenarios:

... Operational Security ... SQL injections ... Bitcoin deanonymization ... Attacks on the Tor network ... "

 
~ It is already known that a Tor Hidden Service provides better anonymity for users over Hidden Service operators. Tor developers have made this very clear in the existing website documentation.

1. Always Read the Manual - https://www.torproject.org/docs/tor-manual.html

" StrictNodes 0|1

    If StrictNodes is set to 1, Tor will treat the ExcludeNodes option as a requirement to follow for all the circuits you generate, even if doing so will break functionality for you. If StrictNodes is set to 0, Tor will still try to avoid nodes in the ExcludeNodes list, but it will err on the side of avoiding unexpected errors. Specifically, StrictNodes 0 tells Tor that it is okay to use an excluded node when it is necessary to perform relay reachability self-tests, connect to a hidden service, provide a hidden service to a client, fulfill a .exit request, upload directory information, or download directory information. (Default: 0)

"ExcludeNodes node,node,…

    A list of identity fingerprints, nicknames, country codes and address patterns of nodes to avoid when building a circuit. (Example: ExcludeNodes SlowServer, ABCD1234CDEF5678ABCD1234CDEF5678ABCD1234, {cc}, 255.254.0.0/8)

    By default, this option is treated as a preference that Tor is allowed to override in order to keep working. For example, if you try to connect to a hidden service, but you have excluded all of the hidden service’s introduction points, Tor will connect to one of them anyway. If you do not want this behavior, set the StrictNodes option (documented below).

    Note also that if you are a relay, this (and the other node selection options below) only affects your own circuits that Tor builds for you. Clients can still build circuits through you to any node. Controllers can tell Tor to build circuits through any node.

    Country codes are case-insensitive. The code "{??}" refers to nodes whose country can’t be identified. No country code, including {??}, works if no GeoIPFile can be loaded. See also the GeoIPExcludeUnknown option below."

2. Thinking outside the box.

With basic text edits to the Torrc .config file and using a process of elimination we can commence with a search for the most likely Geo location of a Tor Hidden Service.

Listing routers by country code via http://torstatus.blutmagie.de/ or another mirror presents data for the majority of Relays and Exits.

So, lets imagine that a .onion address might be physically hosted in say the US. First we try to connect to a hidden service to check its currently 'live'. If so, we exit Tor and edit the config with StrictNodes 1 and ExcludeNodes {us} then re-start Tor and try to browse to the hidden service once more and if it is now inaccessible then we might assume, with up to 99% accuracy (against MaxMind GeoIP) that the 'Hidden Service' is potentially hosted (or at the very least that its current Guard Server is routed) within the US.

If not, then we keep trying blocks of GeoIP country codes in descending order until a likely country match is found. Of course the actual percentage accuracy is less when including satellite, A1, unknown IP addresses and potential spoofing or Geo-rotational IP's that advanced Hidden Services might utilize.

Obviously this method cannot be considered 100% accurate, although when combined with other Tor network stats. and/or chronological data it is a potential method to commence with unmasking the location of a Hidden Service or attempting to monitor its users:

- What is the first know publication of the .onion address ?

- Was a new Relay created around that time and does this match the likely GeoIP location ?

- Does all or part of the Hidden Service code / software only run on linux or windows etc. ?

- What Relays probably don't host this hidden service ? Etc., etc.,

...

~ I could post a lot more with regards to this possible 'attack vector' for Tor Hidden Services. Its not really necessary to do so. In less than 30 bootstrap attempts to the Tor network using a regular home PC and some networking tools you can quite easily determine the most likely Geo location of a Tor Hidden service with a fairly high degree of accuracy. Combining this information with other already known and more sophisticated 'attack vectors' perhaps gives you something towards a "parallel construction" ... Well, in terms of networking anyway.

Always RTM.
 
EDIT: The obvious question is if StrictNodes are really strictly necessary as a hard coded Tor function ?