I woke up around 6am for an early morning and got some work done prior to the CanSec West registration (which started around 9am). The registration procedure had some technical difficulties which halted the process for a little over an hour. After successfully registering I walked towards a glass wall and stared at a piano located on the floor beneath me while contemplating a few melodies.

The first presentation, "Mobile Workstations, mitigating the crawling trojans" presented by Cedric Blancher, was about to begin. I must admit the name sparked more curiosity and excitement then the presentation itself. The "Mobile Workstation" was essentially a laptop, as expected, and the "crawling trojans" simply meant the ever changing insecure network environment the laptop is subject too. Much like in "Independence Day" the Alien skiff kept at Area 51, piloted by... monkeys, invades the perimeter defence of the Alien mother ship undetected while carrying a deadly payload. The mother ship is damaged severely because the Alien's did not anticipate the skiff to be infected by... monkeys. So the morale of the story is not to treat a "Mobile Workstation" as if it were a trusted device (such as an office workstation) because you can not control it, only the monkeys do.

The second presentation, "0wn3d by an iPod: Firewire/1394 Issues" presented by Maximillian Dornseif, was easily my favourite. First introducing the history and some technical data of Firewire/1394, I mean FireWire/1394, I mean iLink... Mr. Dornseif then explained the potential to read and/or write to any physical memory address on a system through the Firewire port without authentication. I must admit I was sceptical at first as it seemed highly illogical that such capabilities would be so easily granted. My scepticism was quickly put to shame as Mr. Dornseif provided us with a demo. Two computers were first linked together using the Firewire port and then the video memory of one computer was read and modify by the other. Someone, somewhere, must be saying "Oops" right about now.

The third presentation, "0wn3d by everything else: USB/PCMCIA Issues" presented by "David Maynor", was particularly boring. At first the issue appeared to be the potential exploitation of device drivers, then DMA, then USB, then firmware, or hiding code in FPGA's that some video cards apparently use... FPGA's used by a consumer video card? Maybe if I was not an avid IDA user I would have enjoyed the IDA screenshots. The lack of consistency left me logging into my IRC client and talking with a few friends about... lack of consistency. I felt like the sky is falling... only it is not falling... but we can pretend it is.

The fourth presentation, "Everything is Vulnerable" presented by Brian Martin & Jake Kouns, started off well. They talked about known issues with vulnerability databases that have annoyed me and my fellow coworkers since the first day we started using them. A fine example entailed a vulnerability database claiming version "1.0" and "2.0" are vulnerable... but what about "0.9"? or "2.2"? The vulnerability is not thoroughly tested (if tested at all) and therefore should only be taken as a partial answer and not a final answer. Of course all the troubles of using a vulnerability database to determine the vulnerable instances of an application can be solved by simply checking for the existence of the vulnerability directly rather then writing peripheral version check. It was also pointed out that vulnerability databases have a tendency never to revisit and update past vulnerabilities. Therefore a vulnerability that claims to have no solution, according to the vulnerability database, may in fact have a solution.

The last presentation I am going to comment on was the sixth presentation, “ICMP Attacks” presented by Fernando Gont. The talk emphasised 3 ICMP attack methods against TCP sessions that can reduce TCP session throughput, increase TCP session latency, and reset a TCP session. Four vectors are required to perform each attack: The Source and Destination IP address, and the Source and Destination TCP port associated with the TCP stream being targeted. If you know your target Source and Destination IP address, and the Destination TCP port, the only vector you need to brute force is the Source TCP port. Therefore the brute force space is only 65536 possibilities. This brute force space can be reduced when considering deterministic port ranges assigned to Source TCP ports by most Operating Systems.