README

   1 ===== End-to-end correlation for Tor connections using an active timing attack =====
   2
   3 This is a very simple implementation of an active timing attack on Tor. Please note that
   4 the Tor developers are aware of issues like this –
   5 https://blog.torproject.org/blog/one-cell-enough states:
   6
   7 > The Tor design doesn't try to protect against an attacker who can see
   8 > or measure both traffic going into the Tor network and also traffic
   9 > coming out of the Tor network.
  10 > [...]
  11 > The way we generally explain it is that Tor tries to protect against
  12 > traffic analysis, where an attacker tries to learn whom to investigate,
  13 > but Tor can't protect against traffic confirmation (also known as
  14 > end-to-end correlation), where an attacker tries to confirm a
  15 > hypothesis by monitoring the right locations in the network and then
  16 > doing the math.
  17
  18 That page also links to this really scary paper:
  19 <http://petworkshop.org/2007/papers/PET2007_preproc_Sampled_traffic.pdf>
  20
  21 So, this is a known problem, but I wanted to see how easy it really is to do this,
  22 and I wanted to try it myself, so I built a PoC.
  23
  24 The requirements are:
  25  - The user points his browser to an attacker's webserver and stays on that server
  26    long enough (a bit over 4 minutes in my implementation)
  27  - An attacker controls the webserver or the exit node (or something between them)
  28    (in my implementation, he controls the webserver)
  29  - An attacker can measure the internet traffic of all possible users
  30  - The attacking machines have their time synced over NTP or so
  31
  32 It is NOT required, however, that the webserver is run by the same attacker who also
  33 runs the passive traffic analysis near the users – they can be two distinct attackers
  34 who decide to collaborate after-the-fact. The webserver owner only needs to save the
  35 64-bit ID he generated, the traffic analysis attacker needs to save one bit every four
  36 seconds for every connection.
  37
  38 Also, it is NOT required that the victim's browser supports JavaScript or so. curl would
  39 already be sufficient.
  40
  41 In my implementation, the attacking server can encode 64 bits into a pattern
  42 of data bursts – simplified, a zero becomes "first data, then nothing" and a one
  43 becomes "first nothing, then data". The server then sends those data bursts back to
  44 the client.
  45 The attacker measures the traffic of all possible users and decodes every TCP data
  46 stream back into bits using the data burst encoding. Then, he scans all the decoded
  47 data for the bits he sent to the user to find out which user connected to his server
  48 through Tor.
  49 This is really just a simple one-day-project implementation without any sophisticated
  50 stuff that would probably improve the accuracy and speed a lot.
  51
  52
  53
  54 ===== USAGE =====
  55 My proof-of-concept code is at <http://git.thejh.net/?p=detour.git;a=tree>.
  56 It needs libpcap and works on Linux. It probably won't work on Windows.
  57
  58 You can download the code with "git clone git://thejh.net/detour.git".
  59
  60 Compile with "./compile.sh".
  61 On the server, run "./pulser". This will open an HTTP server on port 4422.
  62 On the monitoring device (just run it on your computer if you just want to
  63 test it for yourself), run "./pulserecord eth0" as root (replace eth0 with the
  64 right interface if it's wrong).
  65 Generate a new bit pattern with "./random_bits" (or anything else).
  66 In the victim browser that uses Tor, navigate to "http://<your server>/<random bits>".
  67 After the page has loaded in the victim browser, run
  68 "./pulsehunter <random bits> | sort -n | tail"
  69 (with the same bits you used in the browser) on the monitoring device. The number on
  70 the left side is how many bits matched, the TCP connection data (IPs and ports) is on
  71 the right side.
  72
  73
  74
  75 ===== TEST RESULTS =====
  76 So, with my PoC ready, I tried it on myself in three different scenarios:
  77
  78  - no other traffic over Tor
  79  - reading news articles over Tor
  80  - watching Youtube videos over Tor (with switching to another video after the first
  81    one had buffered completely)
  82
  83 Here are the results.
  84
  85
  86 --- DOING NOTHING ---
  87 $ ./random_bits
  88 1010101010110011101101110010110010011101000000000100101000100101
  89 $ sudo rm out/*
  90 $ sudo ./pulserecord eth0
  91 Device: eth0
  92 ^C$ ./pulsehunter 1010101010110011101101110010110010011101000000000100101000100101 | sort -n | tail
  93 [...]
  94 64      ***.***.***.***:59254 -> ***.***.***.***:443
  95 64      ***.***.***.***:443 -> ***.***.***.***:59254
  96
  97 => All 64 bits correct in both directions – that's a really solid hit.
  98
  99
 100
 101 --- READING NEWS ARTICLES ---
 102 $ ./random_bits
 103 1100001100001111110101110000101000111110001111010111110011011111
 104 $ sudo rm out/*
 105 $ sudo ./pulserecord eth0
 106 Device: eth0
 107 ^C$ ./pulsehunter 1100001100001111110101110000101000111110001111010111110011011111 | sort -n | tail
 108 [...]
 109 60      ***.***.***.***:443 -> ***.***.***.***:59254
 110 61      ***.***.***.***:59254 -> ***.***.***.***:443
 111
 112 60 bits for incoming Tor, 61 bits for outgoing Tor. How solid is that hit? Let's ask Wolfram Alpha:
 113
 114 http://www.wolframalpha.com/input/?i=p%3D0.5+n%3D64&a=*MC.p%3D0!.5+n%3D64-_*Formula.dflt-&a=FSelect_**BinomialProbabilities-.dflt-&f3=60&f=BinomialProbabilities.x_60&a=*FVarOpt.1-_***BinomialProbabilities.x--.***BinomialProbabilities.l-.*BinomialProbabilities.r---.*--
 115
 116 probability for 61 or more bits to appear at random: 2.331*10^-15
 117 Wolfram Alpha says there are roughly 1 200 000 000 personal computers on earth (as of 2011)
 118 1200000000*100*2.331*10^-15 = 0.00028
 119
 120 => Even if you're monitoring the internet use of every personal PC on earth and every one of those PCs
 121    is communicating over 100 connections at the time of interest, you're still usually not going to get
 122    any false positives. This is a solid hit.
 123
 124
 125
 126 --- YOUTUBE ---
 127 I watched youtube and switched to a new video when the first one finished buffering.
 128
 129 $ ./random_bits
 130 0101100100001100011011001001101101110000011110000011100011110000
 131 $ sudo rm out/*
 132 $ sudo ./pulserecord eth0
 133 Device: eth0
 134 ^C$ ./pulsehunter 0101100100001100011011001001101101110000011110000011100011110000 | sort -n | tail
 135 [...]
 136 41      ***.***.***.***:40307 -> ***.***.***.***:443
 137 43      ***.***.***.***:443 -> ***.***.***.***:40307
 138
 139 43 is incoming Tor, 41 is outgoing Tor
 140
 141 http://www.wolframalpha.com/input/?i=p%3D0.5+n%3D64&a=*MC.p%3D0!.5+n%3D64-_*Formula.dflt-&a=FSelect_**BinomialProbabilities-.dflt-&f3=42&f=BinomialProbabilities.x_42&a=*FVarOpt.1-_***BinomialProbabilities.x--.***BinomialProbabilities.l-.*BinomialProbabilities.r---.*--
 142
 143 0.4073% probability for 43 or more bits to appear at random
 144
 145 => Significant, but if you look at >100 connections, you might well get some false positives.