January 2008 Archives
Mon Jan 14 10:42:00 2008
Teaching at the Brandenburg University of Applied Science
As part of our research commitment, I went to teach a few classes to students of the Master of Security Management course at the Brandenburg University of Applied Science, following an invitation from Professor Friedrich Holl.
The first lecture focused on security engineering and the different ways professional security verification services are performed. We also went into discussions on how software audits are done, including source code review as well as binary code audits.
It is interesting to talk to people with solid education on the subject but less practical experience in the field. What I found most astonishing was that they had little to no preference for a specific programming language. This caused some discussions about which programming languages are better fit for security verification. I had to argue about my point that more modern languages should be used for quite a while. What I think finally drove the point home was the effort needed for testing, especially unit testing and code verification. If your language and especially your runtime environment (for example .NET) does not allow you to play fancy tricks with pointers or address indices outside of the array bounds, neither testing nor automated code verification needs to cover those topics and deal with the problems inherent to such actions. If nothing else convinces you to stop writing your programs in C, it should be the fact that the less flexibility on the lower levels of machine interpretation you have, the less things can go wrong and be turned against you with an exploit.
Of course higher level languages have plenty of their own issues. But given the fact that the fault density actually directly relates to the number of lines of source code, a language in which you write less code allows for a smaller chance to introduce faults. This is why I cringe every time I hear or read someone stating that the prototype is written in Python and works well but the release version is going to be rewritten in C. Please, don't.
Mon Jan 7 17:56:44 2008
Due to popular demand, we created some T-Shirts with the cute little PortBunny. Check out shop.recurity-labs.com.
Sun Jan 6 18:58:51 2008
Every year between Christmas and New Year's Eve, the Chaos Computer Club invites hackers and security enthusiasts to the Chaos Communication Congress in Berlin. Of course, this is a must-go event for everyone at Recurity Labs.
The event was more smooth-running than any other CCC Congress we have been to. Herding such a large number of hackers, coordinating and staying within the schedule of three tracks isn't easy. But this year, everything went perfectly well from our point of view. The community responded well to most talks we have attended and a number of follow-up activities arose, like the newly deployed barcode hackers wiki, hosted at cyphertext.de.
This year was also the first time that we could contribute the results of our research activities to the conference. We presented and released PortBunny, a specialized TCP port scanner for professional use. The motivation behind developing a new port scanner was the requirement in the professional security services world to be predictable.
Port scanning a large network can take a significant amount of time. When using the commonly available tools of the trade, the time to scan a network varies a lot, depending on how well the network is protected. But from a professional services point of view, you want to minimize the time tools work on a subject and hereby maximize the time you can work on it yourself. Additionally, being able to predict the time a TCP port scan takes is a huge improvement for estimating the overall time required for the engagement.
PortBunny is designed to run in the Linux Kernel space on dedicated machines. It uses different algorithms than most other scanners to separate the bandwidth saturation detection from the detection of filtered (aka firewalled) ports. The slides of the presentation can be found on our publications page.