vandeneynde.net

0xa12:0×0001

May 28th, 2007

For the ones who did not read Max Moser’s paper about converting a cheap USB bluetooth dongle into a full blown bluetooth sniffer, the code 0xa12:0×0001is the devide ID for the cheap CSR based bluetooth device which Max used to do the conversion.

The reason why I am so happy with this code is that this code is exactly the code which came on my linux computer when I inserted my new Bluetooth USB key and typed ‘lsusb’.

I also found a good howto which brings Mosers’s theory into practice. I did not have much time this weekend so I will try to test the howto during the next days.

On the non-IT side, I celebrated my 27th birthday this weekend, went to a little festival in Olen (pics), attended my second cousin’s baptism party and enjoyed a few bbq meals in between (despite the rainy weather).

Today, CNET reported that Domainkeys are adopted by the IETF as a standard and that the outlook of a lot less spam and phishing is nearby. In my opinion it will not solve the spam problem and fulfill Bill Gates’ prophecy of a spam free world any time soon.

The Domainkeys system works similar as signing your mail with PGP. The difference is that instead of signing your message to authenticate you as the sender, Domainkeys embeds a cryptographic signature in the header of the mail to authenticate the sending mail server for a domain. The public key, which is needed to check if a cryptographic signature is valid, is stored in the domain’s zone file.
The receiving mail server can check the signature of a message by fetching the public key through DNS for the sending domain.
On paper this seems great. It would mean that no one can spoof the sender’s domain.

The caveat is that, in order to make it really work, everyone needs to update their DNS and especially heir email infrastructure. Thinking about how slow the transition of IPV4 to IPV6 is going, this could take some time. Granted, a change (or update) of mail server and an update of the zone file is less work and less invasive then migrating your entire IP infrastructure but still it will be a long time until every domain runs on Domainkeys enabled servers.

Now, what will happen in the transition time? Having installed a few anti-spam solutions in various corporate infrastructures, I have learned a few things. One thing is that businesses hate false positives. No matter how much their dislike of spam is, no one wants to wait for an important corporate e-mail because the anti-spam solution falsely recognized it as spam.
So, in the transition time, when a mail arrives from someone@importantcustomer.com without a Domainkeys signature, most companies’ policy will be to just allow it even if another mail from someonelse@importantcustomer.com earlier had a Domainkeys signature. This is because the receiving party cannot be certain during the transition phase that the sending party has indeed upgraded their entire mail infrastructure.
Furthermore, a corporation is certainly not going to block mail from newcontact@futurecustomer.com just because futurecustomer.com does not have their Domainkeys in place yet.
This means that spammers can use domains to send their mail from and don’t even need to bother with setting up Domainkeys.

It is very important to understand that Domainkeys only authenticates the sending domain. This means that, as a spam protection, it would only work against spam mails which spoof a trusted domain. If a spammer would write spam from me@myjustboughtdomain.com, Domainkeys offers no extra protection whatsoever to prevent the spam from reaching its target audience.

An advantage of Domainkeys would be that it could mean the end of phishing. Assuming that yourbank.com has indeed installed the Domainkeys and you only trust Domainkey signed mails from yourbank.com, what would stop a fisher from acquiring y0urbank.com, setting up a Domainkey infrastructure for the domain and phishing you from there? Nothing at all, domains are being bought and sold every minute and that is not going to change. Will the user trust y0urbank.com? Most likely he will. It reminds me of a story about phishers acquiring a valid SSL certificate for one of their domains. Did the user fell for it? Off course, he did, since the user was always taught that a valid certificate (little padlock in your browser) means it is all secure right? No one ever educated him that SSL only secures the transport not the content, and in the phisher’s case, SSL secures a malicious message.

This brings me to the last part. Domainkeys only verifies the authenticity of the domain’s sending server, not the content of the message. The message could be modified in transit, if the Domainkey of the header is correct; the message is authentic for the receiver. Is it technically possible that the message could be modified in transit? Sure it is. It is not unthinkable that the sending mail server or another device along the path gets compromised.

To summarize, I think that Domainkeys could be a step in the good direction when it would be made mandatory for every server starting right now. Even, if it would happen overnight, Domainkeys would still not solve the spam problem. The only thing which would be a little harder is phising.

I think we will have to live with spammed inboxes and phishing a little longer.

Long weekend

May 20th, 2007

This week, thanks to some holiday in Belgium, the weekend started on a Wednesday evening instead of a Friday. Every week should have a 4-day weekend!

Apart from some sleeping in, squash, hanging out in the pub, going out, catching up on my favorite feeds, watching some TV (I have refound my old love for South Park ), assembling a new gas barbecue (and eating food from it ;) ), I have been playing with sguil.

Sguil is an open source framework to practice network security monitoring (NSM). It uses SANCP and barnyard to analyze Snort data. It seems like a good framework but the documentation is, in my opinion, not the best I have ever seen. After some compilation issues, I have managed to get all the needed software compiled now on my Linux box. The only thing left to do is to configure it to match my needs.

But, that will be something for later. Right now, Jack Bauer is eager to get his nephew back from the Chinese. :)

I noticed that, again, I did not update this blog for quite some time now. Of course, I have been busy with all kinds of stuff. But part of maintaining a blog is actually blogging about the stuff you are busy with and not using it as an excuse not to blog. Therefore I am going to try to update this site more frequently with all kinds of stuff.

On a technical level, this month I have been busy (apart from my day job as a security consultant) with some fun security topics including WEP cracking (the new and faster method), USB switchblades and some other stuff. I just ordered a new Bluetooth stick to play with so I will probably blog about that somewhere in the future

I also discovered google reader which is the best feed reader I have ever seen. Thanks to this excellent google tool, I can read my news, blogs, websites, etc in one interface accessible from everywhere.

Nuclear Fusion Nearby?

April 23rd, 2007

SlashDot stated that Bussard gets Navy funding for his Fusion Project. For those who didn’t see the video at Google: Bussard is a scientist who is investigating a method of creating nuclear fusion in another way than the more popular (and very expensive) design of the tokomak generator. If he succeeds, it would be great for Earth’s energy issues.

First HDR Experiment

April 23rd, 2007

With the sunny weather of the last days, I have been experimenting with HDR photography.

The pictures below are taken with a Nikon D70. The first one is a picture taken with all settings at ‘AUTO’ on the camera. The second is a HDR composed image of 7 RAW pictures (3 under exposed, 1 metered and 3 overexposed), tonemapped to ‘Details Exposuer’, the third one is an variant of the second one but with another tone mapping.

Auto - No HDR

Details Exposure

Tone Mapping

Running on the Etch

April 9th, 2007

This Sunday, Debian GNU/Linux 4.0 codenamed ‘Etch’ was released as the next stable release of Debian. Therefore, both the servers where this site is hosted on have been upgraded to the latest version.

Although not as easy as just running ‘apt-get dist-upgrade’, the upgrade went very smooth. I just had to follow the release notes and after a reboot both servers ran the newly released version fine. Well, actually one server did not came up right away but that had nothing to do with the upgrade. A manual file system check was needed. Thanks to the quick support from the techies at serverpronto, the server was back up within the hour.

If it takes as long as it took Etch to become a stable release, the next major upgrade will be somewhere 22 months from now.

For those interested, these were the steps taken to upgrade from Debian 3.1 (sarge) to Debian 4.0 (etch):

  • aptitude update
  • aptitude -y -s -f –with-recommends dist-upgrade
  • aptitude upgrade
  • aptitude install initrd-tools
  • aptitude install linux-image-2.6-686
  • aptitude dist-upgrade
  • aptitude update
  • reran ‘aptitude upgrade’ and ‘aptitude dist-upgrade’ until no packages were kept back and nothing remained to be done.
  • reboot
  • removed obsolete packages from old sarge.
  • recompiled home-built soft. (This was not really necessary but I liked to have the soft compiled with the new gcc4)

If, for some reason, you would like to know more about the steps taken, just drop me an email.

Space Cat

March 30th, 2007

I accompanied our cat to the vet yesterday. The poor thing is being harassed by another cat in the neighborhood. She has to wear a collar for a while now until her wounds heal. Although the picture shows her looking very sad, it is very funny to see her trying to escape her ‘satellite’ collar.

Sad Scully

A long time since I updated this blog. Main reason is that I went skiing to Austria a few weeks ago and that I became addicted to 24. I started with season 1 in January/February and am now finishing up on season 5. Fortunately, season 5 is the last season available on DVD in Europe so I will (hopefully) find more time to update this blog in the future

Oh yeah, some pictures of the skitrip can be found here.

A bad week for the home LAN

February 12th, 2007

I didn’t have time to update this blog last week. Most of my free computer time was spent on recovering my home linux server.
Tuesday evening, the three months old 500GB SATA disk of my home server crashed! And it crashed big time. Nothing but ‘tak-tak –tak’ and it was impossible to recover anything from the damn thing.

Fortunately, I had setup an rsync which synced all my data and most of the server configuration to an external USB disk every night. Not much data was lost.
But, even then, restoring the server took more time than I expected. This is mostly because I learnt the hard way that having all the config files on a backup is not a guarantee for a fast restore. Installing all the apps (with dependencies), compiling some soft, compiling a custom kernel for the motherboard takes a LOT of time.

Therefore I have taken my precautions in case the replacement disk should decide to go on permanent leave in the near future. I googled a bit and found mkCDrec. This neat tool allows one to create a bootable recovery CD set from the entire system including installed applications. When necessary, you can boot with the CD set and quickly restore the system in the state when you created the disks.

So from now on, whenever I make big changes to the system. I just run mkCDrec, save the ISO images to my external disk and that’s it: I am a little better prepared for when Murphy strikes once more.

Next on the improvement list: buy a small UPS for when lightning strikes :-)

Google Reader Shared Items

Belgian Security Blognetwork

Proudly powered by WordPress. Theme developed with WordPress Theme Generator.
Copyright © vandeneynde.net. All rights reserved.