Mixing Up The Tor Network

I may be wrong, but if the Internet was created again, it would be build with embedded security, and not require security tunnels. And the…
Photo by Artem Bryzgalov on Unsplash

Mixing Up The Tor Network

I may be wrong, but if the Internet was created again, it would be built with embedded security, and not require secure tunnels. And the Tor network would — possibly — showcase a secure infrastructure, and where each node along a route adds their own encryption key, and cannot see any of data in the traffic. With this, each node creates an encryption key, and then when Bob sends data to Alice, he encrypts with all of the keys of the nodes. Each node then takes off its layer of encryption by decrypting with its own key [background]:

But, there’s a weakness: the exit node, as the traffic is only encrypted with the key that the exit node knows, and can thus examine the traffic flow.

Overall, this is still likely to be SSL tunnel, but the exit node can reveal the destination of the traffic. A malicious exit node could also perform a person-in-the-middle attack, and where they could try and degrade the connection so that it does not use an encrypted tunnel.

Recent attack

And this threat has become real, and where a threat actor has managed to place exit nodes onto the Tor network and then undertaken SSL stripping attacks for cryptocurrency accesses. Overall, SSL stripping involves creating a person-in-the-middle and aims to downgrade the HTTPs connection to an HTTP one. This allows the threat actor to change Bitcoin addresses within the traffic destinated for Bitcoin mixer sites — and which split Bitcoin transfers into smaller parts, and then which are compiled back to a target address. The attack occurs because the user may not add “https://” at the start of a URL, and thus there is a HTTP-to-HTTPs redirect applied. The malicious node removes this redirect, and downgrades to HTTP, without the user seeing a certificate error. Enhanced server options can be applied to overcome this threat, including HSTS Preloading and HTTPS Everywhere.

It is thought, that the threat actor may have amassed around one-quarter of all the Tor exit relays (around 380 (23.95%) on 22 May 2020). Once this was detected the Tor administrators have been removing these nodes. The following shows the addition of known malicious exit nodes:

Figure 1: nusenu (raw data source: https://metrics.torproject.org/onionoo.html)

When setting up an exit node the contact name of the administrator needs to be given, and in this case common email providers of Hotmail, Protonmail and Gmail have been used:

Join Timestamp, Removal Timestamp,ContactInfo
2020-01-27 21:00:00,2020-05-22 00:00:00,[email protected]
2020-01-29 20:00:00,2020-06-22 00:00:00,[email protected]
2020-02-29 03:00:00,2020-06-21 23:00:00,[email protected]
2020-03-16 05:00:00,2020-05-22 00:00:00,[email protected]
2020-03-21 13:00:00,2020-06-15 23:00:00,[email protected]
2020-05-04 02:00:00,2020-06-21 23:00:00,[email protected]
2020-05-25 08:00:00,2020-06-21 23:00:00, [email protected]
2020-05-28 19:00:00,2020-06-21 23:00:00,[email protected]
2020-06-02 08:00:00,2020-06-21 23:00:00,[email protected]

In terms of the hosting provider for the malicious exit nodes, OVH was mainly used — and which is one of the most popular networks for hosting Tor relays. An amusing one is “fbirelays”, and which is not thought to be run by the FBI [here]:

Conclusions

Where’s there’s profit, you will find threat actors with time, knowledge and resources. Like it or not, we are basically still running the same old Internet that was created in the 1980s, and as long as there’s a weak part of the chain, it exposes great threats to our future.