Glop

As I mentioned in the last post, I’m working on a Tor simulation. I spend most of my time doing that and haven’t had much of a chance to do as much reading on current research as I should. One particular document I was quite interested in was Richard Clayton’s Ph.D. thesis. Dr. Clayton does a lot of very practical security research, which can be a breath of fresh air compared to the standard academic papers on security. By that I mean his papers are extremely readable, practical and not overflowing with maths. (Along with mornings, me and maths don’t get on too well)
I finished re-reading the Aubrey-Maturin series again the other day on my 770, so downloaded a copy of Clayton’s thesis as my bedtime reading! There are a number of very interesting tricks and techniques raised in the thesis, quite a lot of which I hadn’t encountered before. I thought that I would post up some of the more interesting ones. I’m sure a lot of these are common knowledge, but I was surprised by some.

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.

I was playing around with converting recorded CS:S demos to videos and came across the GameCam tool, in combination with the Windows Movie Maker application. Both are reasonably decent, movie maker is a bit buggy, so save regularly. Another GameCam equivalent tool is Fraps. Both have freeware/demo versions that cut down on the functionality, but do work.
One issue I encountered with CS:S demos is that when a map is changed, the demo continues recording with a _X appended to the filename, where X is a increasing number for each map change. These demos won’t play correctly by default. The solution is to run the demoui cmd from the console and use that interface to load the demo. Once the demo is loaded, enter 50 into the frame box and press goto. This will jump to the start of the demo and start playing it correctly.

An example I uploaded to Youtube is below, music courtesy my eccentric eclectic flatmate.

Update: Dec 4th, 2006.

I finished creating the video I was hoping to create. That is, a mockery of my CounterStrike playing peers. The YouTube version below is quite poor quality unfortunately. A full quality 720×576 version is available though. BotSlaughter-720×576 (95MB).

My work at the moment is building a Tor based simulation. I’m using the java SSFNet simulation tool which is designed to be extremely scalable. Hopefully I’ll be able to implement thousands of nodes, with hundreds of thousands of connections. At this stage I have a rudimentary implementation of the Tor protocol, with a torProxy, torRouter and torExitRouter. I can connect a testTcpClient to a testTcpServer via the torProxy, 3 torRouters and a torExitRouter.

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.

The morning time is my arch nemesis