Audit security hotfixes

I'm sure that most of you subscribe to the Microsoft Product Security Notification email list, so you know that hardly a week goes by without a new bulletin. During crazy weeks, you might receive notice of three or four hotfixes that you need to install. When you're responsible for tracking, evaluating, and eliminating vulnerabilities for multiple platforms and applications, staying current with all these hotfixes can be overwhelming. Collecting, deploying, and tracking the hotfixes on generic workstations and servers as well as on the Microsoft IIS and SQL Server systems throughout your enterprise is a demanding job. Microsoft's new Hfnetchk utility can help you get the job done, although it isn't the perfect solution for large networks.

New and Improved
Until recently, Qfecheck was the only Microsoft tool that could help you determine which hotfixes were installed on a system. Qfecheck is a rudimentary utility that audits hotfixes on the local system. Although you can install the utility on a network share so that users can access it, you can't redirect Qfecheck to audit a remote machine—a restriction that severely limits the tool's value in a network environment of more than a few systems. Also, Qfecheck can't determine whether an update is specific to the OS, to IIS, to Microsoft Internet Explorer (IE), or to other applications. Perhaps Qfecheck's most glaring omission is that it can't advise you whether you truly need to install a hotfix or simply implement a work-around to ensure that your systems are secure by current standards.

Microsoft has been aware of Qfecheck's shortcomings for some time. In August 2001, the company attempted to address some of these limitations through the release of Hfnetchk, a new hotfix audit and advisory tool that greatly extends your ability to manage security hotfixes. The core of Hfnetchk's improved functionality is a new XML-format security-hotfix catalog, mssecure.cab. This catalog contains a comprehensive list of every security hotfix and workaround that Microsoft has released for its most popular platforms. Each time Microsoft releases a new security hotfix, the company updates mssecure.cab. Hfnetchk 3.1 uses this catalog to track security updates for the following products:

  • Windows 2000 (including Service Pack 1—SP1—and SP2)
  • Windows NT 4.0 (including SP1 through SP6a)
  • NT Server, Enterprise Edition (NTS/E —including SP4 through SP6a)
  • SQL Server 2000 (including SP1)
  • SQL Server 7.0 (including SP1 through SP3)
  • Internet Information Services (IIS) 5.0 and Internet Information Server (IIS) 4.0
  • IE 5.01 through IE 5.5 (including IE 5.5 SP2)
  • Microsoft Data Engine (MSDE) 1.0

The one product Hfnetchk doesn't track is Microsoft Exchange Server. Given that Exchange is deployed all over the world, I hope that the tool's developer, Microsoft Gold Certified Partner Shavlik Technologies, will include Exchange coverage in the tool's next version.

Getting Started
You can download Hfnetchk from the Microsoft Download Center (http://www.microsoft.com/downloads/release .asp?releaseid=31154). Each time you start Hfnetchk, it attempts to download the current version of the hotfix catalog file, mssecure.cab. When you're auditing one or only a few systems, the catalog download is convenient. When you permit users to audit systems independently, however, you might want to keep a local copy of the catalog file to eliminate unnecessary download activity and to speed up auditing. The instructions in this article assume that you're using a local copy of ms-secure.cab.

You can manually download ms-secure.cab from http://download.microsoft.com/download/xml/security/ 1.0/nt5/en-us/mssecure.cab. When you run Hfnetchk, use the–x command-line option to instruct the utility to use the local catalog copy. Microsoft releases security hotfixes nearly every week, so you'll need to download the catalog at least weekly to ensure that Hfnetchk's audit provides the most current results.

After you download the catalog file, you can use the File Signature Verification (sigverif.exe) tool to verify that the file contains a valid Microsoft signature. Open a command prompt and run sigverif.exe to open the tool's GUI. Click Advanced, then click Browse and navigate to the location in which you placed mssecure.cab. As part of the verification, the sigverif.exe checks the certificate revocation list (CRL) at Microsoft to ensure that the signature is valid.

After you verify the signature, double-click the Hfnetchk download file (i.e., nsch.exe) and the catalog download file (i.e., mssecure.cab) to expand them into individual files, then place all files from both downloads into the same directory. Hfnetchk expands into three files: readme.txt; hfnetchk license.txt, which contains the license text; and hfnetchk.exe, which installs Hfnetchk. Mssecure.cab expands into one file: mssecure.xml.

Open a command prompt and change to the directory in which you stored the files. I suggest you start Hfnetchk in its default mode but use the tool's –x option to direct Hfnetchk to use the local copy of the catalog. As you get comfortable with how Hfnetchk works, you can add other options to fine-tune auditing and reporting. (Table 1 lists Hfnetchk's available command-line options.) To run Hfnetchk with default settings, type

hfnetchk –x mssecure.xml

This command produces a report similar to the one that Figure 1 shows. (I added the hotfix names and descriptions to the report file as I researched and downloaded the appropriate updates.) You can save the report to a text file so that you can refer to it later. For example, to save the report in a text file called hfxaudit.txt in the same directory as Hfnetchk, type

hfnetchk –x mssecure.xml >hfxaudit.txt

To save the same report on a network share (named Audit in this example), type

hfnetchk –x mssecure.xml>\\ Audit\hfxaudit.txt

Auditing Hotfixes
You can't instruct Hfnetchk 3.1 to audit only OS hotfixes or hotfixes specific to SQL Server or IIS. When you run the utility, it audits and reports on missing hotfixes for all products that Microsoft includes in the catalog. When I ran Hfnetchk on my combination firewall/ VPN server, for example, it reported on missing hotfixes for the current OS (i.e., Win2K SP2) and my version of IE.

Microsoft packages most security hotfixes with the hotfix.exe installer. When you install a security update, the installation procedure expands the download file into multiple files, one of which is the hotfix.exe installer. When hotfix.exe runs, it creates an uninstall directory in the system root and places the expanded hotfix files in that directory. The name of the directory is the same as the Q number of the Microsoft article that references the hotfix. You'll find hotfix.exe, along with one or more .exe, .sys, or .dll files, in most of the Qxxx directories in the system root. Hotfix.exe also creates a matching registry subkey with the same Q reference number. The installer creates this subkey in one of two places: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Current Version\Uninstall or below the appropriate product subkey in HKEY_LOCAL_MACHINE\SOFTWARE\Micro soft\Windows\Updates.

When you use Hfnetchk to audit security hotfixes, the utility reports that a hotfix is properly installed only when three conditions are met. First, the hotfix registry subkey must be present. Second, the version number of each file included in the hotfix must match the corresponding catalog entry. Third, the checksum of each file must match the checksum of the catalog file. If any of these conditions isn't met, the utility reports the hotfix as not installed.

Hfnetchk's False Alarms
In several situations, Hfnetchk can erroneously report a hotfix you installed correctly as not installed. These situations reflect inconsistencies in how Microsoft packages and installs security updates.

No registry subkey. Some hotfixes (specifically those packaged with Microsoft Data Access Internet Publishing Provider—MSDAIPP) don't create the expected registry subkey. To correctly interpret Hfnetchk's audit report, you need to know which security updates omit that step—but Microsoft doesn't document that information. To avoid receiving reports for hotfixes that don't create a registry subkey, you can use Hfnetchk's —z option to instruct the tool to skip the registry-subkey verification step for systems on which you've installed old or nonstandard updates. When you use this option, however, Hfnetchk skips the registry-subkey verification step for every hotfix.

MSDAIPP. Microsoft occasionally releases hotfixes that use a different installer: the MSDAIPP. This installer doesn't follow hotfix.exe's system-root and registry-subkey conventions and doesn't force a system restart. Thus, when you audit a system after you apply updates that use the MSDAIPP installer, Hfnetchk reports the patch as not installed. The WWW Distributed Authoring and Versioning (WebDAV) hotfix in Microsoft Security Bulletin MS01-022 is a good example of this problem. The first clue that the hotfix is a nonstandard update is that the name of the download file, rbupdate .exe, doesn't follow the Q-number naming convention. (Be aware, though, that even some download files that follow that convention—e.g., the IE post-SP2 update file q295106.exe—use MSDAIPP.)

You can identify a hotfix's installer by extracting the individual components in the download file. All updates that use hotfix.exe contain that file in the extract directory; updates that use MSDAIPP contain one or more files named msdaipp in the extract directory (e.g., after I expanded the WebDAV update, I found msdaipp.10 and msd aipp.15 in the extract directory). The fastest way, however, to determine which installer a security hotfix employs is to open a command prompt and type the name of the hotfix download file followed by a space, a backslash, and a question mark (e.g., rbupdate /?). When a security update is packaged with hotfix.exe, you'll see the output that Figure 2, page 3, shows. When an update is packaged with MSDAIPP, you'll see the output that Figure 3, page 3, shows.

To be absolutely certain you've installed MSDAIPP-based updates, you must manually verify that those files have the correct date, version, and checksum. (And no, you aren't the only one who thinks this is an unnecessary waste of valuable time.)

Auditing Remote Systems
Hfnetchk's strength lies in its ability to audit remote systems. To identify the systems you want to audit, you can provide the tool with an individual system's NetBIOS name or a list of names (to audit multiple systems), a list or range of TCP/IP addresses, or a domain name (to audit all systems in the domain). If you identify the systems by name or domain membership, Hfnetchk must be able to resolve the computer names with NetBIOS, even when you're running only Win2K systems. (In a mixed Win2K and NT 4.0 environment, you already use NetBIOS over TCP/IP—NetBT—to ensure that legacy systems can communicate.) You can use one of several options (i.e., –h, –i, –r, and –d) to instruct Hfnetchk to audit multiple systems.

For example, suppose you want to initiate an audit of three workstations and a server. You can use the –h option to tell Hfnetchk to locate and audit the systems with the specified NetBIOS computer names:

hfnetchk –x mssecure.xml –h \\<system1>,
\\<system2>, \\<system3>

You can use the –i option to tell the utility to perform the same operation on the systems with the specified TCP/IP addresses:

hfnetchk –x mssecure.xml –i 10.1.1.100,
10.1.1.101, 10.1.1.102, 10.1.1.254

You can use the –r option, which is the preferred method to use on a DHCP-based network, to identify a range of TCP/IP addresses to scan. Simply give Hfnetchk the same address range you use in your DHCP server:

hfnetchk –x mssecure.xml –r 10.1.1.100
–10.1.1.102, –h 10.1.1.254

When you audit multiple systems, remember to pipe the output to a file so that you have a permanent record of the audit.

The –d domain_name option instructs Hfnetchk to locate and audit every system that belongs to the specified domain. For example, suppose you have a domain called Engineering. To audit all computer domain members, type

hfnetchk –x mssecure.xml –d engineering

Hfnetchk requires NetBIOS name resolution to locate the computers that belong to the domain. The tool's documentation states that to use this method, your network must permit UDP port 137 traffic (i.e., NetBIOS Name Service—NetBIOS-NS), so you can't use this option if you disable NetBIOS-NS for security purposes.

Other Useful Options
As Table 1 shows, Hfnetchk supports many useful options. You can combine several of these options in one command. For example, suppose you're using a local copy of the catalog and you want a verbose report that lists only the necessary hotfixes. Type

hfnetchk –v –a n –x mssecure.xml

The syntax is ugly, but it works. The Microsoft article "Microsoft Network Security Hotfix Checker (Hfnetchk .exe) Tool Is Available" (http://support .microsoft.com/support/kb/articles/ q303/2/15.asp) contains a fairly detailed description of Hfnetchk command-line options, and the partner Hfnetchk FAQ "Frequently Asked Questions about the Microsoft Network Security Hotfix Checker (Hfnetchk .exe) Tool" (http://support.microsoft .com/support/kb/articles/q305/3/85 .asp) answers many questions about how the utility operates.

Expediting Hotfix Installation
We can dream about a utility that not only identifies needed hotfixes but also downloads the missing patches—but we aren't there yet. You need to read the security bulletin for each hotfix that Hfnetchk identifies as not installed to determine whether you need the hotfix on the audited system. Even though scanning one bulletin takes only a few minutes, reading and collecting all the missing pieces for Win2K, NT 4.0, IIS 5.0, IIS 4.0, and SQL Server can take a day or more.

You can find a current list of security bulletins, by number, at the Microsoft TechNet Security Bulletin Search site (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/security/current.asp). When you've identified and downloaded the updates you need, collect all the hotfixes for a specific product in one directory. For example, you might create a hotfix directory with three folders, one for Win2K, one for NT 4.0, and one for SQL Server 7.0. Because multiple hotfixes sometimes contain different updates of the same executable or DLL, standard protocol requires a reboot after you apply each fix to ensure that the OS installs the most recent version of any common files. However, you can use Microsoft's Chain (qchain.exe) utility to safely install multiple hotfixes without rebooting after each hotfix.

Qchain examines all the files that each update replaces and ensures that the OS installs the most recent version of any OS components that are common to more than one update. Run each hotfix.exe update with the hotfix .exe –z option (to disable the automatic reboot after installation) and –m option (to disable interactive feedback). If you have any updates that use the MSDAIPP installer, run these updates with the /q switch, which disables interactive feedback. (The installers use different options—another reason you need to determine how Microsoft packages each hotfix you want to install.) Run Qchain after you install all the hotfixes (or any other updates, for that matter) but before you reboot. Then, when you restart the system, Qchain ensures the OS loads only the most recent version of every updated file. You can download Qchain from the Microsoft Download Center (http://www.microsoft.com/downloads/ release.asp?releaseid=29821).

Running Qchain interactively is practical when you need to install one or two hotfixes. If you have a big list, though, using a script to automate the process is probably faster and more convenient. Figure 4 shows a script that I used to install multiple hotfixes for Win2K and IE. Each update that hotfix.exe installed used the –z and –m options; updates that MSDAIPP installed used the /q switch. I invoked Qchain with an argument that identified the text-based log file (i.e., d:\temp\qchain\hotfx.log) that permanently records the files the update replaced.

A Work in Progress
Hfnetchk is a great improvement over its predecessor, but you're still faced with a labor-intensive procedure. You must use the tool to run a preliminary audit (either interactively or from a script), download needed updates, examine each update to determine which installer it uses, write a script to install the updates on each system, use Hfnetchk to run a final audit, then verify the status of any hotfixes that Hfnetchk still reports as not installed. If you're responsible for thousands of systems, you're probably better off with more sophisticated third-party utilities such as those available from Shavlik Technologies, St. Bernard Software, or Gravity Storm Software.