Identification of real IP addresses of users of the Tor network through a distorted cache

This article describes an example of the practical application of the “cache distortion through 301 redirect” attack, which can be used by the output node of the Tor network with malicious code to identify the real IP addresses of selected users.

Attack scenario

The attack scenario is as follows:

• Client: Chrome Canary (76.0.3796.0)
• Real client IP: 5.60.164.177
• Customer Tracking Parameter: 6b48c94a-cf58-452c-bc50-96bace981b27
• IP address of the output node of the Tor network: 51.38.150.126
• Transparent Reverse Proxy: tor.modlishka.io (Modlishka - updated code to be released.)

Note: In this scenario, the Chrome browser was configured through the SOCKS5 network protocol to use the Tor network. The Tor channel has been tuned to a specific test output node: '51 .38.150.126 '. This is also a check of the correctness of the concept and many settings can be optimized in the future ...

In the case of a malicious output node of the Tor network, all traffic is redirected through the Modlishka proxy server:

iptables -A OUTPUT -p tcp -m tcp --dport 80 -j DNAT --to-destination ip_address:80
iptables -A FORWARD -j ACCEPT

Attack scenario description

Assumptions:

• A browser application (in this case, a standard browser) that will use the “Tor” network connection and, finally, the connection will go through a malicious output node.
• The malicious output node of the Tor network, which intercepts and distorts the cache of all HTTP traffic (response code “HTTP 301”), which does not have a transport layer security cryptographic protocol (“TLS”).

Let's look at the following steps of an attack scenario:

1. The user connects to the Internet through the Tor network by configuring the browser to use the SOCKS5 network protocol of the Tor system, or by configuring so that all traffic of the operating system is redirected through the Tor network.
2. The user begins his normal Internet access session with his favorite browser, where usually a lot of HTTP traffic without the TLS security protocol is sent through the tunnel of the Tor network.
3. The malicious output node of the Tor network intercepts requests and responds by forwarding each using the HTTP 301 response code. These redirects will be constantly cached by the browser and will be sent to the tracking URL with the assigned Tor client identifier. The tracking URL can be created in the following way: user-identifier.evil.tld, where 'evil.tld' will collect all information about the source IP address and redirect users to the originally requested hosts ... or, alternatively, to a transparent reverse proxy server, which will try to intercept all subsequent stream of HTTP client traffic. In addition, since it is possible to automatically distort the cache for most of the most popular domains (as described in a previous article), e.g. top 100 sites according to the statistics of the company «Alexa», the attacker maximizes his chances of identifying real IP addresses.
4. After exiting the Tor network session, the user will switch to their regular network.
5. As soon as the user enters the address of one of the previous distorted domains into the address bar (for example, “google.com”), the browser uses the cache for internal redirection to the tracking URL with the context identifier of the output node.
6. The output host will be able to match the previously intercepted HTTP request with the user's real IP address using information received from an external host that used the tracking URL with the user ID. The evil.tld host will have information about all the IP addresses that were used to access the tracking URL.

Obviously, this method allows you to efficiently match selected HTTP requests with client IP addresses using the output node of the Tor network. This happens because the previously generated tracking URL will be requested by the client through the “Tor” network tunnel, and then again, as soon as the connection is made through the standard connection of the Internet provider. It’s all because of the garbled code in the cache.

Another approach may be based on the introduction of modified JavaScript code with embedded URLs for tracking in the corresponding responses that do not have the TLS security protocol, and changing the necessary control cache headers (e.g. 'Cache-Control: max-age = 31536000') . However, this approach is not very effective.

Tracking users through the standard cookies of various web applications is also possible, but it’s very difficult to force the client to visit the domain that is under the control of the attacker twice: first, when connecting through the output node of the Tor network, and then again after switching to the standard Internet connection provider.

conclusions

The fact is that an attacker has the ability to achieve certain changes in the browser cache by injecting malformed code through malicious output nodes and detecting the real IP addresses of Tor users who send HTTP traffic without the TLS security protocol.

In addition, the distortion of a significant number of popular domain names will increase the likelihood of receiving a reverse response of an HTTP request (with a user ID assigned), which will determine the real IP address of the user. You can try to intercept the domain from some browser clients and hope that a typo in the domain name will not be noticed by the user or it will not be displayed (for example, the “WebViews” mobile application).

Ways to reduce risk:

• When connecting to the Internet through the Tor network, make sure that all traffic that does not use the TLS security protocol is disabled. An example of browser plugins that can be used: for Firefox ”and“ Chrome ”browsers.
• In addition, always use the “private” browser mode when connecting to the Internet through the Tor network.
• Do not redirect traffic to your entire operating system through the Tor network until you are sure that all outgoing traffic uses the TLS security protocol ...
• Whenever possible, use the latest version of the Tor browser to browse the web.

---

The latest dual-processor configurations of dedicated servers with 2019 Intel Scalable processors are available on DEDIC.SH :

• 2x Xeon Silver 4214 - a total of 24 cores
• 2x Xeon Gold 5218 - a total of 32 cores
• 2x Xeon Gold 6240 - configuration with 36 cores.

The cost of a server with two Xeon Silver 4214 - from 15210 rubles / month
. We are also ready to collect any configuration for you - write to us !

If large powers of a dedicated server are not required - VDS from 150 rubles / month is what you need!