experiment-infra | ||
architecture.svg | ||
attack.svg | ||
README.md |
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.
Some Related Work
We Built This Circuit: Exploring Threat Vectors in Circuit Establishment in Tor
Point Break: A Study of Bandwidth Denial-of-Service Attacks against Tor