Go to file
2025-05-28 14:26:14 +02:00
experiment-infra Move web to infra 2025-05-28 14:26:14 +02:00
architecture.svg updated architecture diagram to include the dummy guard 2025-05-23 14:58:20 +02:00
attack.svg added writeup on the experiment setup 2025-05-22 16:29:00 +02:00
README.md README.md aktualisiert 2025-05-28 14:00:05 +02:00

Revealing Guard Nodes via Traffic Induced Watermarking

Revealing the primary guard node used by a party within the TOR network can be a significant step in a deanononimization attack. This proposed attack attempts to detect the primary guard node of a client connecting to a malicious server through the TOR network. The attacker attempts to induce high traffic volumes on potential guard nodes to watermark traffic forwarded by them and then attempts to recognize these watermarks later in traffic received from the exit node.

Infrastructure

Name Datacenter IP
Guard #1 AMS2 95.85.53.75
Guard #2 AMS3 64.225.67.64
Caddy FRA 164.90.190.0
Host rsca-tor1
  Hostname 95.85.53.75
  User root

Host rsca-tor2
  Hostname 64.225.67.64
  User root

Host rsca-web
  Hostname 164.90.190.0
  User root

Experiment Setup

The first experiments purpose is to see, whether recognizable watermarks can be introduced into traffic just by controlling the load on the guard node. We deploy a network of one victim, one private guard node and one malicious server. The victim frequently (in 10 second intervals) accesses the server through the TOR network, using the private guard node as the first component of its circuit. In this first experiment, the guard node is known to the server, allowing us to test different mechanisms of introducing traffic patterns.

Network Structure Details

All parties in this experiment are part of one virtual private network 10.2.0.0/24. The network consists of three main components as well as an arbitrary number of members running experiments.

Victim

The victim's IP is 10.2.0.2. It constructs a circuit with the guard node 10.2.0.3 and two random TOR relays and then accesses the website rsca.vanrissenbeck.com every 10 seconds.

Guard Node

The guard node's IP is 10.2.0.3. It's used by the victim as well as by the attacker when attempting to increase the traffic load. The guard node is not publicly reachable by the TOR network.

Proxy

The proxy is the one publicly reachable component of this network. It has to be public, because otherwise the exit node which is not controlled by us wouldn't be able to reach the malicious service. Its internal IP is 10.2.0.4. Requests to rsca.vanrissenbeck.com are redirected by a caddy instance running in the Oracle cloud to port 8080. To test out a certain attack strategy, port 8080 of the proxy is further forwarded to a server hosting the actual malicious site. This allows researchers to spin up any kind of application serving the malicious website independent of the network infrastructure (see setup instructions below).

Setup Instructions

Experimenting with this network is rather simple: First, you'll have to become part of the 10.2.0.0/24 network. I'll send you a WireGuard config on request. To install WireGuard, run

sudo apt install wireguard-tools

or an equivalent command for your distro. Then install the configuration I've sent to you by running

# replace N with the lowest non-negative integer
# so that you don't overwrite existing configs
sudo cp wg-rsca.conf /etc/wireguard/wgN.conf

and finally boot up the VPN

sudo wg-quick up wgN

You can test the configuration by sending a ping to 10.2.0.1.

Next you'll have to develop some malicious HTTP service. For testing purposes, this could be an instance of python's http.server module. Run your service, e.g.

python3 -m http.server 1337

Finally, you'll make the service publicly available, by forwarding port 8080 of the proxy to port 1337 on your local device using ssh reverse port forwarding. This can be achieved by running

ssh -NR 8080:127.0.0.1:1337 anon@10.2.0.4

The password is rsca2025nA4g1A. Your malicious HTTP service should be publicly visible under the domain rsca.vanrissenbeck.com and receive requests by the victim through the TOR network about every 10 seconds. If you used the http.server example, a directory listing should be visible on that domain.

We Built This Circuit: Exploring Threat Vectors in Circuit Establishment in Tor

Point Break: A Study of Bandwidth Denial-of-Service Attacks against Tor

TagIt: Tagging Network Flows using Blind Fingerprints