Summerschool Aachen 2004/Project Days
As you all should know, on Friday, Octobre 1st, we have a Project Day. Everybody should work all day on a project that he can choose (more or less) freely.
Please make sure to inform us about your project and your goal until Wednesday, Septembre 29th!
Feel free to ask us for help if you lack of ideas.
--Cklein 23:24, 23 Sep 2004 (CEST)
Scan of the Month 32
Yesterday I started to work on the Scan of the Month Challenge by the Honeynet Project and I decided to continue it during the project days, and possibly submit a solution before the deadline (which is Friday 23:00 CET).
Me and Mario planned to try and finish a (non-working) perl module he made a while ago which allows you to forge arp packets. (this module is called Marp).
-- Ilja van Sprundel
edited: I just send the report of my 2 days of projects to christian, and as it turned out I didn't make the arp library (also, mario wasn't at the university then due to illness). I did make the summerschool advisory, and some work on a paper and a talk me and Max are (probably) going to present at the congress this yea (it's about fingerprinting). I also watched a movie of gobbles at defcon 10 which could also be seen as research, and I will shortly post something about that on the blog.
I am planning on continue developping the generic automatic feature extraction tool for fingerprinting protocols. I have already some code from the network Recon Lab, but I still need to code a classification engine, and solidify the code so that it is useable by others.
I will write a program that looks for ARP replies on a network and compares the data with a local database. In case of a mismatch, it will send out a packet with the correct info.
This is meant to defend against ARP spoofing where an attacker periodically sends out unsolicited ARP replies to poison the cache of other machines. The aim is to update the cache of victim machines as quickly as possible, so that the forged information will be kept in the cache as shortly as possible.
The other aim of the project is for me to play with libnet and libpcap.
Update:  is the latest version. It works well for ARP/IPv4, although I had hoped for a faster reaction. IPv6 support is not there yet, but some framework for handling IPv6 packets is there.
We are working on a DNS tunnel (hence that stupid name, you know about drilling and stuff ;-). We want to keep it simple, so this will be just a point-to-point connection to get data across the network. At a later time this might be usable to implement some other protocol on top of that.
We spent most of our time so far working out the basics of the DNS protocol and think we have now actually come up with a way of achieving what we want, simply using the encoded domain names to push data and using RDATA TXT fields for retrieval. We first thought about using CNAME chains, but are not really sure whether this would work, since the specs are a little unclear about it. Besides, RDATA TXT offers a lot more space to put stuff into.
An interesting point about it will be to poll data from our "fake" nameserver, we will probably have to play with the correct TTL and use some sort of sequence numbers to avoid caching problems.
Our first milestone was to actually come up with a basic idea of how to implement this, which we just achieved. By this time tomorrow, we should have basic implementations of the server as well as the client, so we have some spare time to actually get it working and enhance with features that come to our minds.
I decided to continue working on the fingerprinting tool I started on monday. Currently it works pretty well for DNS, using djb's database.
--Cpunkt 18:16, 30 Sep 2004 (CEST)
At the wardriving days we played around with kismet, gpsdrive and gpsmap and we all felt the need to improve this tools. We are writing an enhanced viewer for the XML output of Kismet in Java. It will have different views with different graphic layers. If there is time left we want to enhance Kismet so that it looks into the just scanned networks for standard services like dhcp etc. Maybe connected to a file with default passwords for APs.
3Com Switch 3300
I am continuing my reverse engineering of the firmware in 3Com's Switch 3300. My aim is to produce some evidence that it is possible to make the switch execute arbitrary Motorola 68020 code, as proof of concept of a possible embedded device based attack vector.
--Slewis 12:08, 1 Oct 2004 (CEST)