Published on Sep 03, 2023
We present a moderately simple to implement but very effective and silent deanonymization scheme for Tor traffic. This is done by bridging the mixes in Tor, that is, we control both the traffic leaving the Onion Proxy (OP) and the traffic entering the Exit node. Specifically, from a user’s viewpoint, our proposal has been implemented in the popular Android platform as a spyware, having the dual aim to manipulate user traffic before it enters the Tor overlay and explicitly instruct OP to choose an exit node that is controlled by the attacker.
When the user traffic is received by the rogue exit node it is filtered, and the sender’s IP details become visible. Notably, apart from deobfuscating normal http traffic, say, send via the Tor browser, the proposed scheme is able to manipulate https requests as well.
Internet was not created and designed with anonymity in mind [1]. So, normally, if two parties want to communicate it is mandatory to provide their routable source IP addresses to each other. This situation however is subject to traffic analysis by potential eavesdroppers. Typically, disclosure of IP address is necessary across all applications communicating over IP protocol, however most of the well-established network security protocols fail to provide full anonymity. For instance, Transport Layer Security (TLS) succeeds in perfectly encrypting and authenticating packet contents, but fails to protect the identities of the involved parties. On the other hand, IPsec achieves to protect the anonymity of the communicating parties, but this stands true only when used in ESP/Tunnel mode and only for data traveling between the two ends of the tunnel. That is, the links between the sender and the one end of the tunnel, and between the other end of the tunnel and the final destination do not afford protection from traffic analysis. However, to fully block traffic analysis, one needs a solution which will provide anonymity in a cross-layer fashion.
One of the most prominent anonymization systems today is the Onion Router network (TOR) [2], which consists of a group of volunteer-operated servers, each of them working as a proxy. Its main purpose is to allow individuals to protect their anonymity, by means of deterring traffic analysis. In fact, Tor is an overlay network that among others can be used as a censorship circumvention tool. Namely, Tor is particularly useful to certain parties, including journalists trying to communicate safely with whistle-blowers or dissidents, activist groups that endorse maintaining civil liberties online, and people living in countries with restricted freedom of information and access to websites [3]. On the other hand, Tor can also be used for malicious purposes.
Apart from using Tor with the aim of obfuscating the forensic signal behind attacks like Denial of Service (DoS), aggressors employ Tor’s capability to build the so-called hidden services to accomplish illegal or malicious actions, such as drug dealing or illegal gun trafficking. This has spurred research on methods to deanonymize Tor traffic. Usually, such deanonymization schemes focus on the exploitation of the Exit node. Nevertheless, better results can be achieved if traffic analysis performed at the exit node is bridged with either the Entry node or an even precedent point of entry, namely before the outgoing data reach the Onion Proxy (OP).
In this paper, we present a new stealthy way of instantly deanonymizing specific or random Tor users. Specifically, the proposed attack relies on (a) a user-side spyware called SnoopyBot we specifically created for the Android platform, and (b) on the very plausible assumption that the attacker is in control of at least one Tor Exit node. Precisely, among others, SnoopyBot’s main purpose is to inject user-identifying information in every request the infected user channels through the Tor network. In this way, when the rogue Exit node receives the corresponding request, the sender’s true identity in terms of their public IP address will be revealed. Putting it another way, by controlling both ends of the circuit, SnoopyBot achieves to bridge the mixes in Tor. This also means that the assault does not capitalize on an inherent Tor vulnerability, but entirely on the ability of the attacker to control the two ends of the Tor circuit
Today, Tor is probably the most popular open source implementation of a distributed overlay network which aims to anonymize TCP-based traffic. The Tor software installed on the client device, namely Onion Proxy (OP), chooses a random path through the available Onion Routers (OR) in the network and constructs a circuit, in which each OR in the path knows only its predecessor and successor, but no other nodes. After that, the user’s traffic flows down the selected circuit using onion routing which is based on layered encryption. To further impede the analysis of data streams based on traffic characteristics, Tor overlay uses cells of fixed size to communicate its users’ data among the different ORs.
Overall, this approach blocks traffic analysis because no single entity is aware of the full path a packet has traveled. A Tor user, say, Alice needs to have locally installed the Tor software, which in a desktop environment is the Tor browser. In Android environment, Tor software is provided by means of two separate apps, namely, Orbot [4] and Orweb [5]. Any mobile browser that offers http proxy support can also be used with Orbot if properly configured, but Orweb is configured out-of-the-box. Orbot is used to create an OP and construct a circuit to realize the anonymization of client data into the Tor overlay.
The necessary information for the available ORs is obtained from the Tor’s Directory Server. The ORs are proxies that relay data between the two endpoints, Alice and the actual destination, say, a web server. Each OR maintains a TLS connection to other ORs in the constructed circuit. By default a Tor circuit consists of three ORs known as Entry/Guard Node, Relay Node, and Exit Node. Typically, to construct a circuit, Alice’s OP chooses three ORs and starts negotiating a symmetric key with each one of them by means of Diffie- Hellman handshakes. After the circuit is ready, a service, e.g., web browsing, is achieved when Alice’s browser establishes a TCP connection with the corresponding web server.
To avoid DNS resolution queries (which may reveal information about Alice’s identity) sent directly by the web browser over the Internet, Alice’s OP uses an HTTP proxy so that her traffic can be diverted through Tor. Therefore, in a properly configured Tor installation, the exit node is responsible to make DNS resolution of, say, the user’s http requests.
At a high level, assuming an http or https connection, SnoopyBot has three main goals. First, it modifies the default settings of any Tor application running on the smart device and are necessary to access Tor network. As already pointed out, these applications are, Orbot and Orweb. Second, it obtains the public IP of the user, and third, it hijacks (acting as a man-inthe- middle) the connection in order to inject user’s personal information to the requested URL. SnoopyBot is designed to instantly launch right after its installation, as well as after every reboot of the smart device.
Upon its successful installation, SnoopyBot masquerades itself as Adobe Flash v2.0, which is a well-known software and will normally present itself as a benign application to the owner of the smart device. Also, it removes any application (SuperSU, Superuser) that gives root permissions to the user, including pop-up permission request dialogs. Pop-up dialogs are shown to the user with the use of toast messages, every time an application requests root permissions. This kind of action can attract the victim’s attention, and such a suspicion could eventually lead to have SnoopyBot uninstalled. In addition, we particularly concentrated on the stealthy operation of SnoopyBot to make harder its detection by anti-spyware software.
Towards this goal, we minimized the number of connections SnoopyBot makes outside the Tor network. More specifically, SnoopyBot generates only one request to a public web service, to obtain the user’s public IP, while the rest of the communication remains within the Tor network. Naturally, every time the IP of the user changes the same request must be repeated. As already pointed out, the spyware needs to modify Tor settings at the client side. Figure 1A depicts a typical http or https GET transaction when processed by Tor at the client side. The spyware invades this procedure and modifies Orbot configuration settings inside the torrc file, to always use the attacker’s exit node during the creation of any Tor circuit.
After that, it prohibits any further modifications to torrc. It is to be noted that Orbot consists of two main components. The Polipo [7] http proxy that listens on port 8118, and Privoxy SOCKS proxy [8] that listens on port 9050. Essentially, Polipo forwards the http traffic to Privoxy, which subsequently forwards the traffic to Tor. Additionally, as depicted in fig. 1B, SnoopyBot changes the http proxy settings of Orweb to point to destination port 8119 instead of the default 8118. This forces all victim traffic to be proxied through the SnoopyBot HTTP proxy. After manipulating the GET request, SnoopyBot will forward it to HTTP port 8118 as normal, which is Orbot’s HTTP Port.
Putting it another way, SnoopyBot HTTP proxy acts as a man-in-the-middle between Orweb and Orbot, thus it is able to sniff and modify any data passing through this link. After that, SnoopyBot triggers a connection to a public service (e.g., www.myip.com) to get the public IP of the user (victim). Since this is the only outbound connection made by the spyware, its footprint on the system is minimal. Having the public IP of the victim, the SnoopyBot proxy injects it along with a certain identification string (i.e., SnoopyBot’s signature) into all URLs requested by the victim.
For the exit node, we used the official Tor software on a Linux Ubuntu server, and configured the torrc file so as for our server to be able to operate as a trusted Exit node. In particular, we configured the torrc file in the Exit node to route HTTP and HTTPS traffic (ExitPolicy accept *:80 and ExitPolicy accept *:443). We also adjusted the amount of bandwidth that will be made available to Tor and finally provided a name for the Exit node. Moreover, a Python HTTP proxy was implemented. This proxy listens on a different port on the same box as Tor and eavesdrops on incoming traffic. By using iptables we redirected all the incoming traffic with destination port 80 or 8080 (http-alt) to our HTTP proxy.
Upon the reception of any http request that carries one of the SnoopyBot’s signatures, the HTTP proxy logs it, strips the signature from the request, and forwards the request to its destination, say, a webserver as normal. An exception to this rule is any incoming bogus http request which is blocked in order for the destination not to receive an extra http request corresponding to the original https one. As explained in section III.B, all bogus http requests carry a special SnoopyBot’s signature. The HTTP response from the webserver is forwarded to the Tor network with no further manipulation.
SnoopyBot needs to somehow infect and spread amongst users. One way to do so is to bundle the spyware apk setup file with another apk, belonging to an app that requires root permissions during installation. The latter apk may belong to a legitimate app that the user would download from an alternative Android app market. Using this method, during apk installation, the root permissions that the legitimate app would ask from the user for performing its tasks would also be given to the spyware after installation. A second way of spreading SnoopyBot is to make an on-the-fly bundle and injection of the spyware when a user makes a request to our Exit node for an .apk download. This method however, increases the chances of the malevolent Exit node to be detected by Tor. It is also implied that the infection of specific users is considered more difficult than spreading SnoopyBot among the public at large.
Currently, SnoopyBot works only with Orweb. However, there are several other web browsers that can be used in cooperation with Orbot, and thus SnoopyBot needs to be modified to co-work with each one of them.
The user’s smart device must be rooted. This condition is necessary for the spyware to perform its actions.
Tor’s major weakness is the Exit node of each circuit, as all traffic that passes through this node is potentially unprotected. This shortcoming attracted several researchers to develop methods of tracking and avoiding malicious Exit nodes. However, as with SnoopyBot, this is hard to achieve in cases where the Exit node just silently logs the traffic passing via it, leaving no other trace of its privacy-invasive activity. In this case, countermeasures need to be taken on the client side as well. For instance, the apps that provide access to Tor, like Orbot or Orweb, must encrypt their settings or use a secure database for storing them. In any case, however, the root cause of the Exit node’s problem is not due to the internal workings of Tor, but to end-users not employing https connections or other means of protection at the application layer. This problem is even aggravated by badly configured web browsers or other applications and the rise of privacyinvasive software as in our case.
Moreover, one of the most prominent security issues that can occur during Tor installation on, say, a smartphone is the root permissions Tor requires to anonymize outgoing traffic stemming from any application other than Tor’s official browser. This requirement leads many users to root their smart device, which, as a direct consequence gives the ability to any malicious application to gain access to critical files on the Android system.
[1] G. Kambourakis, “Anonymity and closely related terms in the cyberspace: An analysis by example,” Journal of information security and applications, vol. 19, no. 1, pp. 2–17, 2014.
[2] R. Dingledine, N. Mathewson, and P. Syverson, “Tor: The secondgeneration onion router,” in Proceedings of the 13th Conference on USENIX Security Symposium - Volume 13, ser. SSYM’04. Berkeley, CA, USA: USENIX Association, 2004, pp. 21–21. [Online]. Available at: http://dl.acm.org/citation.cfm?id=1251375.1251396
[3] G. Karopoulos, A. Fakis, and G. Kambourakis, “Complete sip message obfuscation: Privasip over tor,” in Availability, Reliability and Security (ARES), 2014 Ninth International Conference on. IEEE, 2014, pp. 217–226.
[4] Guardian-Project. Orbot: Tor for android. [Online]. Available at: https://guardianproject.info/apps/orbot/
[5] Guardian-Project. Orweb: Private web browser. [Online]. Available at: https://guardianproject.info/apps/orweb/
