Tracking One Year of Malicious Tor Exit Relay Activities (Part II)

Figure 1: Malicious Tor exit fraction (measured in % of the entire available Tor network exit capacity) over time by this particular malicious entity between July 2020 and April 2021. Peak value: The attacker did manage approx. 27.5% of the Tor networks exit capacity on 2021–02–02. Graph by nusenu (raw data source: Tor Project/onionoo)
Figure 2: 2020–08–16: ContactInfo “exitrelays@protonmail.com” tor relays get caught doing MITM attacks. They got removed from the tor network on 2020–08–17. Source: https://twitter.com/leak_ix/status/1295030849663053825
Figure 3: 2020–08–18: ContactInfo “kleinendorstwiebe AT gmail DOT com” tor relays are confirmed as malicious. They got removed on 2020–08–19. Source: https://twitter.com/notdan/status/1295813432843829251

New negative records

The graph in Figure 1 starts where the first graph in the previous blog post ends and shows the fraction of known malicious exit capacity linked to this specific actor between July 2020 and April 2021. You can see the repeating pattern of new malicious relays getting added to the tor network and gaining significant traction before dropping sharply, when they got removed.

  • on 2020–10–30 the malicious entity operated more than 26% of the tor network’s exit relay capacity
  • and on 2021–02–02 they managed more than 27% of tor’s exit relay capacity. This is the largest malicious tor exit fraction I’ve ever observed by a single actor.
Figure 4: Confirmed malicious Tor exit capacity (measured in % of the entire available Tor exit capacity) between 2020–06–21 and 2020–11–01 by ContactInfo (stacked). Only actual malicious relays are included (for example not all relays using ContactInfo CypherpunkLabs were malicious. Graph by nusenu (raw data source: Tor Project/onionoo)

New malicious trends

But also new attack trends and have been observed:

  • large exit fraction without any relay ContactInfo: This actor is increasingly adding malicious tor relays without any ContactInfo (this is the largest fraction, shown in red in Figure 4). Once a malicious tor exit relay is detected, all other relays using the same ContactInfo are easily found and removed, this is not an issue for them if they do not have a ContactInfo at all. Figure 5 shows the overall tor exit fraction that had no ContactInfo set (blue) and what part of it was malicious (red). We can obviously not rule out that even more of them are malicious and we failed to detect them. The vast majority of exit capacity without ContactInfo was malicious between October 2020 and March 2021.
Figure 5: What fraction of exit relays not having any relay ContactInfo was malicious? (You can ignore the straight red line above “Apr 1, 2021”, that is just a interpolation) Graph by nusenu (raw data source: Tor Project/onionoo)
  • impersonation attacks against other operators: This is not directly visible because the list of contacts was too large to include in Figure 4, but the malicious actor also started to impersonate other operators to hide malicious relays by using their ContactInfos. In one case they used CypherPunkLabs’ ContactInfo. (Side note: To avoid false positives Figure 4 was generated by identifying malicious relays by fingerprint and not by searching for the ContactInfos used by CypherPunkLabs.)

Reaction time matters

In August and September 2020 malicious relays got reported and removed continuously (see the Appendix II for examples). In October 2020 the malicious exit fraction reached a new record (>26% malicious exit fraction). What was different in October 2020? Like the previously identified groups, also the groups appearing at the end of September and the beginning of October 2020 got detected by OrNetRadar (a relay group detector):

Figure 6: Malicious exits using ContactInfo “supportanonymity.club” and “coronamitmdisease2019@hotmail.com” got reported when their exit fraction was at 0.57%. Graph by nusenu (raw data source: Tor Project/onionoo)
Figure 7: Malicious Tor exit relays reported on 2020–08–20 and found on the tor network again in April 2021 (removed on 2021–04–27). Graph by nusenu (raw data source: Tor Project/onionoo)

New adversarial tactics

In September, on 2020–09–03 “Андрей Гвоздев <andrejgvozdev55@gmail.com>” reported CypherpunkLabs relays, an undeclared relay group (but not necessarily run with malicious intends), to bad-relays at lists.torproject.org.

Unexpected Luck with WHOIS data

On 2020–10–31 Roger Dingledine sent an email to the tor-relays mailing list mentioning that tor directory authorities removed a long list of malicious exit relays for performing the known attacks (mitmproxy, sslstrip) against tor users. Side note: Since CypherPunkLabs did not properly declare their relay group it was not possible to tell their relays apart from the attacker’s relays (they even used the same hosting company for the malicious relays). So all of them, those actually run by CypherpunkLabs and those run by the attacker, got removed altogether:

Source: twitter
Group #7: other
4E6C7297F16523A236EE1A2EE23AF54ABEF15490
55D490E9E440DD4458F16ABCDD79F48396D55EA9
78F699D58F3353AB6C4CE39E3BD96CE87439753A
B1896E58FDEB5627B6B8334E6ABD42767AB8B0D9
Figure 8: WHOIS records contain the email address “andrejgvozdev55@gmail.com” as abuse contact for the small IP block used by malicious exit relays. Source: RIPE Database (archived version)
Figure 9: Inverse RIPE DB lookup for abuse handle finds an additional IP block also containing malicious exit relays. Source: RIPE database (2021–01–04).
  • andrejgvozdev55@gmail.com tested the bad-relays team by reporting the CypherPunkLabs relays to see if they get removed for improper MyFamily configuration. This information is crucial for them because an attacker can not establish a mutual MyFamily configuration with the victim they impersonate. A few weeks later malicious relays appeared using the CypherPunkLabs ContactInfo (CypherPunkLabs was not the only relay group they reported..).
  • andrejgvozdev55@gmail.com shows up as abuse-contact in WHOIS for two small IP blocks that contain malicious tor exit relays.
  • One of these exit relays in these IP blocks used a confirmed malicious ContactInfo previously identified (“fbirelays@protonmail.com”).
The abuse-contact information for the IP addresses used by malicious tor exit relays. Source: RIPE database (archived version)
Figure 10/11: The abuse-contact address of the IP range hosting malicious tor exit relays (185.32.222.166–185.32.222.173) is allegedly located at this building in Moscow according to RIPE database records. Image Source: yandex.com
Figure 12/13: The alleged abuse-contact address used by the malicious exit relay operator can also be found on booking.com. According to moscowmap.ru the building has 108 apartments and 9 floors. That makes 12 apartments per floor, so apart. 12 (“kv12”) could theoretically be on the ground floor. Image Source: Google Maps / Booking.com (2, 3) (Zvenigorodsko(y)e shosse 13 / Звенигородское шоссе 13)

>1 000 new exit relays in early May 2021

The tor network usually consists of less than 1 500 tor exit relays. In early May 2021 over 1 000 new unnamed tor exit relays without ContactInfo joined the tor network within less than 24 hours (1, 2, 3, 4). Although that sounds like an impressive number of exit relays, such massive relay groups impose little risk for tor users because they basically get removed right away before gaining any meaningful traction. When I noticed them I thought they are trolling because no one can assume such a large Sybil stays on the network for long, until I got email from them. Someone responded off-list to a short note I wrote to the tor-relays mailing list about this event. Apparently they were not amused by the removal of these exit relays (I do not claim any credit for their removal). It is likely that this is the same entity previously observed, because their limited vocabulary is consistent with earlier emails I got from “andrejgvozdev55@gmail.com”.

Countermeasures

My previous blog posts about malicious tor relay activities (1, 2) featured a section about proposals the Tor Project could implement to reduce the risks for Tor Browser users. That did not turn out to be fruitful. So after several attempts to convince them to improve the situation I’m going to take an another approach: Digital self-defense for tor users. This is a work in progress and my plan is to write about it in more detail in a future blog post but this section might provides some overview.

  • The scale of the detected attacks has never been as large as in 2021.
  • Non-central options should only be considered after trying (and failing) to achieve protections at the tor directory authority level because they will never reach all users.
  • Tor client configuration changes should generally be avoided to avoid splitting the anonymity set and only be used as an option of last resort (or as a method to vote with your feed as a tor user).
  • Non-default tor client configurations make network wide load balancing harder.
  • It requires more effort.

HTTPS-Only Browser Mode

The HTTPS-Only mode (which might land in Tor Browser based on Firefox 91 ESR) would be a strong protection, but there are still some uncertainties with that as well as a Tor Browser developer points out on a tor mailing list:

Solving the fake ContactInfo impersonation attacks

Problem: ContactInfo is an unverified arbitrarily spoofable string and malicious actors take advantage of that by using other peoples ContactInfos to hide their malicious relays — especially if their MyFamily configuration is not properly setup. This even goes as far as using names of (former) tor community people that do not even run exit relays.

Visualizing known and unknown exit fraction

Visualizations provide a good overview on what is going on on the tor network with regards to changes related to who controls what exit fraction for example. I use the following graph to get an idea on what is going on before proceeding with more specific investigations. It shows the aggregated exit probability from operators I classify as “somewhat known/non-malicious”.

Figure 14: Likely non-malicious exit fraction over time graph allows to draw indirect conclusions about (large scale) malicious activities. Graph by nusenu (raw data source: Tor Project/onionoo)
Figure 15: Contributed exit fraction by (non-spoofable) operator domain. Graph by nusenu

Summary

  • The entity attacking tor users, originally disclosed in August 2020, is actively exploiting tor users since over a year and expanded the scale of their attacks to a new record level (>27% of the tor network’s exit capacity has been under their control on 2021–02–02).
  • The average exit fraction this entity controlled was above 14% throughout the past 12 months (measured between 2020–04–24 and 2021–04–26).
  • The malicious actor actively reported non-malicious but poorly configured relays to the Tor Project’s bad-relays mailing list to find viable victims to use for operator impersonation attacks.
  • Most of the malicious tor exit capacity did not have any relay ContactInfo. Throughout the last 6 months the majority of tor exit capacity without ContactInfo was malicious.
  • The attacker primarily uses servers at the hoster OVH.
  • In early May 2021 the attacker attempted to add over 1 000 exit relays to the tor network.
  • The attacker (or one of them) likely uses the Russian language interface of gmail.com.
  • As of 2021–05–08 I estimate their exit fraction between 4-6% of the tor network’s exit capacity.
  • A new non-spoofable ContactInfo field for tor relays has been specified and has been adopted by over 20% of the network’s exit capacity so far.
  • OrNetStats has been extended to include two new graphs: exit fraction by non-spoofable ContactInfo domain and graphs showing exit fraction without ContactInfo

Additional Background / Disclosure

After publishing Part I in August 2020 I got email from the Tor Project in which they shared their concerns about me “leaking” information from the private bad-relays mailing list without their consent. While I agree that it is reasonable to expect some level of confidentiality after being invited to a non-public mailing list I questioned that my blog post did any damage to the goals of the bad-relays team. I have unsubscribed from the bad-relays mailing list as of 2021–01–01. It did not feel like being on that list allowed me to help reduce the risk for tor users and relevant discussions happen also elsewhere. Regardless of that I’ll continue to work towards a safer tor network.

Want to support this type of research?

I’m looking for a new maltego license (the previously donated license I got after publishing my previous blog post expired).

Appendix (bonus material)

Fake profiles for fake relays: relaystor.xyz

On 2021–02–13 and 2021–02–16 close to 100 relays joined the network. All of them had the domain https://relaystor.xyz in their ContactInfo field. They are not so relevant from an exit fraction point of view because they were not on the tor network for long but I still found them interesting because they made some effort to build some fake profiles:

  • (rudimentary) website
  • twitter profiles (created 2012 and 2014)
  • telegram channel
  • BTC donation address
Source: https://relaystor.xyz/about/ (archived version: https://web.archive.org/web/20210411231629/https://relaystor.xyz/about/ )
Source: https://twitter.com/temporaca86
Source: https://twitter.com/n64alys184
Source: https://unsplash.com/s/photos/man
Source: https://unsplash.com/s/photos/man
Donation bitcoin address shown on the rudimentary relaystor.xyz website. This address has 0 transactions: https://www.blockchain.com/btc/address/bc1qcatkzga54sz3eyzwlr4hzmtfd37rgpenqp62yz (source: https://relaystor.xyz/donate/)

Timeline for events related to andrejgvozdev55@gmail.com (not comprehensive)

  • 2020–09–03 Андрей Гвоздев andrejgvozdev55@gmail.com reports the undeclared relay group of CypherPunkLabs to the bad-relays mailing list. (10 days before that I did send an email to tor-relays about this — which might gave them this idea in the first place)
  • 2020–09–03 I responded by letting them know that the CypherPunkLabs relay group is on our radar and that we were in contact with them.
  • 2020–09–07 first malicious exit at SOFTplus Entwicklungen GmbH gets added (185.32.222.167) — no ContactInfo given. The abuse contact (RIPE database) later points to andrejgvozdev55@gmail.com
  • 2020–09–15 first RIPE DB entries related to andrejgvozdev55@gmail.com are created
  • 2020–09–21 andrejgvozdev55@gmail.com’s first mailing list posting on the tor-relays mailing list
  • 2020–09–26 impersonation: first malicious exit relays using CypherPunkLabs as contact appear (relay fingerprint: 1EC0CCAFA8ABD5470B062AF470EAC97DD069C655)
  • 2020–10–31 a large fraction of malicious exit relays get removed by tor directory authorities
  • 2020–11–06–2020–12–16: more tor exit relays get added in the two identified IP blocks located in AS51395 (Datasource AG) and at other known hosters (OVH, more OVH, 2)
  • 2020–12–31 a new relay using a previously confirmed and known malicious ContactInfo (“fbirelays@protonmail.com” — see Part I) appears on one of the known IP block in AS51395 (91.192.103.35) with abuse contact pointing to “andrejgvozdev55@gmail.com
  • 2021–01–16 ContactInfo (“fbirelays@protonmail.com”) and nickname is removed from that relay (using this known malicious ContactInfo was probably unintentional)
  • 2021–01–18 I reached out to andrejgvozdev55@gmail.com using a random email address, but they didn’t want to disclose which tor relays they run.
  • 2021–02–04 malicious tor exit relays removal event: at OVH (2, 3)
  • 2021–02–18 malicious tor exit relays removal event at multiple hosters (Amarutu Tech., OVH, Frantech, …)
  • 2021–02–22: 52 fake CypherpunkLabs exit relays get added again (tweet by CypherPunkLabs)
  • 2021–03–04 malicious tor exit relays removal event at OVH
  • 2021–03–14 malicious tor exit relays removal event: this is the last seen date for many malicious tor exit relays at AS51395, Datasource AG and a few other ASes (Amarutu Tech, Liteserver Holding, …).
  • 2021–04–08 23 new tor exit relays using contactInfo “andrejgvozdev55(at)gmail(dot)com [tor-relay.co]” join the tor network
  • 2021–04–10 previously identified malicious exit relays (reported to the Tor Project in August 2020) join the Tor network again. (removed on 2021–04–27)
  • 2021–04–12: Last seen date for the relays using contactInfo “andrejgvozdev55(at)gmail(dot)com [tor-relay.co]”;
    https://lists.torproject.org/pipermail/tor-relays/2021-April/019591.html

Appendix II

Timeseries graph showing the new malicious groups getting added immediately after a removal event, which makes them linkable. Graph by nusenu (raw data source: https://metrics.torproject.org/onionoo.html)
  • A: malicious exit group with contact “kleinendorstwiebe AT gmail DOT com” gets kicked→”cockcockcockcock(at)cock(dot)li” relays become exit relays (previously non-exits)
  • B: malicious exit group with contact “cockcockcockcock(at)cock(dot)li” gets kicked → “exit_abuse@posteo.net” relays get added
  • C: exit group with contact “BlackHatsMatter@protonmail.com” gets kicked→”hgonxhe51@gmail.com” relays get added

Appendix III

Emails from andrejgvozdev55@gmail.com on public Tor Project mailing lists:

--

--

Tor, Routing Security and DNS Privacy related Topics. https://nusenu.github.io

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
nusenu

nusenu

Tor, Routing Security and DNS Privacy related Topics. https://nusenu.github.io