Topology

The topology is very simple, as is demonstrated in the image below. In my test simulation, I have one http client, 1 Tor proxy, 3 Tor routers, one Tor exit router and a http server.

The real Tor implementation runs as a SOCKS proxy, typically on the local machine. This means that data leaving the client machine is encrypted and divided into 512 byte Tor cells before any attacker can view it. In the image above, the proxy is a seperate entity. This was the easiest way to implement it using the SSFNet simulation software. For my purposes it is essentially the same, I merely put my ‘tap’ on the link from the Tor proxy to the first Tor router. I also ‘tap’ the connection between the http server and the last Tor router, or exit router.
This is one of many attacks surmised against Tor, basicly treating the Tor network as a blackbox and analysing traffic streams  entering and leaving the network.The traffic streams should have the same ‘fingerprint’ throughout the network, thus identifying them a trivial task.

The below is a tcpdump output from the tor proxy interspersed with tcpdump from the http server:

00:00:01.000132 0.0.0.9.10001 > 0.0.0.10.1070: S 0:0(0) win 0
00:00:01.000132 0.0.0.10.1070 > 0.0.0.9.10001: S 0:0(0) ack 1 win 16384
00:00:01.000396 0.0.0.9.10001 > 0.0.0.10.1070: . ack 1 win 16384
00:00:01.000396 0.0.0.10.10001 > 0.0.0.3.1080: S 0:0(0) win 0
00:00:01.001072 0.0.0.3.1080 > 0.0.0.10.10001: S 0:0(0) ack 1 win 16384
00:00:01.001072 0.0.0.10.10001 > 0.0.0.3.1080: . ack 1 win 16384
1) 00:00:01.001072 0.0.0.10.10001 > 0.0.0.3.1080: . 1:513(512) ack 1 win 16384
00:00:01.001228 0.0.0.9.10001 > 0.0.0.10.1070: . 1:1001(1000) ack 1 win 16384
00:00:01.001228 0.0.0.10.1070 > 0.0.0.9.10001: . ack 1001 win 16384
1) 00:00:01.002764 0.0.0.3.1080 > 0.0.0.10.10001: . 1:513(512) ack 513 win 15872
00:00:01.002764 0.0.0.10.10001 > 0.0.0.3.1080: . ack 513 win 16384
2) 00:00:01.002764 0.0.0.10.10001 > 0.0.0.3.1080: . 513:1025(512) ack 513 win 16384
00:00:01.003996 0.0.0.3.1080 > 0.0.0.10.10001: . ack 1025 win 16384
2) 00:00:01.005867 0.0.0.3.1080 > 0.0.0.10.10001: . 513:1025(512) ack 1025 win 16384
3) [..]1.005867 0.0.0.10.10001 > 0.0.0.3.1080: . 1025:1537(512) ack 1025 win 15872
00:00:01.007036 0.0.0.3.1080 > 0.0.0.10.10001: . ack 1537 win 16384
3) [..]1.010053 0.0.0.3.1080 > 0.0.0.10.10001: . 1025:1537(512) ack 1537 win 16384
4) [..]1.010053 0.0.0.10.10001 > 0.0.0.3.1080: . 1537:2049(512) ack 1537 win 15872
00:00:01.011222 0.0.0.3.1080 > 0.0.0.10.10001: . ack 2049 win 16384
4) [..]01.015323 0.0.0.3.1080 > 0.0.0.10.10001: . 1537:2049(512) ack 2049 win 16384
5) [..]01.015323 0.0.0.10.10001 > 0.0.0.3.1080: . 2049:2561(512) ack 2049 win 15872
00:00:01.016491 0.0.0.3.1080 > 0.0.0.10.10001: . ack 2561 win 16384

00:00:01.017942 0.0.0.5.10001 > 0.0.0.1.80: S 0:0(0) win 0
00:00:01.017942 0.0.0.1.80 > 0.0.0.5.10001: S 0:0(0) ack 1 win 16384
00:00:01.018177 0.0.0.5.10001 > 0.0.0.1.80: . ack 1 win 16384

5) [..]01.020531 0.0.0.3.1080 > 0.0.0.10.10001: . 2049:2561(512) ack 2561 win 16384
00:00:01.020531 0.0.0.10.10001 > 0.0.0.3.1080: . 2561:3073(512) ack 2561 win 15872
00:00:01.0217 0.0.0.3.1080 > 0.0.0.10.10001: . ack 3073 win 16384
00:00:01.0217 0.0.0.10.10001 > 0.0.0.3.1080: . 3073:3585(512) ack 2561 win 16384
00:00:01.02331 0.0.0.3.1080 > 0.0.0.10.10001: . ack 3585 win 16384

00:00:01.026434 0.0.0.5.10001 > 0.0.0.1.80: . 1:1001(1000) ack 1 win 16384
00:00:01.026434 0.0.0.1.80 > 0.0.0.5.10001: . 1:1001(1000) ack 1001 win 15384
00:00:01.026749 0.0.0.5.10001 > 0.0.0.1.80: . ack 1001 win 16384
00:00:01.026749 0.0.0.1.80 > 0.0.0.5.10001: . 1001:2025(1024) ack 1001 win 16384
00:00:01.026749 0.0.0.1.80 > 0.0.0.5.10001: . 2025:3049(1024) ack 1001 win 16384
00:00:01.027223 0.0.0.5.10001 > 0.0.0.1.80: . ack 2025 win 16384
00:00:01.027223 0.0.0.1.80 > 0.0.0.5.10001: . 3049:3463(414) ack 1001 win 16384
00:00:01.027255 0.0.0.5.10001 > 0.0.0.1.80: . ack 3049 win 16384
00:00:01.027896 0.0.0.5.10001 > 0.0.0.1.80: . ack 3463 win 16384
00:00:01.027896 0.0.0.1.80 > 0.0.0.5.10001: F 3463:3463(0) ack 1001 win 16384
00:00:01.028131 0.0.0.5.10001 > 0.0.0.1.80: . ack 3464 win 16383

00:00:01.031124 0.0.0.3.1080 > 0.0.0.10.10001: . 2561:3073(512) ack 3585 win 16384
00:00:01.031124 0.0.0.10.10001 > 0.0.0.3.1080: . ack 3073 win 16384
00:00:01.032293 0.0.0.3.1080 > 0.0.0.10.10001: . 3073:3585(512) ack 3585 win 16384
00:00:01.032293 0.0.0.10.1070 > 0.0.0.9.10001: . 1:1001(1000) ack 1001 win 16384
00:00:01.032293 0.0.0.10.10001 > 0.0.0.3.1080: . ack 3585 win 16384
00:00:01.033357 0.0.0.9.10001 > 0.0.0.10.1070: . ack 1001 win 16384
00:00:01.034293 0.0.0.3.1080 > 0.0.0.10.10001: . 3585:4097(512) ack 3585 win 16384
00:00:01.034293 0.0.0.10.10001 > 0.0.0.3.1080: . ack 4097 win 16384
00:00:01.035461 0.0.0.3.1080 > 0.0.0.10.10001: . 4097:4609(512) ack 3585 win 16384
00:00:01.035461 0.0.0.10.1070 > 0.0.0.9.10001: . 1001:2025(1024) ack 1001 win 16384
00:00:01.035461 0.0.0.10.10001 > 0.0.0.3.1080: . ack 4609 win 16384
00:00:01.036545 0.0.0.9.10001 > 0.0.0.10.1070: . ack 2025 win 16384
00:00:01.037481 0.0.0.3.1080 > 0.0.0.10.10001: . 4609:5121(512) ack 3585 win 16384
00:00:01.037481 0.0.0.10.10001 > 0.0.0.3.1080: . ack 5121 win 16384
00:00:01.038649 0.0.0.3.1080 > 0.0.0.10.10001: . 5121:5633(512) ack 3585 win 16384
00:00:01.038649 0.0.0.10.1070 > 0.0.0.9.10001: . 2025:3049(1024) ack 1001 win 16384
00:00:01.038649 0.0.0.10.10001 > 0.0.0.3.1080: . ack 5633 win 16384
00:00:01.039732 0.0.0.9.10001 > 0.0.0.10.1070: . ack 3049 win 16384
00:00:01.040669 0.0.0.3.1080 > 0.0.0.10.10001: . 5633:6145(512) ack 3585 win 16384
00:00:01.040669 0.0.0.10.1070 > 0.0.0.9.10001: . 3049:3463(414) ack 1001 win 16384
00:00:01.040669 0.0.0.10.10001 > 0.0.0.3.1080: . ack 6145 win 16384
00:00:01.041264 0.0.0.9.10001 > 0.0.0.10.1070: F 1001:1001(0) ack 3463 win 15970
00:00:01.041264 0.0.0.10.1070 > 0.0.0.9.10001: . ack 1002 win 16383

The dark blue lines are traffic between the HTTP client and the Tor proxy. Red lines are the traffic from the HTTP server I added in manually. Some of the times were chopped slightly so as to fit onto the page nicely.
We can see the steps all the way through. The initial blue lines show the syn, syn/ack, ack tcp conversation between the HTTP client and the Tor proxy. When this connection is established, the Tor proxy now creates a Tor circuit. The bold lines show the Tor packets being sent back and forth establishing the circuit.

Circuit Creation

1. The first packet sent creates a circuit with the first router. This router respones with a connection succeeded packet
2. The next packet is an extension, it tells the Tor router we are already connected to, to extend the circuit onto another router. Again, a packet is sent in response to confirm the extension.
3. This is done once more to the third router
4. We extend again to the fourth router
5. The fifth communication sends the ip/port of the TCP (HTTP in this case) server we want to connect to. We can see the connection request being sent, and then the red lines of the server side. This is the exit router establishing a TCP connection to the http server.

Data transmission

Now that the circuit has been established, the data can be sent over the circuit between the client and the server. At time 00:00:01.001228 we see that the HTTP client has sent a 1000 byte packet to the proxy. As the circuit is still being established at this time, this packet is left waiting. Eventually, immediately after the circuit has been established, at time 00:00:01.020531,we can see two 512 byte Tor cells being sent across the circuit. These contains the initial 1000 byte HTTP REQUEST packet. They arrive at the Tor exit router, are put back together and sent onto the HTTP server at time 00:00:01.026434. The HTTP server responds with a number of packets, rapidly sending the packets one after the other and then closes the TCP connection with the tor exit router.

These packets are recieved by the Tor exit router, are chopped into Tor cells and sent back over the circuit to the Tor proxy where they are put back together and delivered to the HTTP client.

One interesting thing that the block of red lines demonstrates is the slowness, or latency introduced by the Tor circuit. The server is able to send all its data and close the connection before even a single packet of that data stream reaches the Tor proxy.

You might notice some odd things in the tcp trace as well ….

The title of the thesis is “Anonymity and traceability in cyberspace” and mostly deals with the issue of traceability.

IP TCP Stream Spoofing

Ip TCP spoofing isn’t as impossible as it should be. The problem with spoofing a complete conversation is that the ACK numbers on each packet being sent out need to be correct. They need to be the same as the sequence numbers recieved. To prevent easy guessing of the sequence numbers, the initial sequence number is randomised. So the attacker must guess a 2^32 value correctly in order to spoof a conversation. This sounds great, the problem is that equipment vendors don’t follow this rule all the time. Alcatel equipment for example does not use a random value, instead a chosen value is incremented by 64,000 every millisecond. This is all detailed on pg27, and a CERT Advisory

ADSL Authentication

When authenticating a DSL connection, the users DSL modem connects to a DSLAM in the telephone exchange. The DSLAM creates a Permanent Virtual Circuit (PVC) to a “Home Gateway”. The authentication details are then offered to the Home Gateway by the DSL Modem which in turn will hand them onto the correct ISP RADIUS server. The ISP RADIUS server is chosen based on the username of the authentication details. e.g gavin@eircom.net will go to Eircoms ISP, gavin@esatbt.ie will go to ESAT BTs RADIUS server etc. The RADIUS server will authenticate the user and then allocate them an IP using DHCP.

The issue with this is that I can borrow another persons authentication details and commit some nefarious act on the Internet. When the IP used in the nefarious act is traced back, it will lead to the owner, and not me. The only way to verify in fact I was the one using that IP is to check the logs of the Home Gateway. This will show what PVC was used to pass on the authentication details, back to the DSLAM and back to the physical socket connecting my telephone to the DSLAM.

The only problem is that apparently the Home Gateway may not actually log this information. Pg43.

Playing with reverse DNS

Plenty of interesting things one can do with reverse DNS it seems. For example Apache logs use an IP address at the start, or can reverse resolve this IP and use the DNS instead. If the reverse DNS address looks like an IP, then effectively a fake IP can be substituted in the logs. There are options to disable this, or do full IP checking in Apache. Reverse DNS is disabled by default, and if enabled double DNS lookups can be performed. Indeed any sort of string could be inserted into the logs with this trick. Pg50 and this article

The same sort of trick can be performed on an IRC server. The server should log just the IP, but this isn’t always the case. Pg55.

And again, in e-mails, to fool someone that doesn’t thoroughly investigate the headers. In this case an ip was configured to resolve to bay15-f8.bay15.hotmail.com and extra hotmail specific information such as X-Originating-IP: added. The IP for x-originating of course was a false one. Pg59

HopFake

A simple trick for creating false traceroutes. When an ICMP echo packet arrives at the local machine and the TTL value is zero, don’t respond with an echo, respond with a TTL exceeded and a different IP address. The machine sending the traceroute packet assumes that your machine is a router and will send another ICMP echo packet with TTL+1. You can then respond to this new ICMP echo with either an echo and a different IP address, or send back another TTL and continue on the traceroute. Nice little trick. Pg54 and a copy of hopfake

That’s just small small knick knacky things from the thesis, I have yet to read the remaining two thirds.

It’s very simple, the tcpClient sends a request for some data and the tcpServer sends data of that size back. When the tcpClient recieves the data, it disconnects and the established torCircuit is torn down. (Well it should be. At the moment, everything just dies when the connection closes)

Obviously the most important part of the simulation for me is getting results from it. At the moment what I’m interested in is obtaining packeting timing information which will allow me to compare streams on one part of the network with streams on another part.

There is a measurement infrastructure in place in SSFNet, however I got a tad confused with the documentation for it. It’s actually extremely straightforward though. I thought I’d document what I’ve done so far. The SSFNet community in general is quite small, the tool doesn’t appear to be actively developed, so I figured any spur to this might help. It’s also handy for me for logging what I’ve done.

Utilising a BasicRecorder via a ProbeSession

In the DML file for your simulation, add the following to the graph section

ProtocolSession [
name probe use SSF.OS.ProbeSession
file "/tmp/mystream.dat"
stream "My Stream"
]

This will create a ProbeSession “pseudo-protocol” within the graph. This can then be accessed like below

if(this.recorder == null)
{
ProbeSession probe = (ProbeSession)this.owner.inGraph().SessionForName(“probe”);
this.recorder = (StreamInterface)probe.getRecorder();
}

Where this.owner is a class extending the ProtocolSession class. The StreamInterface returned is actually an object of type BasicRecorder, this isn’t mentioned anywhere in the documentation. I haven’t quite figured out how to get a different StreamInterface implementing class returned.

Once this recorder has been obtained, it can be written to quite easily using the send() method.

byte[] nothing = new byte[10] ;
String writer = owner.localNHI;
String type = VIRTUAL ;
int nWriter = this.recorder.getRecordSourceCode(writer);
int nType = this.recorder.getRecordTypeCode(type);
this.recorder.send(nType,nWriter, owner.localHost.now()/(double)SSF.Net.Net.seconds(1.0),nothing,0,10);

It took me a while to figure out where the BasicRecorder class was getting the int values from for the Code strings. It just creates internal numbers, ints, to store the string the first time it’s called and subsequently uses that int for every other call. Everything is figured out by looking at the code of course, luckily most of SSFNet is opensource.
To view the outputed log in /tmp/mystream.dat, you can use the BasicPlayer class. The stream identifier is as defined in the DML file, “My Stream”. with a 0 appended.

gavin@gavbot:~/workspace/ssfnet/bin$ java SSF.Util.Streams.BasicPlayer “My Stream.0″ /tmp/mystream.dat.0 > output.tmp
{Player processed 825 records, 8210 bytes, in 0.1 seconds (82 KB/s)}
gavin@gavbot:~/workspace/ssfnet/bin$ head -5 output.tmp
[type=3 ("Real") source=2 ("2") time=1.276107562 bytes=10]
[type=3 ("Real") source=4 ("3") time=1.278110762 bytes=10]
[type=3 ("Real") source=2 ("2") time=1.280161322 bytes=10]
[type=3 ("Real") source=4 ("3") time=1.286252842 bytes=10]
[type=3 ("Real") source=5 ("4") time=1.288256042 bytes=10]
gavin@gavbot:~/workspace/ssfnet/bin$

My next step is to hook the stream recording and playback up to the RaceWayViewer tool, so as I can actually see what’s going on in the network. It’s not particularly important, or remarkably useful, but it is handy to demonstrate how the simulation works. Beyond that lies creating larger networks, testing the simulation in comparison with the real tool and then starting to analyse results if the simulation output approximates the Tor output.