Glop

Tiddlywiki is a great tool I came across recently while looking for something to manage my data. I’d previously used hnb but found it slightly restrictive. I couldn’t easily check it when away from my machine. Checking it requires ssh’ing into my pc in college, which requires a sshkey that I don’t always carry around with me and also making sure I had Internet access !

I don’t recall exactly how I ended up encountering the TiddlyWiki tool, I think I was reading through a Nokia 770 email list and saw it mentioned. I was really impressed when I saw what it could do.

Tiddlywiki is a wiki, just like MediaWiki, TWiki etc. The difference with TiddlyWiki is that it is completely client side software. The wiki consists of a single file with a good deal of javascript in it. When a new entry is added to the wiki, that file itself is edited by the Javascipt and the new entry stored in a div. This means you only need to use your browser to manage and store your information, todo, notes, ideas, documentation etc.

There are several tutorials linked from the tiddlywiki website which explain how to get going. It does take a bit of getting used to before one starts getting things done, but the learning curve is well worth it. Data is entered into constructs called Tiddlers. By typing in a wiki formatted word like AnExampleOfAWikiWord, this word becomes a link to a new Tiddler called AnExampleOfAWikiWord. Clicking on the link bring up the tiddler, you edit it and save your data, nice and simple.

Another great thing about TiddlyWiki is how extensible it is. Numerous plugins have been written for it, from simple things like adding timestamps by inserting a {ts} to comprehensive calendering and ToDo systems. A neat thing about the plugins is how easy it is to install them. A plugin distributed with the default wiki file is an import plugin. If you see a tiddlywiki you like, point the import plugin at the url of the wiki page and it will list every Tiddler on the page. You can pick which ones you want to import and it will save them into the local file. A decent plugin website is http://www.tiddlytools.com. The trick is to keep your Tiddlywiki as simple as possible. There are an awful lot of plugins out there that are just useless and slow the system down.

Along the same lines, there are also plenty of nice themes for TiddlyWiki. Check out http://tiddlythemes.com/ for a very nice site with some decent themes.

Of course, there are serverside implementations of TiddlyWiki so as to write data back to a server, at the moment I carry mine around on a usb key and store it in a version control repository. I’ll probably move it onto a web server soon enough.

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.