Piotr Duszyński, a security consultant, recently revealed a method that could disclose a visitor’s real IP address despite traversing through the TOR network. This is a huge privacy issue; Tor was built with privacy in mind. There are environmental conditions that must be satisfied, however. Despite the inclusion of “Tor” in the headline, this threat expands past just using the Tor network. It’s also a great example on how threat actors can conduct nefarious actions using multi-staged attacks. Let’s discuss this in more detail.
The Specific Environmental Requirements and Discussion
At a very high level, these are the different conditions required to obtain one’s IP address through a Tor network channel:
- Use a standard web browser, not the Tor browser
- Control of a Tor exit node
- HTTP packet sniffing
- HTTP 301 cache poisoning
I want to look at each of these conditions independently and review them.
Standard Web Browser, not the Tor Browser
For starters, the vulnerability calls for using a standard web browser (e.g., Firefox, Chrome) and proxying into the Tor network via the SOCKS5 protocol. A potential victim would not be using the recommended Tor browser, which is highly ill-advised. Here’s some good reading about censuring the use of browsers apart from the Tor browser. Unless you’re very familiar with the intricacies of security, privacy, and network traffic, never access the Tor network without the Tor browser. Extending that, follow best practices when using this network but even more important, be ethical.
You can refer to a previous post about my experiences accessing the dark web and how I did so in a safe manner. Specifically, the first section “Setting the Stage” covers this a bit more. There are many other considerations that are beyond the scope of this post. As with any software, there are vulnerabilities in the TOR browser as well; this informative video provides various examples of ways identifiable information can be leaked.
Whoever Controls the Exit Node, Controls the Traffic Flow
Next off, and this is a huge concern in general to any Tor network user, an attacker must have control of a TOR exit node. A TOR exit node is basically the interface between the TOR network and the public Internet. To add some context, you can access websites on the Internet in a few ways. For the purposes of this explanation, I’ll cover two ways: one way is to simply pull up a web browser and type in the URL address or perform a Google search if you’re unsure of the domain name, and follow the links. Another way is via the TOR network, which adds a spin to how the former is done. Allow me to expand on these two methods a tad.
The first approach is the most common for typical usage. When you make a web request, a network packet goes from you to the destination and then back to you. The source and destination identifiers are known as IP addresses, which uniquely identify you on the public Internet. This is a simple, high-level overview of it; there is more to it than this as covered in this post.
Going through the TOR network, however, can be thought of as a chained-proxy connection from your computer, through other servers hosting TOR network relay services, then out through a final node (the exit node) that completes the connection to your desired website. This exit node is the interface for your network packet to travel between the TOR network and the final website, as well as its re-entry point to find its way back to you. Each of the hops in-between adds anonymity to the packet. There is more to this process – feel free to read my previous blog post or listen to this amazing podcast (and subscribe!) by WatchGuard’s Threat Lab team.
To be clear: the fact that a malicious threat actor may control an exit node is not a good thing – regardless if you’re using the TOR browser or proxying in, as in this case.
HTTP, Without the “S”
Moreover, there is a need to eavesdrop on our ever-loved HTTP traffic. Simply put, anything nowadays non-HTTPS is vulnerable to man-in-the-middle (MiTM) attacks and it makes me cringe. In HTTPS, the “S,” standing for secure, ensures you’re communicating with the expected recipient – granted they didn’t get hacked, of course! Further into the world of HTTPS, digital certificates are used to access websites. A hypothetical procedure on registering a domain name and proving you own it could be done by first registering a domain name, providing that domain name to a digital certificate company who supplies you with a certificate after validating your identity. This certificate is then used in secure connections to ensure visitors are actually communicating with your specified hostname.
Let’s suppose someone has infiltrated your network communications and is intercepting your communications. When you make a request over HTTP, the request goes through the attacker (MiTM) and then reaches the end point. Any data transmitted over HTTP is cleartext, meaning anyone with access to those packets can read what they contain. Worse still, the returned responses can be manipulated by the attacker as well to display what the attacker chooses. There are legitimate uses for this, such as debugging for web developers. Read more about that here.
On the flip side, when you access a website over HTTPS, you’re essentially reaching out to the domain name and it responds with its digital certificate stating, “hey, I am website example.com.” As long as the certificate checks out, and by that I mean that the certificate’s chain-of-trust is legitimate, then that site went through the hoops to validate itself. A key perk to using certificates is that if something’s off, your web browser triggers red flags. One such (legitimate) flag is a self-signed certificate warning. This is where a server creates its own digital certificate as opposed to going to a Certificate Authority, a reputable entity that’s entrusted with validating companies and providing digital certificates. Your web browser will request a site’s certificate, but a warning will be displayed instead mentioning it’s self-signed and not from a trusted source. One would use a self-signed certificate if they do application development or host services for themselves on HTTPS-capable web servers, or if their friends, whom they know and trust, hosted those services. Bypassing self-signed browser warning displays is fine in these cases.
Completing the Threat
Okay, so far each of the requirements were explained a bit more to understand what’s really going on. Now in order to complete this process, I want to reiterate that this vulnerability revolves around accessing a non-HTTPS website, over the TOR network, while the attacker controls the exit node, thus allowing for (drum roll: this is the icing on the cake) the attacker to inject malicious HTTP 301 redirects into the destination server’s responses back to the user. These redirects are then cached, so stored locally on your computer.
When a user requests that same page sometime in the future, after exiting the TOR network, there will be a malicious redirect to an attacker-controlled server that was created specifically for that user. Therefore, that server will be able to gather your IP address, amongst other bits of information, and made available to the actor controlling that server.
Conclusion and Takeaways
I want to start with the takeaways and then shift to wrapping up this post.
By no means am I downplaying the potential severity of this situation. There are legitimate sites that still use HTTP. Why, I am not sure, but they still exist. A major takeaway here would be to avoid having to log in to websites using HTTP. If you insist, using a different email address and password combo is strongly advised.
Using Tor can add a perceived sense of protection, and it does for the most part. However, when it comes to the requirement of a malicious actor controlling the exit node, this essentially breaks Tor’s purpose in general. As for this point’s takeaway, how the exit node is programmed and packaged up is the responsibility of the Tor Project entity. Unfortunately, not even they can control what an inspired threat actor may manipulate on their own servers. Think of this role as an honor system approach, participating relays are expected to be honorable and offer integrity – we should all know that’s simply infeasible, however.
Alone, the two above viewpoints spells trouble. The same thing could really be applied outside of Tor as well, perhaps for threat actors hosting VPN or proxy services. When it comes to services like this, how do you really go about ensuring no foul play; e.g., how do you know services aren’t logging your true IP address, and how can you be sure they’re not tracking you other ways?
When we throw in that last step, this is where a strong emphasis on using the Tor Browser comes in. JavaScript, cookies and cache, and running plug-ins – they all play a role in cyber security. That said, the Tor Browser is said to take care of all the thinking for you. The takeaway here would be to disable JavaScript, delete cookies and cache upon closing a web browser, and closing then reopening it to ensure no static remnants from the previous session exists – or simply just use Tor in the first place. You can even take this further and consider operating system-level anonymity. Two options are Whonix and Tails.
For some final words, I want to clarify that there are many, many factors to consider in any exploit. Knowing them all, and each factor’s intricacies, is not feasible. That said, no matter what you do, know that there may be a way to exploit most anything via unknown (or known and hidden) software vulnerabilities – zero day malware or multi-staged attacks are examples. There are some determined people out there. Be considerate in your conduct and seek to make the most of the available protective measures.