In-Depth

Get Serious About Securing IE

Internet Explorer is one of the most used products in nearly every environment, but most administrators know little about how to tune it for best performance and safety.

• By Greg Shields
• 10/01/2005

If you're a Windows shop, you're more than likely an Internet Explorer shop, too. Love it or hate it, you're responsible for keeping IE running. That's not an easy job, because IE doesn't play fair—full of holes and easy to hack, IE can be your network's biggest vector for infection. Add in a pinch of spyware sending off your personal information to who knows where, a dash of adware popping up ads every third mouse click, and it's understandable how IE got such a bad reputation.

Despite its from-the-other-side-of-the-tracks standing, it still has to be controlled. And because it flies so low under the radar, it's easy to forget how vital a part of your network infrastructure IE is. It's a major management challenge, but most admins pay it only lip service in their day-to-day work. That's a mistake, and failing to correct it could lead to disaster. Take control. Now.

Marching in Step
Your first line of defense against IE's issues, holes and vulnerabilities is central control. IE has one major advantage over many of the freeware browsers—it's easy to centrally control using Active Directory. With AD locking down IE's configuration, you'll limit your users from damaging themselves and your network.

In order to do this, you'll need to create a Group Policy. Here you have a choice for your IE Lockdown Group Policy Object (GPO). Depending on your network's characteristics, you might link it to a user or workstation GPO.

For example, if your users don't have dedicated computers and their user accounts are split into separate GPOs by function, you might consider configuring IE settings per user. In this situation, you could have multiple IE Lockdown GPOs, depending on the class of user. Power IE users get a lightly locked-down GPO, while problematic users get one screwed down tight.

In a typical office environment scenario where users have dedicated machines and everyone falls under a similar Internet Use policy, you'll probably link the GPO to your Workstations OU.

Either way, IE includes settings in HKEY_LOCAL_MACHINE as well as HKEY_CURRENT_USER, so the GPO you create will involve elements from Computer Configuration as well as User Configuration. If you link your IE Lockdown GPO to a Workstations OU, make sure to enable the policy User Group Policy loopback processing mode so User Configuration policies get applied.

There are three main locations within Group Policy where IE is centrally configured.

• Computer Configuration | Administrative Templates | Windows Components | Internet Explorer
• User Configuration | Windows Settings | Internet Explorer Maintenance
• User Configuration | Administrative Templates | Windows Components | Internet Explorer

The second location is the most important for central configuration, the third for securing the browser. Make sure whenever adjusting these settings to test them in a separate OU prior to rolling them out; it's possible to inadvertently lock down IE such that Web sites don't function at all.

How To Bury IE If your network environment is highly sensitive to Web-based intrusions, or if you want to eliminate IE altogether, you can prevent it from even running. Do this with a Software Restriction Policy: >> Create a new GPO and link it to your desired OU >> Right-click Computer Configuration | Windows Settings | Security Settings | Software Restriction and choose New Software Restriction Policies >> Under Additional Rules, select "New Hash Rule …" >> Navigate to IEXPLORE.EXE and hash the file. Set the Security Level to "Disallowed" Before taking this Draconian measure, consider the following: >> Some applications require IE, so you should test this change thoroughly prior to implementing it. >> When Microsoft releases cumulative update patches for IE, be aware that the patch might change the file hash. You may need to re-hash the file after patching to maintain the software restriction. >> Microsoft best practices suggest keeping all Software Restrictions in a separate GPO. This allows the policy to be separately disabled from all other policies in case of emergency. >> Be careful if you set the Default Security Level to Disallowed. This automatically disables all software except where specifically allowed. — G.S.

Lance the PUS from IE
So, you've centrally configured IE on your network. You've done your best to secure it against external attack. But the baddies still make their way in, clogging processor cycles and transmitting personal information to the world's product marketers or worse.

Let's shift gears for a moment and talk about adware, spyware and malware, a class of software Microsoft calls Potentially Unwanted Software, and we'll shorten to the wonderfully appropriate acronym PUS. Numerous automatic tools like LavaSoft's AdAware, Safer Networking's SpyBot Search & Destroy, and Microsoft's AntiSpyware Beta exist to assist you with removing the PUS from your system, but at present none do the job without help. PUS removal often requires multiple removal tools to completely eliminate it from your system.

This is due primarily to two problems. First, the behavior of PUS is different than viruses. It isn't necessarily destructive, and sometimes isn't even illegal; this makes it difficult for the PUS hunters to identify a scannable behavior. Second, partly because of its not-quite-illegal nature, PUS writers in the wild are writing spyware code faster than anti-spyware vendors can keep up.

Until the scanners get better, good systems experience and knowledge of the processes that should and should not be a on a system can supplant those developing tools. With a little skill and some knowledge of how the Windows OS works, you can become your own PUS scanner.

Can you tell the corrupted system from the uncorrupted system in Figure1?

Figure 1. The system on the right has many more processes running than the one above a strong indication that it’s infected by spyware and/or adware. (Click images to view larger versions.)

In this example, it's relatively easy to tell that the Task Manager on the right shows quite a few additional processes that don't belong on this system.

You should have some basic understanding of the applications on your workstations and the processes that make up those applications. You should also have a baseline for the apps on your network—any applications not on your baseline shouldn't be on your network.

The Nuclear Option
Performing a search-and-destroy mission for unsightly PUS is easier with the right weapons. Add these free tools to your arsenal and make it much easier to identify and eliminate rogue processes and inappropriate auto-start apps on a system. (These types of tools aren't offered natively by Microsoft. Also note that they're manual, but currently they're the best way to clean up the mess).

The first of these is the Task Manager on steroids: the Windows Process Explorer by SysInternals. The Windows Process Explorer, shown in Figure 2, lets you not only see the processes currently running on your system, but the Registry keys and files currently touched by those processes.

Figure 2. Sysinternals' Windows Process Explorer provides rich information on each running process, its associated files and Registry handles. (Click image to view larger version.)

Right-clicking a process in the Windows Process Explorer shows the properties of that process, including its path and command line. You can quickly kill the process from the properties window or even link to Google for more info.

But killing the process only stops the PUS for a little while. You also need to determine from where it's being launched. Our second SysInternals tool, called Autoruns, assists with this process.

Autoruns identifies each of the locations where a process is set to automatically run, either at login or startup. For each process you can view properties of the process and delete its Registry reference right within the tool. For each process, the code signature can also be verified. Because most PUS doesn't include signed code, it's relatively easy to run the tool and search for any lines with a blank or "Not Verified" entry in the Publisher column.

Note that Autoruns doesn't delete the process executable, so you'll likely want to delete the offending program after removing its Registry reference to eliminate it completely.

The third terrific tool for manual PUS elimination is directed specifically at users of IE. Developed by Merijn Bellekom, who calls himself "a student in the Netherlands that codes in his free time," his tool "HijackThis" has a growing following. The freeware tool, downloadable at www.merijn.org, detects differences between the characteristics of your current IE installation and that of a default IE installation. By showing what changed between the default installation and your installation, you can determine what should and shouldn't be there.

Figure 3. HijackThis shows you what’s changed between a current version of IE and a default version. (Click image to view larger version.)

In a Redmond interview with Bellekom, he said "There are only so many places a parasite can hide on your system, and HijackThis just lists those places. This means it's fairly easy to maintain since there's no database of known baddies to keep up-to-date. It only needs an update when the hijacker programmers come up with a new trick to install, hide and start their stuff."

Running HijackThis against an infected machine shows a number of differences, as you can see in Figure 3. Some of these instances, like the changed home page, are legitimate; some are not. For each change, the item can be fixed.

Be careful when choosing to fix anything noted in HijackThis. As any legitimate changes are identified along with the ones made by PUS, you can fix something that didn't need fixing.

Pull out the Hooks
So far we've focused strictly on processes and how to eliminate them, but there's more to the problem of PUS. Many of IE's insecurities stem from the browser's design that allows other apps to "hook" into it. This application hooking is handled by Browser Helper Objects, or BHOs. Originally designed as a mechanism to extend IE's capabilities, these BHOs are how spyware apps like Claria/Gator and CoolWebSearch operate with System-level permissions.

Depending on how they're coded, when IE launches or attempts to pull down a Web page, a BHO can be activated. It's this BHO code that causes pop-ups, slowdowns and personal information disclosure.

Knowing a little about BHOs will help you understand how to eliminate them. In the HKEY_CLASSES_ ROOT key of your system's Registry are the class IDs (CLSIDs) that uniquely identify software components of your system. Like other system components, a BHO has to register itself with your system; it can therefore be identified by its CLSID.

Kill Bit, Vol. 1
Microsoft Knowledge Base article 240797 discusses CLSIDs and something called the "kill bit." This bit is an associated Registry entry for each CLSID that tells the system to never run the code associated with that CLSID. This effectively prevents the BHO from ever starting. To set the "kill bit," create or configure the Registry key Compatibility Flags with the REG_DWORD value 0x00000400 at this location (see Figure 4):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the bad BHO

"Great," you say. "Now I know how to kill the PUS, but there are hundreds of CLSIDs on my system. How do I know which are PUS and which will stop key system services from running?"

Therein lies the crux! Finding them is difficult. However, another tool exists that removes the guesswork.

Navigate to www.spywareguide.com. This site keeps an up-to-date list of known PUS CLSID identifiers—a total of 717 at the time of this writing. It also maintains a downloadable .REG file that allows you to apply the "kill bit" to all 717 at once. By downloading and installing the .REG file, you can prevent known PUS from even installing on your system.

Double-clicking the .REG file automatically sets the "kill bit" by presetting the Compatibility Flags key to 0x00000400 for each known bad CLSID. Kill bit set equals "goodbye BHO." There is an accompanying uninstall .REG file to double-click if you need to back out.

Note that because the .REG file creates the registry keys and "kill bits" for each known BHO—even the ones not previously present—which will prevent any previously unseen PUS from starting when encountered in the wild. With a little scripting, you could turn this into a Group Policy to push to all your machines.

Figure 4. Browser Help Objects and class IDs can be set to never run with a simple Registry hack. (Click image to view larger version.)

It's a Wild World
We'll probably never get rid of IE, but we can secure it the best we can and learn the tricks to clean it when we must. Oh, and if it helps, feel free to swat the next user that clicks "Yes" after re-enabling pop-ups on their XP SP2 machine. It'll make you feel better.