Security

Spoiled onions and Tor exit relays

The Tor network offers users a valuable set of features designed to ensure anonymity, but those features rely on the availability of well-behaved Tor nodes. A research team in Sweden recently explored the Tor network looking for malicious nodes, and its newly-released findings indicate that while the bad actors are few, they are indeed out there.

The team is led by Philipp Winter and Stefan Lindskog at Karlstad University; their past research has looked at other potential threats to Tor, such as the "Great Firewall of China" and various deep-packet inspection (DPI) techniques. The new study took a look at Tor exit relays, the final nodes in Tor's network circuits which make the last-hop connections with Internet servers. These connections are not encrypted by Tor (although the payload connection itself could certainly be running over SSL/TLS), so they are particularly important to the integrity of the Tor network as a whole. A malicious exit relay could undermine its connections with a variety of man-in-the-middle (MITM) attacks: traffic sniffing, DNS poisoning, SSL stripping, or even HTTPS MITM interception.

Like a relay over trouble water

Winter and Lindskog monitored the Tor network for four months in 2013, analyzing the behavior of more than 1000 exit relays. They published their results [PDF] in January 2014. To detect a malicious relay, they used a lightweight Python tool that creates Tor circuits to a decoy destination, specifically choosing each exit relay used in order to test as many as possible. This is a non-standard feature of the test program; Tor clients can choose the circuit they use for their connection (in order to make it harder for outside attackers to predict the circuit), but by default Tor randomizes the circuit, rather than asking the user for input.

Relays conducting HTTPS MITM attacks could be detected by simply comparing the fingerprint of the destination's X.509 certificate as reported by the relay with the known, correct certificate. The tool could also detect SSL stripping attacks, in which the malicious relay would rewrite HTTPS URLs as HTTP equivalents. Here again, detecting the interference of the exit relay is a simple matter of comparing the document returned through Tor with the known original.

The team also tested SSH connections, in which a malicious relay might attempt to replace the destination server's public key, as well as DNS requests. SSH MITM attacks are more difficult to carry out, they note, because replacing the destination key only fools the SSH client if the client has never connected to the server before—for a known server, SSH will report the key mismatch to the user. DNS poisoning, they note, is not common, but in the past there have been incidents reported where Tor exit relays inadvertently blocked certain sites by running filtering software.

Results and impact

Over the course of the four-month scan, the team encountered just 25 misbehaving exit relays. As a percentage of Tor's total network, that is quite small; the roughly 1000 relays scanned during the test accounted for every active exit relay the team saw. Still, some might consider 2.5% high, particularly in light of the fact that most Tor clients cannot select the exit relay used for their connection.

The bad relays are summarized in a table as well as in the paper. The majority of the attacks detected were HTTPS MITM (18), followed by SSH MITM (5); several relays were found to mount both attacks. There were also two SSL-stripping relays, two relays that redirected DNS requests, and one that used an HTML injection attack.

Looking at the fake HTTPS certificates returned by the bad relays revealed another interesting fact: the researchers found that all of the HTTPS MITM relays returned a certificate signed by the same root Certificate Authority (labeled "Main Authority," which is not a genuine CA). That may suggest that all of the malicious exit relays were run by the same attacker, although there are other possibilities (such as a malicious-relay-in-a-box program). These exit relays were located in several countries, in several different IP address blocks, but in addition to using the same root CA, they were all running the same version of Tor.

The decoy destination site requested during each test also appears to have made a difference. The team reports that some of the tested relays would only launch an attack against their decoy site that used the word "bank" in its domain name.

Interpreting the significance of these results is a subjective exercise. The Tor network has mechanisms in place to block an exit relay if it is believed to be acting maliciously. The paper also notes that the HTTPS MITM attacks would be difficult to pull off against a real user, because the phony root CA used would trigger an invalid-certificate warning from the browser. Of course, that supposes that the user takes the invalid-certificate warning seriously, which is certainly not guaranteed, but it could be argued that a Tor user would be more cautious than average.

Going forward, the researchers recommend a few possible paths to protect users against attack. One is fetching server certificates in parallel over multiple Tor circuits, a technique that has also been recommended elsewhere for use with direct HTTPS connections (such as Convergence). They also speculate that initiating a certificate fetch (over a different circuit) whenever an invalid-certificate warning is encountered could be valuable.

For its part, the Tor project has historically been good about anticipating new threats and adapting to them. The Tor Browser Bundle, for example, incorporates the HTTPS Everywhere extension specifically to guard against SSL-stripping attacks. Whether or not 25 bad exit relays constitutes a significant-enough threat to prompt changes to Tor is up to the project to decide. The existing countermeasures can certainly block out 25 bad exit relays, but perhaps there would be ways to detect these relays without requiring a four-month study. For Tor users, the good news is that the vast majority of tor exit relays seem to be behaving properly—but the bad news is that there are no guarantees.

Comments (6 posted)

Quotes of the week

Comments (none posted)

libreswan: denial of service

Comments (none posted)

cxxtools: denial of service

Comments (none posted)

clamav: multiple vulnerabilities

Comments (none posted)

tor: poor random number generation

Comments (none posted)

python-jinja2: code execution

Comments (none posted)

strongswan: denial of service

Comments (none posted)

xen: denial of service

Comments (none posted)

openjdk-7: unspecified vulnerability

Comments (1 posted)

libmicrohttpd: code execution

Comments (none posted)

openstack-heat: two vulnerabilities

Comments (none posted)

openstack-neutron: information disclosure

Comments (none posted)

Alkema: Misconceptions about forward-secrecy

Thijs Alkema has posted a blog entry addressing several common misconceptions about forward secrecy. Included in the discussion are a debunking of the notion that using more keys results in greater difficulty breaking the encryption ("To break a number of Diffie-Hellman negotiated keys all using the same Diffie-Hellman group, a number of different attacks are known. Many of these scale pretty well in the number of sessions.") and a look at the notion that forward secrecy makes it impossible to break future sessions. "The first two steps do not use the key at all, their result can be stored for later use to decrypt future keys. There is a trade-off here, though: the larger the factor base, the slower the first and second stages are, but the faster the third stage is. It’s unlikely that it is worth the effort to make the third stage as efficient as decrypting a session with a RSA private key is, but it’s not impossible."

Comments (none posted)