Home / Blog / Tor, hidden services and de-anonymization

Tor, hidden services and de-anonymization

Posted on 01/07/2015, by Jesús Díaz (INCIBE)
Tor, hidden services and de-anonymization

Although Tor was created to improve the privacy of Internet users and avoid censorship, it may also be employed for other purposes [ES]. A recent example that shows the illegitimate trend of the actions carried out through Tor is described in the FinCEN (Financial Crimes Enforcement Network) report from the U.S. Department of State. This report states that out of a total of 6048 suspicious activities reported by banks between 2001 and 2014, at least 975 involved Tor nodes (however, we must recall that the initial release of Tor dates back to 2002).

Equally, Operation Onymous has been very representative, being executed by various international security organizations (Europol and FBI amongst others). Through this operation, 17 people who were responsible for 400 .onion addresses associated to a total of 27 websites (hidden services) were arrested.

- Page displayed in shut down sites -

Just like on other occasions [ES], this incident has activated the alarm bells between the project directors and the rest of the users who employ the network for legitimate purposes, with these people fearing for their anonymity. On one hand, it is possible (or probable?) that they have resorted to conventional police means (suspects surveillance), or that the secret services were not correctly configured, as seems to be the case which is explained in an email to the Tor distribution list (from the "supervillain" administrador, in his own words). On the other hand, it could also be due to the existence of flaws in Tor that are being exploited.

To have a better idea of the technical possibilities behind these theories, some of the most relevant recent attacks proposed/unveiled and a tool that can be used to analyse Tor are summarized next.

Auditing Tor network nodes

From a purely practical perspective, an interesting Spanish project (presented at CyberCamp) aimed at auditing Tor networks is Tortazo (docs). Based on Stem, the control library in Python for Tor, Tortazo allows to audit the Tor nodes that appear in the last network consensus (or that are stored in the application's database) in an automatic way. For example, with the following instructions, Tortazo will look for exit nodes with the Linux operating system, invoking Nmap with the "-sSV –A –n" options for the first 30.

python Tortazo.py -n 30 -v -m linux -a "-sSV -A -n"
python Tortazo.py --servers-to-attack 30 --verbose --mode linux --scan-arguments "-sSV -A -n"

Parting from the information gathered, and via the possibility of incorporating plugins in the tool, it is easier to find security errors in the nodes that make up the network. As it will be seen in the following paragraphs, there are certain nodes in Tor that play an important role when preventing attacks, meaning that checking its security is vital. In this task, tools such as Tortazo can be very useful.

Attacks against hidden services

As explained before, operation Onymous affected a number of Tor’s hidden services. In a previous post [ES] it was already explained how these services work. To sum up, a hidden service (HS from now on) publishes "contact information" (information known as hidden service descriptor) on a database distributed on the Tor network. Subsequently, any client that wants to use the service, gains access to the database and uses that information to contact with the HS through a meeting points (rendezvous) where both of them (client and HS) establish a Tor circuit, to avoid being traced. The final result is a connection as shown in the following graphic:

- Connection between a Tor client and a hidden service -

Notwithstanding, it is important to note that this way of functioning is more delicate in terms of the anonymity guarantees offered to the hidden service. In this case, when evaluating its security, it is necessary to assume the other extreme of the communication (the client) is under the control of an attacker of the system. In other words, to infringe the anonymity of a Tor client, it’s necessary to compromise both the network’s inward node and exit node. On the other hand, to infringe the anonymity of a hidden service, just the exit node needs to be compromised (given that the entry node could directly be the attacker).

"Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization" describes various relevant attack methods to de-anonymize hidden services in Tor based on traffic confirmation techniques and on the fact that an attacker can easily include illegitimate nodes in the Tor network that take advantage of their functioning characteristics. An important Tor network concept in these attacks is that of nodes known as entry guards. These are special nodes, that the clients and hidden services choose (and rotate periodically) to access the Tor network. Therefore the entry guards are the only nodes that have access to real IPs of those accessing Tor. Coming up, assume that an attacker wants to obtain the real IP address (123.124.125.126) from a hidden service with an xyz.onion address. One of the attacks exposed in the mentioned article is as follows:

  1. A node controlled by the attacker is selected as an entry guard on behalf of the xyz.onion hidden service.
  2. The client (attacker) establishes a connection with xyz.onion.
    • As the attacker is who establishes the connection, he can decide a rendezvous node that he controls.
    • This connection is associated to a cookie created by the client (attacker) and is also transmitted to the hidden service, which uses the rendezvous node to distinguish between connections.
  3. When the service in xyz.onion connects with the malicious rendezvous point:
    • The rendezvous node can associate this connection initiated by xyz.onion with the connection started by itself, as it contains the same cookie.
    • The rendezvous node sends anomalous traffic (researchers suggest sending 50 packages of a specific type) towards xyz.onion, followed by a petition to close the connection.
  4. Finally, the entry guard controlled by the attacker associates the received connection from 123.124.125.126 with the rendezvous node connection with the xyz.onion service, if:
    • The entry guard receives a petition to shut down the connection after the rendezvous node receives the xyz.onion connection with the cookie created by the attacker.
    • The number of packages received by the entry guard corresponds with the pattern of 50 packages sent by the rendezvous.

In other words, following this process, the attacker can associate the 123.124.125.126 IP address with the xyz.onion hidden service. The following scheme graphically represents the attack.

- Scheme of an attack to a hidden service -

One important aspect remains, and it’s that the attack depends on the hidden service choosing a node controlled by the attacker as an entry guard. However, given the selection policy of these nodes when investigating, the authors estimated that, with a cost of 8280€, in an interval of 8 months, there will be a 90% chance that one of its servers (they displayed 23 in their experiments) will be selected as an entry guard by any hidden service (of long duration). This time and cost isn’t by any means far from the reach of big organizations.

Another alternative that an attacker could take to increase the possibilities of one of its Tor nodes being selected as an entry guard is reducing the number of available entry guards (those that have the "Guard" flag in the consensus reached by the Tor network authorities). For example, a recently discovered attack, called Sniper Attack, enables an attacker to deny services directed at arbitrary Tor nodes. The authors of this work state that a strategic attacker could, for example, reduce the bandwidth available on Tor by only 29 minutes.

Minimizing the success probability of the attack

As proven, entry guards and their selection policies play a very important role in Tor. This policy is based on choosing three entry guards, which rotate between 30 and 60 days. However, to increase the difficulty of these types of attacks, minimizing the probability of choosing an entry guard controlled by an attacker, Tor developers have changed this policy so that now each Tor user (including hidden services) choose only one entry guard. Recently, they’ve also suggested increasing the rotation period of the entry guard to 9 months.