Malicious Tor Exit Relays in 2020: Growth, Impact, and Countermeasures

By Ava McKinneyOnline Safety

Development Dynamics and Impact of Malicious Tor Exit Relays in 2020

Over 23% of Tor’s Exit Bandwidth Involved in User Compromise

In December 2019, I published an article, The Growing Problem of Malicious Relays on the Tor Network, to raise awareness and improve the situation. Unfortunately, things have only gotten worse, especially regarding malicious activity among Tor exit relays.

Exit relays are the final hop in the three-relay Tor circuit and the only relay type that can see the user’s destination connection in the Tor Browser. Depending on the protocol used (e.g., HTTP or HTTPS), a malicious exit relay may be able to view and manipulate transmitted content.

This article provides updated information on the state of malicious relays during the first seven months of 2020, based on analysis of a large-scale, concerning attacker. The analysis demonstrates that current countermeasures are insufficient to prevent large-scale attacks of this kind.

Scale of Malicious Operator Activity

In my five years of monitoring, 2020 was the worst year for malicious exit relay activity. For the first time, an attacker was found to control over 23% of Tor’s total exit bandwidth. This means roughly one in four Tor connections exited through relays controlled by a single malicious operator.

Figure 1 shows the share of exit bandwidth under the attacker’s control and the number of confirmed malicious relays operating simultaneously (peaking at 380). On May 22, 2020, at the attack’s peak, the chance of selecting a malicious exit relay was 23.95%. Since Tor clients use many exit relays over time, the likelihood of encountering a malicious relay increases with continued use.

Temporary Removal of Malicious Relays

The relay count line in Figure 1 shows that relays were added in large batches, allowing the OrNetRadar service (a relay group detector) to identify these clusters, which happened multiple times (see Appendix). The most notable spike occurred in March 2020. On March 16, OrNetRadar and the Sybil Attack Detection Project reported a sudden surge of over 150 new relays in a very short period. These relays were removed but reappeared three days later after the attacker contacted the bad-relays mailing list and set up a “MyFamily” configuration to group them. Currently, there are no extra requirements for launching such large relay groups on the Tor network.

Speed of Recovery After Removal

Three sharp drops in Figure 1 (marked 1, 2, 3) represent events when some malicious exit relays were detected and removed by Tor directory administrators. The rapid recovery after each drop shows how quickly the malicious relay population was restored, and that not all malicious relays were found at once. After removal, it took less than 30 days to recover, with the chance of hitting a malicious relay rising from 4% back to 22%. Attackers are persistent and likely have contingency plans and spare relays to avoid a complete shutdown of their operations.

Multiple Fake Independent Relay Groups

The temporary removal of relays taught attackers a lesson: subsequent relays had perfect MyFamily settings, but instead of grouping all relays together, they created many separate, unconnected groups. This strategy has been used since January 2020. Figure 2 shows exit probability by group (stacked chart).

Figure 3 shows how many malicious exit relays from one operator were split into separate groups based on ContactInfo (stacked chart).

ContactInfo can be set arbitrarily by relay operators. While this data should be treated with caution, many of these email addresses interacted with the bad-relays mailing list, suggesting they are real and controlled by the malicious operator. Some addresses even impersonated the FBI (e.g., fbirelays@…), but these were never used to contact the bad-relays list, and there’s no reason to believe the FBI is involved. Attackers generally prefer well-known email services (hotmail, protonmail, gmail).

Figure 4: List of addresses used in the ContactInfo field by malicious exit relays.

Infrastructure Used

A key question in analyzing malicious relays is which hosting services are used. OVH is one of the largest providers hosting relays. Other notable providers include Frantech, ServerAstra, and Trabia Network. “Nice IT Services Group” is also of interest, as I had never seen relays in this little-known network until April 16, when the attacker added several relays.

How Malicious Relays Attack Users

The true scale of these operations is unknown, but the obvious motivation is profit.

Attackers perform man-in-the-middle attacks on Tor users by manipulating traffic passing through exit relays. They (selectively) remove HTTP-to-HTTPS redirects to gain full access to unencrypted HTTP traffic without triggering TLS certificate warnings. In the Tor Browser, this is hard to spot unless you specifically check for the “https://” prefix in the address bar. This well-known attack is called SSL stripping, exploiting the fact that users rarely type out full “https://” addresses.

Countermeasures like HSTS Preloading and HTTPS Everywhere exist, but many sites don’t use them, leaving users vulnerable. This attack isn’t unique to Tor Browser; malicious relays are simply used to access user traffic. To avoid detection, attacks are mostly targeted at cryptocurrency services, especially bitcoin mixers. Within HTTP traffic, bitcoin addresses are swapped to redirect transactions to the attacker’s wallets. While bitcoin address replacement attacks aren’t new, the scale here is impressive. It’s also impossible to know if other attack types are being used.

I contacted some affected bitcoin services to encourage technical countermeasures like HSTS preloading. Some implemented HTTPS-Everywhere rules for known domains (HTTPS-Everywhere is default in Tor Browser), but none used HSTS preloading at the time. At least one bitcoin site implemented HSTS preloading after these events.

Is the Attack Over?

Looking at Tor’s total declared exit bandwidth and the share used by attackers (which was removed), there was a significant increase in exit bandwidth after the last removal around June 21, 2020. This part of the curve resembles the previous month, when attackers recovered after the first removal around May 22, 2020. I added an “expected” line to the chart to show the anticipated total bandwidth without the unusual growth (roughly estimated by combining declared bandwidth added by known operators after removal).

Figure 7 shows the impact of the malicious relay operator on the probability that Tor Browser users will select an exit relay from a known organization (e.g., those listed at https://torservers.net/partners.html and other long-standing relay community members). The attacker reduced the chance of selecting a known exit relay from about 60% to 50%. The chart also shows that the share of known organizations is declining despite increased declared exit bandwidth.

This raises the question: “If the share of known operators is shrinking, whose share is growing?” Figures 8 and 9 show the share of exit bandwidth from unknown operators by autonomous system (Figure 8) and by relay ContactInfo (Figure 9). The charts show networks and ContactInfo with a significant share (over 0.5% chance of selecting their exit relay). The share of networks belonging to OVH (previously heavily used by the attacker) and Liteserver Holding grew significantly after the June 21, 2020 removal. Two new shares also appeared, each over 5% of total exit bandwidth.

These and other indicators (not published here to avoid helping attackers) show that malicious relay networks have not disappeared. However, as exploiting known victims has become harder, attackers may have chosen new targets or attack scenarios. Analysis is ongoing, and more details may be published in the future.

Countermeasures

Handling Bad Relays

After the December 2019 article on the rise of malicious relays, the Tor Project had promising plans for 2020, including appointing someone to oversee improvements. However, due to the COVID-19 pandemic, this person was reassigned. Additionally, Tor directory admins appear to have stopped removing relays as of June 26, 2020. The reason for this policy change is unclear, but it has allowed undeclared relay groups (previously removed for missing ContactInfo and MyFamily) to be added. This means that the discovery of an attacker controlling over 10% of guard node capacity in December 2019 did not lead to improvements. Since previous reports went unanswered for over a month, I stopped reporting relays for removal, but this topic deserves its own article. For now, note that the Tor Project has not allocated resources to address this problem.

Improved Visualization of “Known” and “Unknown” Network Shares

“We lack tools to track and visualize relays we trust.” — Roger Dingledine

It’s important to track when the shares of known and unknown networks change significantly. I aim to add charts like Figures 7 and 8 to the daily OrNetStats statistics. This is only possible if operator static identifier verification can be automated, as manual verification is too time-consuming. I’m working on version 2 of the ContactInfo Information Sharing Specification to give relay operators two simple options for automatic “operatorurl” field verification. Verified fields can then be used for a one-time manual assessment of the “known” label, which is then used for charts. Once version 2 is released (expected by the end of August 2020) and adopted by enough relay operators, such charts can be added to OrNetStats and other tools. This will also make it easier to implement Roger Dingledine’s plans. The key factor will be adoption of version 2 by relay operators.

Short-Term: Reducing Harm from the Threat

How can we make it harder and more labor-intensive for attackers to deploy large relay networks on Tor? Currently, there are no requirements for large-scale relay operators, so nothing stops an attacker from adding 150 malicious relays, as seen in March 2020.

The following recommendations assume the Tor Project lacks resources to address this issue:

  • As an immediate measure, the Tor Project could require physical address verification for all new (joined in 2020) relay operators with over 0.5% of exit or guard node bandwidth. Why 0.5%? It balances the risk of malicious relay power and verification effort. Above 0.5%, few operators need verification. As of August 8, 2020, only five exit relay operators and one guard node operator met these criteria (new and large). Some had similarities to previously removed malicious relay groups; others had good reputations. Initial verification would involve sending six letters to provided physical addresses (likely three, as some may not require verification).
  • This scheme also empowers those making tough decisions about suspicious relays.

Long-Term: Limiting Attackers by Reserving a Minimum Share for Known Operators

Roger Dingledine’s plan is to set a fixed lower bound for the “known” operator pool, limiting the damage malicious operators can do, regardless of their intentions or whether they hide individual relays or groups. This approach is good but should be combined with the following measures to make attackers’ lives harder:

  • Require a verified email address to obtain an exit or guard relay flag. Email verification can be fully automated. Since malicious relay operators can easily register new addresses, move to step two.
  • Require a verified physical address for large operators (over 0.5% exit or guard probability).

Conclusion

  • Since the discovery of large-scale attacks on the Tor network (malicious relay operators controlled over 10% of guard node capacity) in December 2019, no improvements have been made to reduce malicious relays.
  • The malicious relay operator discussed here controlled over 23% of Tor’s total exit bandwidth (as of May 22, 2020).
  • The operator restored capacity after initial removal attempts by Tor directory admins.
  • Multiple indicators suggest the attacker still controls over 10% of Tor’s exit bandwidth (as of August 8, 2020).
  • Recurring large-scale malicious relay activity shows current detection measures are insufficient.
  • Many countermeasures have been proposed to address the malicious relay bandwidth problem.
  • It’s up to the Tor Project leaders and directory admins to prevent harm to users.

Acknowledgments

I’d like to thank the person who wished to remain anonymous and initially reported some malicious relays, enabling deeper analysis and the discovery of large malicious exit relay networks.

Support for This Research

I’d like to continue researching suspicious activity on the Tor network that may pose risks to users. To analyze the problem more deeply, I need a license for Maltego Classic, as the free Maltego Community edition has limitations. If you work at Maltego or want to help, you can support this research by providing a license for this tool.

Appendix

Links to known malicious exit relays belonging to the attacker mentioned in this article:

Author: nusenu

Leave a Reply