Lots of tor relays send out sequential IP IDs; please fix that!
Well, the subject line pretty much says it all: Lots of Tor relays send out globally sequential IP IDs, which, as far as I know, allows a remote party to measure how fast the relay is sending out IP packets with high precision, possibly making statistical attacks possible that could e.g. pinpoint the entry guard a user or hidden service uses. This is how you can test whether a given relay has this issue: $ sudo hping3 -r --syn -p 443 176.199.74.186 --count 10 HPING 176.199.74.186 (eth0 176.199.74.186): S set, 40 headers + 0 data bytes len=46 ip=176.199.74.186 ttl=116 DF id=3025 sport=443 flags=SA seq=0 win=8192 rtt=33.5 ms len=46 ip=176.199.74.186 ttl=116 DF id=+38 sport=443 flags=SA seq=1 win=8192 rtt=32.7 ms len=46 ip=176.199.74.186 ttl=116 DF id=+42 sport=443 flags=SA seq=2 win=8192 rtt=32.5 ms len=46 ip=176.199.74.186 ttl=116 DF id=+34 sport=443 flags=SA seq=3 win=8192 rtt=32.3 ms len=46 ip=176.199.74.186 ttl=116 DF id=+36 sport=443 flags=SA seq=4 win=8192 rtt=33.2 ms len=46 ip=176.199.74.186 ttl=116 DF id=+36 sport=443 flags=SA seq=5 win=8192 rtt=36.4 ms len=46 ip=176.199.74.186 ttl=116 DF id=+35 sport=443 flags=SA seq=6 win=8192 rtt=33.9 ms len=46 ip=176.199.74.186 ttl=116 DF id=+56 sport=443 flags=SA seq=7 win=8192 rtt=31.7 ms len=46 ip=176.199.74.186 ttl=116 DF id=+46 sport=443 flags=SA seq=8 win=8192 rtt=33.4 ms len=46 ip=176.199.74.186 ttl=116 DF id=+34 sport=443 flags=SA seq=9 win=8192 rtt=33.7 ms In the last example, you can see that the "id" field has increased by 30-50 every second. That's an issue: It should be one of: - always 0 - totally random It can also be that it increments by one every time; that probably means that the relay uses per-IP counters or so, and as far as I know, that should be fine. After a bit of testing, I think that this issue is present on a lot of Tor relay nodes. Here are the first few in the alphabet that look suspicious (didn't want to scan the whole Tor network): 0000MiddlemanWV 65.199.52.129 9029 21948 +1 +3 +1 +8 000AAA420 86.56.139.182 9001 14461 +177 +176 +168 +145 0urHomeOnNativeLand 64.231.156.165 443 18012 +4 +16 +11 +12 0x05942 178.77.69.130 443 8387 +5 +6 +7 +4 1234bubs 2.108.151.161 443 17042 +19 +23 +22 +18 1294538115 86.195.35.119 50501 31861 +104 +116 +68 +114 2mpdhack 98.216.168.108 80 41481 +194 +162 +213 +174 404server 119.30.250.67 6699 53620 +195 +5 +1 +3 4144414D 2.120.211.98 443 28587 +1 +1 +1 +1 594ec291a82938230 199.127.56.76 49152 20690 +861 +893 +328 +338 5979ft 97.122.184.135 443 15586 +1 +1 +1 +1 69m3x1xans 98.219.70.159 443 63 +320 +286 953 +286 6cody5 76.108.230.244 443 28107 +59 +57 +73 +71 8930 71.127.151.26 443 3119 +111 +83 +53 +59 8Mu 128.71.234.171 443 19080 +578 +570 +292 +699 Absolution 94.247.41.130 9001 34427 +842 +688 +684 +636 Ace 121.211.92.6 9001 21567 +1 +1 +1 +1 Achim 79.251.152.183 452 8925 +1 +1 +1 +1 admtg 94.73.222.62 443 3025 +441 +286 +318 +286 Aeroplan 46.72.45.143 9001 29676 +166 +184 +189 +169 AetherTor 71.135.40.76 443 13379 +4 +3 +3 +3 alakazam 74.52.112.2 443 30616 +221 +234 +210 +249 aldgate 93.130.179.10 443 10989 +2 +13 +20 +4 AlfredJKwak 87.212.11.165 9031 13676 +22 +14 +2 +8 aliceandbob 66.85.144.247 9001 2869 +20 +7 +23 +30 AllCowsEatGrass 173.48.97.207 443 30159 +404 +783 +616 +401 amercury 195.64.199.236 9001 26102 +1 +1 +3 +1 amercury 87.224.217.221 9001 7043 +26 +6 +15 +13 amercury 94.31.242.41 9001 27049 +41 +33 +88 +81 AmurTor23 2.93.161.46 9002 48802 +4 +115 +14 +34 anonion 86.160.123.126 443 34526 +79 +94 +111 +57 AnonMan 173.69.9.25 443 23551 +24 +33 +43 +51 anonymous 94.208.144.120 9001 24891 +391 +392 26027 +354 anonymous123 117.16.24.142 443 6806 +19 +40 +56 +19 AnonymousW 173.57.117.197 443 9862 +1 +1 +1 +1 AnonymTorProxy2 78.42.56.35 9002 6479 +246 +266 +258 +234 ApophisGER 176.198.48.99 555 6287 +1 +2 +2 +8 ArnoNym 178.142.2.45 443 21741 +83 +112 +57 +32 Arrowslash 90.1.117.14 443 1572 +90 +166 +4 +180 Arruffapopoli 84.223.102.90 4433 56233 +59 +60 +57 +54 AsCI 158.110.41.101 9002 53052 +1 +1 +1 +1 Please, everyone, check whether your Tor relay node behaves this way, and if so, either change the behavior or take it offline until you can fix the issue. Tor is not designed to be secure if an attacker can measure traffic at both ends of a circuit (for a proof of concept for that, see <http://seclists.org/fulldisclosure/2014/Mar/414>), and if your relay has this issue, you're already allowing anyone to measure at your relay.
Could you please translate your instructions into XP that I might check and, if necessary, fix my relay? (OnionTorte) Thanks, P Jann Horn wrote:
Well, the subject line pretty much says it all: Lots of Tor relays send out globally sequential IP IDs, which, as far as I know, allows a remote party to measure how fast the relay is sending out IP packets with high precision, possibly making statistical attacks possible that could e.g. pinpoint the entry guard a user or hidden service uses.
This is how you can test whether a given relay has this issue:
$ sudo hping3 -r --syn -p 443 176.199.74.186 --count 10 HPING 176.199.74.186 (eth0 176.199.74.186): S set, 40 headers + 0 data bytes len=46 ip=176.199.74.186 ttl=116 DF id=3025 sport=443 flags=SA seq=0 win=8192 rtt=33.5 ms len=46 ip=176.199.74.186 ttl=116 DF id=+38 sport=443 flags=SA seq=1 win=8192 rtt=32.7 ms len=46 ip=176.199.74.186 ttl=116 DF id=+42 sport=443 flags=SA seq=2 win=8192 rtt=32.5 ms len=46 ip=176.199.74.186 ttl=116 DF id=+34 sport=443 flags=SA seq=3 win=8192 rtt=32.3 ms len=46 ip=176.199.74.186 ttl=116 DF id=+36 sport=443 flags=SA seq=4 win=8192 rtt=33.2 ms len=46 ip=176.199.74.186 ttl=116 DF id=+36 sport=443 flags=SA seq=5 win=8192 rtt=36.4 ms len=46 ip=176.199.74.186 ttl=116 DF id=+35 sport=443 flags=SA seq=6 win=8192 rtt=33.9 ms len=46 ip=176.199.74.186 ttl=116 DF id=+56 sport=443 flags=SA seq=7 win=8192 rtt=31.7 ms len=46 ip=176.199.74.186 ttl=116 DF id=+46 sport=443 flags=SA seq=8 win=8192 rtt=33.4 ms len=46 ip=176.199.74.186 ttl=116 DF id=+34 sport=443 flags=SA seq=9 win=8192 rtt=33.7 ms
In the last example, you can see that the "id" field has increased by 30-50 every second. That's an issue: It should be one of:
- always 0 - totally random
It can also be that it increments by one every time; that probably means that the relay uses per-IP counters or so, and as far as I know, that should be fine.
After a bit of testing, I think that this issue is present on a lot of Tor relay nodes. Here are the first few in the alphabet that look suspicious (didn't want to scan the whole Tor network):
<snip>
Please, everyone, check whether your Tor relay node behaves this way, and if so, either change the behavior or take it offline until you can fix the issue.
Tor is not designed to be secure if an attacker can measure traffic at both ends of a circuit (for a proof of concept for that, see <http://seclists.org/fulldisclosure/2014/Mar/414>), and if your relay has this issue, you're already allowing anyone to measure at your relay.
------------------------------------------------------------------------
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Dirt kicked to the curb goes into the gutter. Professionals kicked to the curb go into retail.
On Mon, Mar 31, 2014 at 06:25:46PM -0400, Tor Relay wrote:
Could you please translate your instructions into XP that I might check and, if necessary, fix my relay? (OnionTorte)
If you don't have hping, you could also e.g. start a capture in wireshark or so, then connect to your host with telnet and send it some garbage. Like this: $ telnet 74.104.160.171 443 Trying 74.104.160.171... Connected to 74.104.160.171. Escape character is '^]'. a a a a Connection closed by foreign host. Then apply the filter "ip.src==74.104.160.171&&tcp" (replace with the values of your relay) in Wireshark and look at "Internet Protocol -> Identification" for the packets wireshark captured. Btw, it looks like your relay is affected. I do not know of any way to disable this behavior on Windows machines, but I'm also not very familiar with Windows.
On Mon, Mar 31, 2014 at 02:45:47PM -0800, I wrote:
How?
How to fix it, you mean? Good question. Probably depends on your OS. If your OS doesn't let you change it and you can't patch it, I'm afraid you'd have to use another OS (or a newer version of the one you're using). https://en.wikipedia.org/wiki/Idle_Scan says:
The latest versions of Linux, Solaris, OpenBSD, and Windows Vista are not suitable as zombie, since the IPID has been implemented with patches[4] that randomized the IP ID.[1]
Jann, I don't understand but I really want secure relays. All my relays are on VPSs running Debian 6/7 64 and I only know enough Linux to get Tor going. Is being updated enough? If not would you explain how to remedy the problem you've outlined as it seems quite serious? Robert
another OS (or a newer version of the one you're using).
https://en.wikipedia.org/wiki/Idle_Scan says:
The latest versions of Linux, Solaris, OpenBSD, and Windows Vista are not suitable as zombie, since the IPID has been implemented with patches[4] that randomized the IP ID.[1]
On Mon, Mar 31, 2014 at 04:34:20PM -0800, I wrote:
I don't understand but I really want secure relays. All my relays are on VPSs running Debian 6/7 64 and I only know enough Linux to get Tor going. Is being updated enough?
On Linux, that should be sufficient – looking at <https://bugzilla.redhat.com/show_bug.cgi?id=186057>, it seems that the last related issue on linux was fixed back in 2006. I scanned a good portion of all the tor exit nodes now, this is the distribution of operating systems for the suspicious-looking relays: 1 Linux 1 Windows 98 1 Windows Server 2003 Service Pack 2 [server] 1 Windows XP Service Pack 3 [workstation] 2 Windows 8 [server] 2 Windows Server 2003 3 FreeBSD amd64 3 Windows 7 Service Pack 1 [workstation] 5 Windows 8 5 Windows Vista [server] 14 Windows Server 2003 [server] 17 Windows Vista 33 Windows 7 [server] 37 FreeBSD 50 Windows XP 206 Windows 7 So, looks as if Windows and FreeBSD are the problems.
On Tue, 1 Apr 2014 02:56:38 +0200 Jann Horn <jann@thejh.net> wrote:
I scanned a good portion of all the tor exit nodes now, this is the distribution of operating systems for the suspicious-looking relays: ... So, looks as if Windows and FreeBSD are the problems.
Good catch. On FreeBSD this can be tuned via sysctl... sysctl -w net.inet.ip.random_id=1 ... and added to /etc/sysctl.conf so that the setting is not lost on next reboot. Default value for this tunable is 0.
On Mon, Mar 31, 2014 at 11:12:05PM +0200, Jann Horn wrote:
Well, the subject line pretty much says it all: Lots of Tor relays send out globally sequential IP IDs, which, as far as I know, allows a remote party to measure how fast the relay is sending out IP packets with high precision, possibly making statistical attacks possible that could e.g. pinpoint the entry guard a user or hidden service uses.
[Please don't cross-post on multiple lists -- you will splinter the responses.] For extra fun, check out this paper that turns this issue into a potential anonymity attack: http://freehaven.net/anonbib/#tcp-tor-pets12 Their suggestion for a fix iirc was that the Linux kernel should get fixed. --Roger
On Mon, Mar 31, 2014 at 11:12:05PM +0200, Jann Horn wrote:
Well, the subject line pretty much says it all: Lots of Tor relays send out globally sequential IP IDs, which, as far as I know, allows a remote party to measure how fast the relay is sending out IP packets with high precision, possibly making statistical attacks possible that could e.g. pinpoint the entry guard a user or hidden service uses.
Strike "possibly". I picked a random Tor relay from my "probably affected" list (Winston) and put "EntryNodes Winston" into the config of PC 1 (victim). Then I started "hping3 -r -i 2 -p 443 --syn 143.229.213.186" on PC 2 (attacker). While the hping process on PC 2 was running, I ran "torify curl http://var.thejh.net/trailer_400p.ogg" on PC 1 for a while, then canceled it. hping3 output before launching curl: len=44 ip=143.229.213.186 ttl=117 DF id=16154 sport=443 flags=SA seq=0 win=1460 rtt=95.7 ms len=44 ip=143.229.213.186 ttl=117 DF id=+33 sport=443 flags=SA seq=1 win=1460 rtt=95.7 ms len=44 ip=143.229.213.186 ttl=117 DF id=+20 sport=443 flags=SA seq=2 win=1460 rtt=95.1 ms len=44 ip=143.229.213.186 ttl=117 DF id=+30 sport=443 flags=SA seq=3 win=1460 rtt=95.6 ms len=44 ip=143.229.213.186 ttl=117 DF id=+49 sport=443 flags=SA seq=4 win=1460 rtt=96.3 ms len=44 ip=143.229.213.186 ttl=117 DF id=+22 sport=443 flags=SA seq=5 win=1460 rtt=96.4 ms len=44 ip=143.229.213.186 ttl=117 DF id=+10 sport=443 flags=SA seq=6 win=1460 rtt=95.8 ms hping3 output while curl is running: len=44 ip=143.229.213.186 ttl=117 DF id=+20 sport=443 flags=SA seq=7 win=1460 rtt=96.2 ms len=44 ip=143.229.213.186 ttl=117 DF id=+208 sport=443 flags=SA seq=8 win=1460 rtt=102.2 ms len=44 ip=143.229.213.186 ttl=117 DF id=+156 sport=443 flags=SA seq=9 win=1460 rtt=102.3 ms len=44 ip=143.229.213.186 ttl=117 DF id=+167 sport=443 flags=SA seq=10 win=1460 rtt=97.8 ms len=44 ip=143.229.213.186 ttl=117 DF id=+181 sport=443 flags=SA seq=11 win=1460 rtt=104.2 ms len=44 ip=143.229.213.186 ttl=117 DF id=+170 sport=443 flags=SA seq=12 win=1460 rtt=96.4 ms len=44 ip=143.229.213.186 ttl=117 DF id=+157 sport=443 flags=SA seq=13 win=1460 rtt=95.4 ms hping3 output after stopping curl: len=44 ip=143.229.213.186 ttl=117 DF id=+142 sport=443 flags=SA seq=14 win=1460 rtt=95.5 ms len=44 ip=143.229.213.186 ttl=117 DF id=+44 sport=443 flags=SA seq=15 win=1460 rtt=95.6 ms len=44 ip=143.229.213.186 ttl=117 DF id=+8 sport=443 flags=SA seq=16 win=1460 rtt=95.6 ms len=44 ip=143.229.213.186 ttl=117 DF id=+10 sport=443 flags=SA seq=17 win=1460 rtt=96.2 ms len=44 ip=143.229.213.186 ttl=117 DF id=+16 sport=443 flags=SA seq=18 win=1460 rtt=95.8 ms len=44 ip=143.229.213.186 ttl=117 DF id=+3 sport=443 flags=SA seq=19 win=1460 rtt=95.6 ms As you can see, the id field's values looked VERY different while PC 1 was downloading lots of data over the relay. Yes, true, it looks as if this node is relatively idle, and it's probably not THAT easy against relays that are used more. But I hope that this shows you that this is not just a theoretical attack.
participants (5)
-
Daniel Bilik -
I -
Jann Horn -
Roger Dingledine -
Tor Relay