Glop

I was having trouble figuring out if my simulation was working properly or not, so had to trace through the tcpdump output from it. I thought it was interesting enough, so decided to impose it on whatever poor soul happens onto my blog.

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 ….

This was my pet peeve with my mobile phone and java software. Everytime a java application attempted to access the filesystem on the phone, a permission request dialog pops up. For a mapping application that uses tiles of around 256×256 pixels, it needs to access the filesystem with great regularity and thus great annoyance ensues.

The correct way to solve this problem is for the application writer to sign the java application with a certificate, obtained from the likes of Thawte or Verisign. The problem with this is:

• It costs money to get a certificate
• It appears that only a commerical entity can purchase a cert. for signing j2me applications.

There are alternatives to this that I spent most of the day investigating. The best way seemed to be to creates ones own private key and certificate. Upload the certificate to the root store on the mobile phone and sign the application with the private key. Tedious perhaps, especially seeing as I’d have to sign every application and every new version of the application I’d put on the phone, but I was happy enough to do that.

However. There is no support for adding ones own certificates to the K750i/W800i. No official support that is. After much googling and trawling through the forums at http://www.esato.com I found software to do this. An application called FAR Manager in conjunction with plugin called SEFP. The FAR Manager application is a generic file system manager, but it supports plugins for accessing various filesystem types other than a standard hard drive. Network filesystems, FTP, etc.

The SEFP, Sony Ericsson Flash Plugin, is able to connect to a K750i/W800i phone over the stock DCU-60 cable and offer access to the filesystem on the onboard flash memory.

There is a brief guide available showing the basics of using FAR Manager in conjunction with the SEFP.

Once this is up and running on the mobile phone (You’ll need to install the Sony Ericsson Update Manager first if you haven’t already. This contains the USB flash drivers the plugin uses to access the phone), it’s possible to copy files to/from the mobile phone flash memory. It’s then a simple matter of uploading a .cer file to the correct directory on the phone, modifying a customize.xml file on the phone to list the certificate, and reseting the phone using a master reset.

Supposedly. This doesn’t actually work. The certificate does not get added to the root repository as some import function needs to be run. I couldn’t figure out how to do this, it appears that the phones firmware needs to be completely flashed and the certificate copied over before the phone is started. This way, when it’s started for the first time with the new firmware, it initializes the certificate database.

So I returned to the forums and kept trawling. I found an easier method, but this is a real hack. The flash plugin has some extra features that allow one to edit the raw flash memory directly, at a bit level. (Extremely useful for obtaining a good forensic image of a Sony Ericsson mobile phone I’d imagine). The plugin also has support for small .vkp scripts that when run, will patch a location in the flash with certain values, so simple automation of memory editing. A number of these scripts have been created that perform a number of actions. And one of those actions is.. you’ve guessed it, to disable requests for file system access.

I downloaded the script from this forum article and installed it using the FAR Manager with plugin. (In the application, press enter on the flash link, press tab to select the other pane, browse to and select the .vkp file. Press F5 to copy and when prompted select the run .vkp file option.)

Success ! No more filesystem prompts. Now I just need to figure out where j2memap looks for map files on the memory card and I’m away in a hack.

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).