Yesterday, I bought a new wireless router for home. I was in the computer store to buy some DVDs and picked it up in more of an impulse. My old router was not performing well so I bought the first draft-n gigabit router I happened to stumble upon after quickly having verified that it was supported by dd-wrt.

Back home, I noticed that I was a little too quick in verifying the dd-wrt support. It will be supported by dd-wrt but currently it is still a work in progress. So I decided to use the stock Belkin firmware for now. However, one minute later, I stumbled upon a major problem in that plan. The little router does not support DHCP reservations which I need in my home network. I could offload DHCP to another small device in my network but I preferred to have the router handle it.

This leaves three options for getting DHCP reservations in the box:

1. cross-compile my own firmware (GPL sources and MIPS toolchain are available for download)
2. modify an existing Belkin firmware image by injecting extras in the image
3. hack into the router and modify  configuration parameters to support DHCP reservations.

I decided to see what’s behind door number 3 and after a an hour or two I found two ways of adding your static DHCP leases to the device.

The first way is by modifying he configuration file of the device. You can backup the running configuration from the GUI and save it to your local PC. That backup file (user.conf) contains all nvram parameters to get the router configured. I noticed that it had quite the same parameters as my old linksys router. Especially the parameter static_dhcp_clients was of interest to me. After looking at the linksys example, I filled it up with my dhcp leases :

static_dhcp_clients=hostname1:192.168.20.2:001AAABBCCDD:1:hostname2:192.168.20.3:009988776655:1

After feeding it back to the GUI (restore configuration), the GUI told me the CRC was incorrect. Some trial & error learned me that the check was a CRC-32 (8 bit) check done over all the parameters. This checksum was put at the end of the file in hex. With this knowledge, I opened up my hex editor, changed the checksum, uploaded the modified configuration and after a reboot of the router, I had static leases working!

The second way I found is even easier. There is a hidden web page in the administration website : http://routerIP/wukongjiuwo.html. This is a diagnostics page which gives you web-form based console access to the device. In the console, the following command followed by a reboot should bring static dhcp leases in the box:

nvram set static_dhcp_clients=hostname1:192.168.20.2:001AAABBCCDD:1:hostname2:192.168.20.3:009988776655:1

If you decide to use some of this ‘wisdom’ on your own router, please do so at your own risk!

First of all: No I am not dead and yes I will continue to blog here. I just took a bit of a ‘blogging sabbatical’ the last couple of months.

That said,  I  (and many others so it seems) downloaded Chrome, Google’s vision of a web browser this week and played around with it for a while. A new browser always means new (or old) vulnerabilities and Chrome does not seem to be an exception to this. Google has a pretty good track record in following up on vulnerabilities so they will hopefully fix them soon.

On the positive side, it seems that Google really thought about security in Chrome by isolating processes for different tabs and enforcing a security model. They explain most of it in a cartoon you can find here.

Although I like the layout, the speed and the software design of Chrome, I will not be moving away from Firefox just yet. Even if all known vulnerabilities were to be fixed, there is one feature in Firefox which I think every browser should have and Chrome hasn’t: a decent password manager.

As a security conscious person, I use different passwords for each website I use on the internet. Unfortunately, I can’t remember all of them, so I store some of them in Firefox. I know I could use a tool like KeePass (and I do) but for most sites I find this overkill. Now what I like about Firefox is that you can specify a master password. Without this master password, you cannot unlock the password file (signons3.txt, passwords, and key3.db, the key, in your profile folder). This even survives a copy of the files. When you copy both files to another computer, you still have to specify the master password before getting access to the stored (encrypted) passwords.

Now back to Chrome. The profile data (in Vista)  seems to be stored in C:\Users\username\AppData\Local\Google\Chrome\User Data\Default. There is an SQLite file called ‘Web Data’ in that folder and this seems to contain the URLs and (obfuscated) saved passwords.  Since there is no master password functionality as there is in firefox, this file can be copied to another computer. Doing this gives the other computer access to all websites were there is a password stored for in the file (yups, I verified this).
This might not seem like a big deal but think about it. Every process running on your computer with the same rights as the user (or more) has access to these password storage files. This includes malware as well…

So I’ll stick to Firefox for now

This week, I got my invite for Google App Engine in the mailbox. If you have not heard of it, Google App Engine is a beta product from Google where you can publish your web apps to Google’s massive infrastructure. Currently only Python is supported as a language but Google intends to add other languages in the future.
It seems (I will try when I have more time) really easy to publish your app to their cloud. As an extra advantage, you can use Google’s API for Authentication so you can for example authenticate your users based on their Google Account. For the moment, it is free although some quotas are enforced but I suspect that after the beta period ends, it will be a paying service.

Google is not the first to offer these kind of services. Amazon currently already has a stable cloud platform. They even go further by offering a real computing platform instead of ‘just’ the web application framework.
The advantages of Cloud Computing for businesses are obvious. You get instant scalability and high availability for your application and you pay only for how much you use it without investing heavily in your own hosting infrastructure.

However, security is more than availability alone. There are obvious concerns about the confidentiality and integrity of your data while it lives in the cloud. Is your data private in the cloud? Could it become corrupt? The answers are that you don’t know and that you trust the cloud provider.

Potential vulnerabilities should also be a concern. Google has disabled most of the ‘unsafe’ functions in Python but there are bound to be bugs (and security vulnerabilities) in the applications that developers push to the cloud. Will these affect other applications? Again, you trust the provider.

Or what about abuse of the cloud as such. I noticed Google offers a mail API to send out e-mail. Google is quite a trusty sender of mail so this would be ideal for spammers to abuse. Imagine littering the cloud with web apps which can send e-mail and writing a front-end spam app which sends round-robin spam to all these apps, who deliver mail through the trusted Google smtp engine.

Will these and other security concerns stop the trend to Cloud Computing? I don’t think so. As with all new technologies, there are concerns but when there is a business driver (cheap high availability) you might be able to slow it down but it will not disappear. This is something which not only goes for IT but for most technologies.
The real challenge will not be to list all possible risks to scare people but will be to think about how we will handle this technology securely and how security can be embedded in the cloud. Interesting times I think.

• Preparation
• Identification
• Containment
• Eradication
• Recovery
• Special Actions for Responding to Different Types of Incidents
• Incident Record Keeping
• Incident Follow-Up

I am not going to explain each step of the process as this would take this article too far. I would just like to stress that there is more to it than just eradicating the problem.

The reason why I am stressing on this, is that in most cases, people who are infected with some kind of malware tend to think of only one thing: get the thing removed from their system and carry on. It is interesting to see that most people don’t really care what the purpose of the malware was! And some companies do so too.

Let’s say you were infected with some kind of banking trojan, wouldn’t you want to make sure that your bank account isn’t missing a few euros? And if it was a password stealing malware, wouldn’t it be a good idea to change that password you use at every site you visit?

I am not saying that you should start going through the complete incident handling process every time your non-IT savvy friend’s PCs are infected with the latest spyware but at least keep the incident handling process somewhere in the back of your mind. If it is only one kind of malware, investigate and inform your friend what the malware’s purpose was and what he or she should do with that information. If it is a whole zoo of malware living on your friend’s system, I would not only flatten & rebuild the system but would also give some generic advice on what he/she should do now after the mass infection. This would include basic housekeeping like change passwords, keep an eye on his accounts, etc. I also would give some advice on how to prevent infection in the future and explain how he/she might likely have been infected.

Off course, your non-savvy friend might not understand or even be frightened and you might think that their ignorance is your bliss but I am convinced that without spreading a little awareness, you are fighting a fire with a very limited supply of water.

So how to do this?

1. Upload DD-wrt’s latest ‘VPN’ firmware build for the WRT 54G
2. Generate certificates for the WRT router on the central server (a linux box at my home network in this case which hosts the PKI)
3. Add the following to the central server OpenVPN conf file: route 192.168.10.0 255.255.255.0
4. Create a ccd file with the same filename as the name you chose for the WRT during certificate setup and put the following in the file: iroute 192.168.10.0 255.255.255.0
5. Make sure the WRT syncs its time through NTP. Otherwise certs might be detected as invalid!
6. Paste these certs in the web interface of the DD-WRT and do the basic configuration through the webinterface.
7. Adapt openvpn.conf to my specific setup by enabling the following in the DD-WRT startupscript:

   sleep 20
   echo "auth SHA1" >> /tmp/openvpn/openvpn.conf
   echo "cipher AES-256-CBC" >> /tmp/openvpn/openvpn.conf
   killall openvpn
   openvpn --config /tmp/openvpn/openvpn.conf --route-up /tmp/openvpn/route-up.sh \\
   --down /tmp/openvpn/route-down.sh --daemon

8. Adapt the firewall script to disable natting and accept traffic for the OpenVPN interface on the WRT. Real firewalling will be done on the central linux box

   iptables -t filter -I FORWARD -i tun0 -j ACCEPT
   iptables -t filter -I FORWARD -o tun0 -j ACCEPT
   iptables -t filter -I INPUT -i tun0 -j ACCEPT
   iptables -t filter -I OUTPUT -o tun0 -j ACCEPT
   iptables -t nat -I POSTROUTING -o tun0 -j ACCEPT
   iptables -t nat -I PREROUTING -o tun0 -j ACCEPT

9. Done! Both networks are now interconnected!

It took me some time to get it up and running Saturday but I think that the little hangover I had from a fine party I attended Friday night in Leuven was to blame for that (damn you Cristal beer )

Goodmail offers CertifiedEmail which according to their website does the following:

The Certified Email™ Solution
What is CertifiedEmail?
CertifiedEmail is a premium delivery option for qualifying senders that positively affects email marketing metrics. Once you have been accepted into the program, your marketing and transactional messages become trusted-class email at participating ISPs. Since they know that your email is authentic and comes from a verified sender, these ISPs convey special privileges.

100% Assured Delivery
Spam filters inadvertently send up to 20% of your permission email into junk folders. In contrast, CertifiedEmail is routed automatically to the inbox, past content and volume filters. You get 100% of your email delivered.

Links and Images Rendered by Default
Nearly all ISPs today disable links and images on default as a protection against phishing. CertifiedEmail messages are presented with all images intact and links working. Users can’t respond if they don’t see your email. With CertifiedEmail, they’ll see it.

Special Blue Ribbon Envelope Icon
ISPs specially mark all CertifiedEmail messages with a blue ribbon envelope icon, which tells consumers that your message can be trusted and is safe to respond to. The email you send as CertifiedEmail is visually differentiated from other volume messages. CertifiedEmail is marked with a blue ribbon envelope in your inbox. When you open a CertifiedEmail, you’ll see the blue ribbon envelope icon again – just outside the body of the email message.

It is troubling that large ISPs like Verizon, At&T, AOL and Yahoo are falling for this marketing nonsense. Much of the same arguments are valid against this technology as I mentioned in a previous post about Domain Keys.

Even worse in this technology are the 100% delivery guarantee and the guarantee that images are displayed in the e-mail client. Of course these are handy guarantees if you are a legit mass mailer but two major problems pop up in my mind.

A promise of 100% delivery guarantee is something no one can ever make good. The reason for this is that the sender does not control the final destination (my mail client/mail server). If the receiver has a spam system which does not care about GoodMail, then it falls back on the usual spam detection filters. I wonder how GoodMail’s legit mass mailers will react when they see that the 100% they bought isn’t really what they thought it would be. The same goes for the displaying of images. You cannot guarantee that if you don’t control the end point.

The other problem is the scary thought that some of the CertfiedEmail senders might get owned by a spammer and become zombie hosts in the spammer’s botnets. In this scenario, the spammer will be able to send out CertifiedEmail by using the zombies as a relay point. This would be great from the spammer’s point of view because much of the spam filters get bypassed.

Still not a good solution for the spam issue, it seems.

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).

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.

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.