General: July 2008 Archives

Happy sysadmin's day.
As usual I'm not in the office on sys admins day. (the last Friday every July). I can only assume the guys that are in today are being showered with gifts.

So Donna thinks that PC World is a victim of DNS Cache Poisoning.

What is the attack here? pcworld.com DNS resolves to 70.42.185.10 which according to an IPWHOIS is their IP address.

So what if removespyware.ru resolves to the same address. Unless they can modify the routing, I dont see what they've accomplished other than getting Donna to add the IP the Outpost firewall blacklist while invoking the name Dan Kaminsky.

If a site "malware.r.us" has a reputation for serving malware, and they change their DNS to resolve that URL to my website, why should my website be blocked. The biggest security problem here is the denial of service instigated by the Outpost personal firewall against a innocent website.

I guess when you're looking for a DNS cache poisoning attack, everything looks like a DNS cache poisoning attack.

I've seen more than a handful of snarky posts linking results from http://www.doxpara.com's DNS tester and complaining that their ISP is still vulnerable to DNS attack mere days after the patches were released.

The Verizon Business Security Blog has some good comments and reports they have recommended to their customers to patch within 30 days.

No not this one. I'm just falling into the classic blog trap of making a cutsey title rather than a descriptive one.

I've been thinking a bit about birthdates and identity theft. What is it they're going to do with my birthdate? I don't know but apparently I'm supposed to be afraid of anyone having data about me (watch out for Google) even if the data isn't personally identifying.

Sophos reported yesterday a bugin a beta version of Facebook (since fixed) . It would display the date of birth even when it was marked as private.

You've all heard of the "trade your password for a chocolate bar" test. Apparently many people are failing the "trade your date of birth for a scoup of ice cream at Baskin Robins" test.

I guess I'd rather have my friends wish me happy birthday on the right day. I'd rather not have to remember which day my fake birthday is so I can get my free scoup of ice cream. I'd rather not get busted for phony documents because I need a ID with my fake birthday on it to get a free meal (the the purchase of a second meal) at Texas de Brazil (coupon required).

Firefox 2.0.16 and 3.0.1 is out to fix the following security vulnerabilities.

MFSA 2008-35 Command-line URLs launch multiple tabs when Firefox not running
MFSA 2008-34 Remote code execution by overflowing CSS reference counter

UPDATE - looks like 3.0.1 isn't out just yet. Keep your eyes open for it. http://www.mozilla.org/security/known-vulnerabilities/firefox30.html

Secunia PSI has been alerting on a vulnerable version of zlib.dll in many of my applications on my home computer. In a security writeup from July 2005, Secunia reports

a vulnerability in zlib, which can be exploited by malicious people to cause a DoS (Denial of Service) against a vulnerable application.

The vulnerability has been reported in version 1.2.2. Prior versions may also be affected

This doesn't bother me so much when it is detected in old versions of Taxcut installed on the computer, but when it is reported in Wireshark 1.0.1 (not sure if this is fixed in Wireshark 1.0.2) and the latest version of iTunes, I wonder what the deal is.

UPDATE - See the comments, this is actually fixed in Wireshark in spite of the Secunia detection.

I renamed the old dll and replaced it with the latest version from http://www.zlib.net/. Secunia is happy, and it didn't seem to cause any issues with the applications.

Symantec has added device control in Symantec Endpoint Protection 11 (SEP11) MR2. This can be used to disabled wireless cards when connected to a wired connection.

Symantec has a KB article that explains "How to block all Wireless traffic when an Ethernet interface is active using Symantec Endpoint Protection 11.x"

Unfortunately it is not possible to disable all wireless cards automatically. Each wireless card has a device ID. You need to determine the device IDs to block. For me, I went into SMS to determine how many different wireless adapters are in use in the enterprise. Next, I used SMS to find online computers with each make/model of card. I followed the instructions in the Symantec KB to gather the device ID from the registry and add them to the block list. You'll have to ask the helpdesk to let you know when new wireless cards start showing up. (occasionally check SMS to double-check).

My biggest problem was that their KB described two locations - wired and wireless. That is the most vanilla configuration possible and it assumes you don't have any other firewall profiles. Most people I suspect are going to already have location profiles set up for their firewall rules. I already had CorporateLAN, VPN and External configured. To integrate this KB into my existing rules, I setup locations CorpLan-Ethernet, CorpLan-Wifi, VPN, External-Ethernet, External-wifi and default.

So far its working great in testing, and I plan to role this out to a larger group of testers after I make a couple changes. It is really exciting to be on the cusp of solving a security issue that has been lingering for years, that is the problem of wireless cards looking to make a connection even as the wired card is active on our corporate lan.

Today I went to check something on the condo association website and found the page was filled with ads. No, they weren't the latest SQL injection victim. They let their domain expire. If you have domains, you better make sure that you know when they expire so that doesn't happen to you.

If you do webdesign and you aren't offering full service for the non-technical, make sure you dont just set up the page and run. Your customers need to have the passwords to make changes, and they know when renewals need to occur.

Fortunately for the condo association, they didn't have that domain on all their stationary. Because they did a poor job of promoting the site in general, it will be easy to start over with a new domain name. Imagine if that occurred to your business domain name.

The latest Symantec IM Manager includes support for AIM 6.8. This is kind of a big change because previously there was no way to support AIM clients that required SSL logins.

AIM has provided a method whereby we register our domain names with AOL, so when the AIM 6.8 client attempts to log in, AOL directs the client to our internal IM Manager server. As part of setting this up I purchased a SSL cert for my IM Manager server. The client connects using our certificate, therefor the IM Manager server is still able to apply security and perform logging as appropriate.

This support is not retroactive to AIM Pro clients. In fact, I'm told that although this was originally designed for AIM 6.5 as well, AOL made some changes that aced out that client.

I'm not sure I trust AOL not to make major changes again and leave AIM 6.8 installs in the cold. But it is better than being stuck with incredibly old versions of AIM.

Is there an ethical and legal issue here as well? While users are advised that this is our network and our computers, might they argue that they have a reasonable expectation of privacy since AIM is using SSL?