 |
|
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
David Berlind's Reality Check
By David Berlind
July 1, 2004
When was the last time you were scared to death by headlines about some malware that your system wasn't yet protected against, or worse, for which no reasonable defense existed?
Actually, if you're a paranoid Windows user like me, then you're checking Windows Update every day. Because of how aggressively I patch, and because virtually all the headline grabbers have taken advantage of unpatched systems, most of the news wasn't scaring me to death--until this week's reports of two keystroke loggers; one that neither Internet Explorer nor the best anti-virus defenses were well-prepared for, and another for which a client-side patch existed but was alarming in the way it targeted bank accounts. As it turns out, both of the newly reported exploits took advantage of known vulnerabilities for which patches exist. Unfortunately for users of Microsoft's Internet Explorer, however, one of the vulnerabilities existed in certain versions of Web serving software (version 5.0 of Microsoft's Internet Information Server, which itself is a component of Windows 2000 Server) over which they have no control. In other words, the patches on your Windows-based desktop or notebook could be completely up to date, but with no way of knowing the patch status of the Web sites that you're visiting, you could have ended up a victim.
The first of the two exploits, known now as Download.Ject, allowed hacked Web servers to exploit two vulnerabilities (to which most users of Internet Explorer were vulnerable) that, had the transgression gone unchecked, would have permitted the surreptitious recording and subsequent transfer of your keystrokes to criminals in Russia. Fortunately, Internet engineers blunted access to the offending site shortly after the problem was discovered. Though Microsoft has said that it "is unaware of any widespread customer impact based on Download.Ject," the actual extent of the damage is so far unknown. The second of these keystroke logging transgressions exploited an Internet Explorer vulnerability for which a patch was issued in April, and, where successful, used pop-ups to target 50 banking sites including Citibank, Barclays Bank, and Deutsche Bank. As a result of the publicity received by these transgressions and the way hackers like to prey on my kind of paranoia, phishers appear to have stepped up their activities. This week, my inbox was flooded with forged e-mails that appeared to come from legitimate financial institutions (but didn't) and that reminded me of the recent incursions and advised me to update my accounts (on bogus systems, of course). As a reminder to you, such e-mails are invariably in HTML and have return addresses and hyperlinks that look very legitimate. But, by mousing over the links or by viewing the source code of the HTML (right click on the e-mail's body and click on "view source"), you will see that the true destination of the link is not your financial institution, but rather a non-descriptive IP address or domain name. For example, instead of "yourbank.com," the domain name might say "secureyourbank.com." Whatever you do, do not click on these links. The immediate response from Microsoft to the first transgression was not a patch for its browser, but rather a recommendation to turn up Internet Explorer's security setting to "high" -- a recommendation that, according to a Microsoft spokesperson, would have blocked an attack, but would have also disabled access to any Web site that end users had not explicitly designated in IE as a trusted destination. For most IE users, this would have meant a serious disruption to their browsing experience since very few users have parceled the destinations they visit into trusted or untrusted zones. Microsoft has also said that, because of the way Download.Ject took advantage of a vulnerability in Internet Explorer's Local Machine Zone (the LMZ, a zone that's normally trusted), end users who happened to be running the most recent pre-release version (Release Candidate 2, or RC2) of the forthcoming Windows XP Service Pack 2 (SP2) were protected as well. According to a company spokesperson, "RC2 contains changes to IE's LMZ security zone that helps prevent attackers from using that zone to attack customers. Because of this, customers who were running RC2 of SP2 would have been protected from Download.Ject." RC2, however, is a potential candidate for the final release. Officially, it's still beta and many businesses and consumers are loathe to run beta software on anything but test systems, which means that RC2 cannot presently be considered a prescription for safety. In a moment, I'll explain why Microsoft should reconsider the beta version's candidacy for release as a shipping product. The immediate response from many outside of Microsoft was simply to stop using Internet Explorer and to try alternatives such as Opera and Mozilla. Personally, I've decided to give Opera a whirl. Another solution is moving to Linux or Mac on the desktop. However, like running the pre-release RC2, switching platforms is inconceivable to most users--for many reasons that I won't explore here. Unfortunately, none of these solutions offered me any comfort in that post-headline grey area during which my paranoia began to mount. While these keystroke loggers were on the loose, I realized, I also visited my banking and credit card sites multiple times. Though the odds are I wasn't a victim this time, I'm still not positive that my user IDs or PINs weren't compromised. There's no way to tell for sure. I believe Microsoft will be making a critical mistake if the new and improved personal firewall included with the release version of Service Pack 2 to Windows doesn't have a facility for outbound blocking. (I discussed this same issue in a prior column about why your personal firewall could eventually become obsolete.) In addition to keeping the bad stuff out, a firewall can also keep the good stuff (like your user IDs and PINs) in. Keeping the bad stuff out is the domain of inbound blocking. Keeping the good stuff in is what outbound blocking is all about. As clever as these keystroke loggers were at wriggling into your system, past your ISP, past your anti-virus system, and past IE's already shored up defenses, a firewall that does outbound blocking would have, at the very least, detected the surreptitious attempt to communicate with an offending site and may have even warned you about it. I'm not saying that the hackers can't find a way around this problem as well. But, should your front-line defenses fail to keep something bad from getting in or executing on your system, then your last hope is that an outbound blocking firewall will catch it on the way out. Microsoft is in a difficult position. On the one hand, it doesn't want to come across as a predator, wiping out the anti-virus and personal firewall industries the way its previous OS design decisions have adversely impacted cottage industries, such as the market for memory management utilities. By improving Windows XP's personal firewall, but not making it so good that it walks all over offerings from Symantec, Zone Labs, McAfee and others, Redmond leaves plenty of room for anti-virus vendors, anti-spam vendors, anti-pop-up vendors, and personal firewall vendors (all of which appear to be merging ) to flourish. Microsoft, in fact, will in SP2 include new APIs that promote the deeper integration of these third-party offerings with Windows. On the other hand, in light of these two most recent transgressions, the company can't possibly expect its Trustworthy Computing Initiative to be taken seriously if its own personal firewall neglects to offer what could have been the last line of defense against such malicious attacks. According to Fred Felman, vice president of Zone Labs (makers of the popular ZoneAlarm personal firewall), even if Microsoft puts outbound blocking in its firewall, there's still plenty of room for third-party firewall makers. "Of course there's room," said Felman. "Outbound is important, but the market [for security products] is mature. There are many more demands that users make of their security products beyond this. The missing outbound feature is like a wart on your nose--it's obvious. The real solution is making effective security easy and approachable. Not just pretty." Microsoft needs to either put the brakes on SP2 (which is at Release Candidate 2 stage -- the one that usually precedes official release) or announce that an outbound blocking update will be available within days or weeks of SP2's release. For the second time, I suggested to Microsoft that it may want to reconsider the exclusion of outbound filtering functionality from the new firewall. As of the publishing of this column, Microsoft position remains unchanged since Microsoft lead product manager for Microsoft Windows Greg Sullivan said in April: "the company has no plans at this time to add outbound filtering to Windows Firewall." Referring to the aforementioned APIs, a Microsoft spokesperson said: "Windows Firewall is designed to provide a base level of protection; in some environments, more sophisticated firewalls may still be required. We realize that many customers will still prefer to use a third-party firewall which has this functionality. That is why we've been working with software firewall providers to support for detection of third-party firewall status." "It's also important to note that SP2 is about proactive prevention," the spokesperson continued. "All of the included technologies in SP2--such as the changes in IE to prevent installation of back controls, the changes to prevent scripting attacks, the changes to the way attachments are handled--are around prevention. The changes in Windows Firewall are also there to prevent the machine from getting hacked. Outbound filtering is a way to stop malicious code that's already on the box from doing things. We agree there is some value in that. However, if you have malicious code running on your PC it could just as easily have formatted your hard drive or turned off the firewall altogether. The best defense against malicious code from doing stuff on your PC is to prevent it from entering your PC in the first place." I agree. I wouldn't want malicious code to turn off my firewall or reformat my hard drive. But, I'd rather have my hard drive wiped out than my bank account emptied. If something turns off your firewall, in many cases, you'd be able to tell that it's been deactivated. I'm sticking by what I said last time: Excluding outbound blocking from Windows' built-in firewall is a big mistake. In the name of Trustworthy Computing, what harm is there in adding this feature? You can write to me at david.berlind@cnet.com. If you're looking for my commentaries on other IT topics, check the archives.
What do you think? |
|
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
& Firefox 0.9 
|
|
|
|
|
|
|
|
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
