Patch Tuesday January 2008
Microsoft just released their monthly patches.
It contains:
- one important patch (LSAS, local exploit)
In my opinion, especially important for systems like terminal servers or shared multi-user systems. - one highly critical patch (vulnerability in TCP/IP stack)
The reason why I am writing about this and put the TCP/IP vulnerability in bold is that this is one which goes against the trend. It is a remotely exploitable vulnerability on the network level. A crafted IGMP / ICMP message triggers the exploit. Even Vista is vulnerable out of the box (for the IGMP part, not for the ICMP part).While the trend is moving more and more to 3rd party applications and no longer pure network worms, this is a vulnerability which is perfect to create a network worm. It can be mitigated by classic protections:
<quote from Microsoft>
Firewall best practices and standard default firewall configurations can help protect networks from attacks that originate outside the enterprise perimeter. Best practices recommend that systems that are connected to the Internet have a minimal number of ports exposed. Perimeter firewalls that block multicast traffic (IGMPv3 and MLDv2 specifically) help protect internal network assets from this attack that originate outside of the enterprise perimeter.
</quote from Microsoft>
Another observation is that the past months, we have seen several vulnerabilities for MS Vista. Interesting enough Windows Vista was the first OS to be spawned from Microsoft’s Security Development Lifecycle, a process designed to produce more secure products. Although Microsoft is one of the ONLY software vendors who follows these strict security development and patching guidelines (not even security vendors like McAfee, Symantec,..do so !), it is not perfect yet. But at least, they are already on a good path.
MD5 collisions
MD5 hashes are no longer safe as a hash for signing applications or fingerprinting documents
It is possible (in a ‘chosen prefix attack scenario) to generate identical MD5 hash values for two functional different binaries.
Security software which checks the MD5 signature of an application/document to verify its integrity is no longer to be trusted to provide the correct results.
What about VPNs?
This does not mean that it is now possible to alter the integrity of a VPN connection. Simple reason for this is that in a VPN scenario, data flows continuously over the network and an MD5 hash is only valid for a matter of milliseconds (time the data needs to go from point A->B). It is currently not (yet) possible to alter data, calculate and update identical hashes on the fly. The researchers used a PlayStation 3 with its advanced cell processor to calculate collision hashes as fast as a 30 PC cluster but still it took hours or even days to perform the calculation. Time based security is what effectively protects a VPN in this scenario.
SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 are still considered pretty safe and are mandatory in US federal organizations.However, SHA-1 has been reported broken back in 2005 and it was advised to move away from SHA-1 then as well.
Currently the NSA is considering candidates for the next generation hashing algorithm.
Most likely not. Simple things still work for the average attacker so there is no need for them in investing in this attack scenario. Especially not for infecting the general public and expanding current botnets.
For targeted attacks and corporate/international espionage scenarios, the story is different. There the attacker might go through the difficulties of this attack because the stakes are higher.
Fiber Cable Not Safe Against Eavesdropping After All?
It seems that it is possible to listen to the signal of a fiber cable with a piece of hardware which costs less than $1000.
Organizations where eavesdropping of cables is not an acceptable risk and who have invested in fiber everywhere (instead of EM radiating copper cable) have to make sure that their cabling is physically protected, that encryption is used in every protocol sent over the cable and, if needed, implement a Fiber IDS system.
OpenVPN and Linksys WRT-54G
This weekend, I put a Linksys WRT54G at my sister’s apartment to enable her(and her boyfriend) to share the internet connection. No big deal off course but I also thought it would be nice if the router could act as an OpenVPN client so my network and her network would be securely connected through the VPN. This enables her to pop mail from our mailserver in a secure manner and it enables me to give some remote support by VNC-ing to her computer.
So how to do this?
- Upload DD-wrt’s latest ‘VPN’ firmware build for the WRT 54G
- Generate certificates for the WRT router on the central server (a linux box at my home network in this case which hosts the PKI)
- Add the following to the central server OpenVPN conf file: route 192.168.10.0 255.255.255.0
- 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
- Make sure the WRT syncs its time through NTP. Otherwise certs might be detected as invalid!
- Paste these certs in the web interface of the DD-WRT and do the basic configuration through the webinterface.
- 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
- 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
- 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 
)
VMware server upgrade time!
Since there were some serious vulnerabilities discovered in VMware products lately, it is time to upgrade to the latest releases of their software if you are running it.
I run a VMware server @home on my Core 2 Duo machine to test some OS/configurations without the need of physical machines. In the beginning of this year I needed to replace the hard drive of this machine and since it is a Core 2 Duo I chose to install a 64 bit Debian on the machine as main OS.
Ever since then, I was having strange problems with the VMware server on that machine. It was able to run a windows guest (except if the guest was under high load) but unable to run a linux guest. When I booted a linux guest OS on the server it simply crashed the host. And I do mean crashed, the system was totally unresponsive and nothing was to be seen on the screen or in the logs pointing to a cause of the error. I blamed it on the ‘experimental’ 64 bit support in VMware server although it seemed to run fine on some Xeon systems @work. Anyhow, a virtual machine crashing the host machine is not good! It means that there are some very serious issues in the software which could possibly be exploited for bad.
With the new release out today, I checked the release notes hoping for a clue that my issue was finally resolved. A lot of issues were fixed but my specific issue was not mentioned. A little disappointed, I started the upgrade process from my 1.0.3 to 1.0.4 anyway and it appears to be that I am lucky today because I am now able to run windows, linux and other guests without problems! So the issue must have been resolved by one of the fixes they implemented in 1.0.4!
Certified Mail from GoodMail systems
I read an article today about major US ISPs which are signing up for GoodMail.
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.
Just Another Product Training
After a nice relaxing and sunny weekend with not much IT related activity, this week starts for me with a two day training on ISS SiteProtector. I didn’t receive training yet from ISS in the past so I was curious what the quality of their training would be. It turns out that it is just another boring product training. Time to rant.
I received official product trainings so far, if I remember correctly, for Check Point, BlueCoat, RSA, InfoBlox, Radware and TrendMicro . The only ones who were any good were Check Point and BlueCoat. I would bet that if I follow them now, they wouldn’t be any good either but I was younger, less experienced and easier to please in those days.
The main reason why I am not a fan of product oriented trainings is that every vendor seems to think that a training is no good unless it provides all of the following:
- A trainer who cannot answer all your (sometimes simple) questions (although I must say that the ISS dude does a pretty good job at answering questions)
- Powerpoint slides who contain at least 4 full length (15 words minimal) sentences making them impossible to focus on, let alone summarize the topic.
- Lab exercises which challenge exactly two of my brain cells. Anything which expands on the product’s advanced features and could possibly challenge the trainee is feared by the trainer.
- A certification which you can only take after you took the training.
- A course handout who counts at least 50+ pages per training day and explains everything in a matter my 9 months old nephew could understand.
- At least one co-student who has absolutely no clue about the topic at hand. (Seriously: Thinking that an IPv4 address can end in 256 when you are in an IPS course? Time to think about a career change dude.)
I would much rather prefer to lock myself in a room with a demo (license or appliance) of the product, the manual and play with it myself to prepare for the certification that our vendors demand from engineers. Of course, in most cases you cannot take the certification from the vendor unless you take the training…
The best training I attended so far, apart from my college education, was the SANS GCIH. No surprise that SANS is a vendor neutral training which is not product but technology and business oriented.
Just My 2 cents.
Multi-Touch is the future!
I just saw a video of the new Microsoft Surface Computing platform :
The first multi-touch display which will be available to consumers will be the iPhone but I think multi-touch displays will become the next revolution in input technology. Goodbye mouse and keyboard?
Domainkeys becomes a standard
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
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.