As you no doubt know, the latest Internet Explorer exploit, Download.Ject, escalates security problems to the lose-your-life-savings point for users. Do business with an infected bank site and user keystrokes get logged and sent to a “bad guy” server. Yow!
As of this writing, nobody knows exactly how the Windows-based IIS was infected, except the perpetrators. It appears that even some fully patched servers were affected. Worse still, it’s not clear how to prevent this kind of IIS attack from happening again.
It’s enough to make one start thinking that putting up the familiar notice of “You need IE to access our site” may be a message that could get your company sued.
Don’t trust a site’s end-user license agreement to protect you or your company. It is very likely that the person suing will get a sympathetic jury and an attorney who asks questions like “Did you see the CERT Advisory on Internet Explorer? Did you understand it? Why do you recommend IE to your customers?”
Still, even if your customers command the use of Windows/IIS servers, you can still mitigate their Web site’s risk with the following steps.
First, convert any IE-specific code on the site into code that conforms to the World Wide Web Consortium standards. But first make certain that there is actually true IE-specific code: Check the site with such browsers as Netscape, Mozilla and Opera. Perhaps you’re asking users to use IE when they don’t actually have to.
Next, determine if the site depends on some IE feature, such as ActiveX. Look for workarounds for whatever functionality the server-side IE-specific code is providing. There are dozens of non-ActiveX-based server-side programming environments from which to choose, from J2EE (Java 2 Platform, Enterprise Edition) to PHP to Perl.
For that matter, when a visitor using IE is detected, you might even want to direct the server to respond with a page that says, “To use this site with maximum safety, upgrade your browser to the safer Netscape, Opera, or Mozilla browsers.” If you have a page that says, “upgrade to IE,” kill it and instead use one like we suggest.
Why not just patch the servers? There are good reasons not to automatically download and install Microsoft patches as soon as they are available. Downloading and installing a Microsoft patch may break your system. Changing your computer from a security hazard to an inert hunk of scrap metal may protect your users, but it doesn’t help you get your job done.
Take the MS04-011 patch, which is designed to stop Download.Ject. The patch, by Microsoft’s own admission, includes several showstopping problems.
For example, on both Windows 2000 and Server 2003, the Oracle database service startup process stops responding with this patch. On NT, you can run into the dreaded blue screen of death. In addition, Microsoft knows of at least five other problems. There are workarounds, but you can forget about simply patching your system and getting back to work.
That said, patches must be on your system or you probably will get nailed by the exploits they’re supposed to prevent. However, as MS04-011 shows, you must test them offline before you take them live on your server; otherwise, your server may crash while doing business. If you don’t have a test box, I suggest cloning your current server for this purpose. You can also use the clone as a spare server if you’re pushed for server resources.
Still, until the question of “how does Download.Ject get onto an IIS server box?” is completely answered, nobody can honestly say that an IIS server is securable, or that it’s more secure than the non-Microsoft offerings. After all, if even with a patch we still don’t know how Download.Ject gets on a server, that method will still be usable for other exploits. What other holes like this are in IIS/Windows?
There’s a limit to what problems even Microsoft IIS best practices can mitigate.
Beyond IIS
So, what are the alternatives? If you’re married to Windows, you can still use Apache instead of IIS.
Apache is the most popular non-Microsoft Web server for Windows, and the only one with significant market share. It works on Windows 9.x, NT, 2000 and XP, and Windows Server 2003. Like the better-known Unix and Linux versions, it is also open source and is available as a free download at Apache’s Web site. Support for Apache is available from the usual open-source online sources. You can also get commercial support for either the Windows or Unix environments.
While Apache is not, of course, immune to attacks that are purely based on the underlying Windows operating systems, it is immune to the many exploits that target IIS specifically. In other words, even without moving off Windows, you have another option for a more secure Web server. When the organization is ready for a Unix transition for servers, going from Apache-Windows to Apache-Unix/Linux should be far easier than going straight from IIS.
The major non-Microsoft alternatives are all Unix variants. Developers have put 30 years of work into Unix to make it reliable and stable, and the community of developers behind Linux and the BSD operating systems is far larger than even Microsoft can afford.
There are many Linux distributions. Red Hat Inc. has the lion’s share of the Linux market, according to U.K. Web analysis firm Netcraft Ltd., with 49.8 percent.
Like Windows, any Linux distributions must be secured by downloading patches. Unlike Windows though, you’ll only have to download those patches that relate to operating system components or applications actually running on your system. You should also follow the advice available on such open-source security sites as Linux Security and SecurityFocus.
A few Linux distributions, including Trustix, Immunix and Bastille, are specially designed for secure operation in hostile environments.
Contrary to popular belief, both user community and commercial support are available for most Linux servers from Red Hat and other Linux distributors such as Novell/SuSE and Mandrake.
Is it a lot of trouble to switch over to Linux? For your complete enterprise infrastructure, yes, it would be. But for Web serving, few infrastructure changes would be easier and, given the latest trends in Windows-related security problems, perhaps few things would be smarter.
Check out eWEEK.com’s Security Center at http://security.eweek.comfor the latest security news, reviews and analysis.
Be sure to add our eWEEK.com developer and Web services news feed to your RSS newsreader or My Yahoo page