The Essence of What Happened
In May 2020, a group of exit nodes was discovered that were interfering with outgoing connections. Specifically, they left almost all connections untouched but intercepted connections to a small number of cryptocurrency exchanges. If users visited the HTTP version of the site (i.e., unencrypted and unauthenticated), the malicious nodes prevented redirection to the HTTPS version (i.e., encrypted and authenticated). If the user did not notice the substitution (for example, the absence of the lock icon in the browser) and began transmitting sensitive information, that information could be intercepted by the attacker.
The Tor Project excluded these nodes from the network in May 2020. In July 2020, another group of relays conducting a similar attack was discovered, after which they were also excluded. It is still unclear whether any users were successfully attacked, but given the scale of the attack and the fact that the attacker repeated the attempt (the first case affected 23% of the total bandwidth of exit nodes, the second about 19%), it is reasonable to assume that the malicious actor deemed the costs of the attack justified.
This incident is a good reminder that HTTP requests are unencrypted and unauthenticated and thus remain vulnerable. The Tor Browser comes with the HTTPS-Everywhere extension, specifically designed to prevent such attacks, but its effectiveness is limited by the list, which does not cover all websites in the world. Users visiting HTTP versions of websites will always be at risk.
Preventing Similar Attacks in the Future
Methods to prevent attacks are divided into two parts: the first includes measures that users and site administrators can take to enhance their security, while the second concerns the identification and timely detection of malicious nodes in the network.
Recommended Actions for Websites:
1. Enable HTTPS (free certificates are provided by Let’s Encrypt)
2. Adding redirection rules to the HTTPS-Everywhere list so that users can proactively establish a secure connection rather than relying on redirection after an unsecured connection is established. Additionally, if the web service administration wishes to completely avoid interaction with exit nodes, they can provide an onion version of the site.
Currently, the Tor project is considering a complete shutdown of unsecured HTTP in the Tor Browser. A few years ago, such a measure was unthinkable (too many resources had only unsecured HTTP), but HTTPS-Everywhere and the upcoming version of Firefox have an experimental feature that enables HTTPS by default for the first connection, with the ability to revert to HTTP if necessary. It is still unclear how such an approach will affect Tor Browser users, so it will first be tested at higher security levels of the browser (the shield icon).
On the Tor network side, volunteers monitor the behavior of relays and report incidents, allowing malicious nodes to be excluded by the directory root servers. Although such reports are usually addressed quickly and malicious nodes are disabled immediately upon detection, there are not enough resources for continuous network monitoring. If you manage to identify a malicious relay, you can report it to the project; instructions are available at this link.
The current approach has two fundamental problems:
1. It is difficult to prove the maliciousness of an unknown relay when considering it. If no attacks have been observed from it, should it be left in place? Mass attacks affecting many users are easier to detect, but if attacks only affect a small number of sites and users, the attacker may act preemptively. The Tor network itself consists of thousands of relays located around the world, and such diversity (and the resulting decentralization) is one of its strengths.
2. When considering a group of unknown relays, it is difficult to prove their interconnectedness (i.e., whether they are conducting a Sybil attack). Many voluntary relay operators choose the same cheap networks for hosting, such as Hetzner, OVH, Online, Frantech, Leaseweb, etc., and if several new relays are discovered, it will not be easy to definitively assume whether multiple new operators have emerged or just one managing all the new relays.
Source: linux.org.ru
