131 lines
4.4 KiB
Markdown
131 lines
4.4 KiB
Markdown
# 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](https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9581198)
|
|
|
|
[Point Break: A Study of Bandwidth Denial-of-Service Attacks against Tor](https://www.usenix.org/system/files/sec19-jansen.pdf)
|
|
|
|
[TagIt: Tagging Network Flows using Blind Fingerprints](https://petsymposium.org/popets/2017/popets-2017-0050.pdf) |