Auditing Patch Management

John needed a way to track and produce management-style reports on patches across his enterprise. Roberta to the rescue!

• By Roberta Bragg
• April 01, 2003

I was about to leave the office for the day when he arrived, unannounced, and sat down. “Ms. Bragg,” he said and, then, with a quick intake of breath, stopped. Perrin, my 20-pound alley cat, jumped into his lap and perched there, a paw on each of my guest’s shoulders. For a minute, Perrin held the man in thrall and, then, feline judgment served, left as quickly as he came. This one’s not a threat, he was telling me—help him.

“Sorry” I muttered, as I flipped Perrin a treat. He caught it in midair and, with a look and a growl at my visitor, disappeared behind the wall of CD-ROMs that separates front office from server room. “I’m afraid Perrin thinks he has to protect me from the outside world, though I can usually keep him from drawing blood. Call me RB. How can I help you?”

“Well,” he began, while brushing cat hairs off his shirt and passing me a business card that told me his name was John. “Management wants to know if what we’re doing to secure our network is working, and I’m not sure I can rely on the reports that IT is providing.”

“Can you be a little more specific?” I asked.

They keep telling me what they do and not what is. For example, I get reports on how many machines now have Service Pack 3 and how many patches they’ve approved for distributing to them. What I don’t get is any proof that the patches are actually being applied. ‘Trust me,’ they say, ‘We add the patches to the server, the clients connect, download them and install them.’ Case closed. Isn’t there some way I can easily verify that systems are patched? Isn’t there some way I can print out a list of systems that aren’t? Can I identify which systems don’t have which patch? That way everything is up-to-date, and I’ve got my proof for management reporting. If it’s not, well, I guess it’s a way to make sure it gets done.”

“That,” I answered, “I can help you with.” I built a demo using Microsoft Security Baseline Analyzer (MBSA) 1.1 and Microsoft Access. We tested it on his network. It gave him the information he wanted, and IT a way to check up on the success of the patching system. They’re finessing it now into a proper tool, but I can provide you with the basic information you need to build your own.

HFNetChk, the command-line patch detection tool written by Shavlik for Microsoft, provides a quick way to determine if basic Windows 2000 systems are up-to-date on patches. MBSA puts a friendly face on it and adds assessment of several other security best practices. It puts all the data in a pretty report. After its release, four problems with MBSA quickly emerged:

1. You need the tool to view the reports.
2. Each report covers one computer. You can scan many computers from one, but there’s no report consolidation.
3. Report details, especially on specific patch status, are confusing.
4. Many, even those charged with managing systems, can’t take the time to read the documentation and use it appropriately.

The first two issues are covered below, and I’ll show you how to make a report that consolidates the patch information from multiple computers into a database from which you can create helpful reports. The third issue requires reading and interpreting the “note” provided with some fixes marked as “not found.” The notes explain why you might get a false alarm. Once you determine the cause, you may want to suppress that check during future scans. The fourth issue is one that requires its own tutorial; unfortunately, its audience would never read it.

Before we create that database of systems and patches, we need to talk about MBSA. The information here is specific to version 1.1.

MBSA can be a simple tool used to evaluate security status of any Windows NT 4.0, Win2K, Windows XP or Windows Server 2003 computer. It can be installed on and used directly on some systems and remotely on others. (Tables 1 and 2 show installation requirements for local and remote systems.)

Table 1. MBSA installation requirements.

Item Requirements Operating systems on which it can be installed and perform a local scan Windows 2000, Windows XP Professional, Windows XP Home Browser Internet Explorer 5.01 or newer (if this is not possible, then an XML parser must be downloaded from Microsoft) Administrative authority Must have administrative authority on local computer XML parser If IE 5.01 cannot be used, then an XML parser must be downloaded from Microsoft Services Server (not necessary for local scan), Workstation Network binding Client for Microsoft Network (to scan remotely) Additional possible requirements IIS, SQL or Exchange in order to obtain results Caveat Only a local scan is possible if the XP computer is XP home, of XP Professional using simple file sharing model

 

Table 2. MBSA remote scanning requirements.

Item Requirements Operation systems which can be remotely scanned Windows XP, Windows 2000, Windows NT 4.0 Service Pack 4 and newer Rights Administrator on each machine to be scanned Services Remote Registry Service, Server service Network binding File and Print Sharing Possible additional requirements IIS Common files if scanning IIS servers; Exchange Admin tool if scanning Exchange servers Network access Must be able to access the %systemroot% share (C$) on the remote computer; can access NetBIOS (TCP 139 or direct host TCP 445) ports on remote computer Mssecure file access Computer can download the patch database XML file, or it is located locally and you direct the scan to use the local file

Using MBSA
Installation is simple: Download, run the installation wizard, and you’re ready to begin. To scan, choose the system or systems to scan and click a button. MBSA scans each, one at a time. If not directed to a software update services (SUS) server, MBSA downloads a current copy of an XML file from Microsoft that allows it to check each system for current patches. (In version 1.1, you can direct MBSA to use the contents of your “approved” list of patches from your SUS server rather than the Microsoft XML file.) Figure 1 shows a portion of scan results. Scrolling through the report will help you identify weaknesses.

Figure 1. Microsoft Baseline Security Analyzer reports on potential server security vulnerabilities. (Click image to view larger version.)

Each item in the report is accompanied by information that identifies what was scanned and attempts to explain why this is an issue and what to do about it. If the product to be scanned isn’t installed on the scanned computer, the report will note this. Occasional issues arise, like missing requirements on scanned computers, permission issues and so on. Even though you may have installed a patch, MBSA may report its status as being undetermined—or even missing.

MBSA Tricks and Tips Here’s a listing for, and interpretation of, the errors you might encounter during scans: 200 System not found. Scan not performed—Is the host on the network? Are the name and IP address correct? 201 System not found—Usually a network or logon problem. 202 System not found. Scan not performed—The computer may not be running the Server service or connected to the network. 230 Scan not performed—Usually a general network error. 235 System not found or NetBIOS ports may be firewalled—No computer with this name or IP address exists or a personal firewall or port-filtering device may be dropping packets for ports 139 and 445. 261 System found but it is not listening on NetBIOS ports—The computer isn’t listening or it’s blocking access to TCP ports 139 and 445. 301 SystemRoot share access required—Unable to connect to the remote machine’s system share, possibly because the AutoShareServer(Wks) setting in the registry has been disabled. Another possibility: The account used doesn’t have administrative privileges on the computer 452 HFNetChk unable to scan this machine. Please check to see that you have administrative rights to this machine and are able to log in to this machine from your workstation. Scan not performed—Make sure the Server service is running on the remote machine to be scanned. Is the Workstation service running on both the remote machine and the scanning machine? You must also have administrative rights on the remote machine. 501 Remote registry access denied. Scan not performed—The Remote Registry Service must be enabled on the scanned computer. 502, 503 Scan not performed. Error reading registry —Usually a general registry error. 553 Unable to read registry. Please ensure that the remote registry service is running. Scan not performed—Is the Remote Registry service running (see error 501)? 621 Machine is not one of Windows (NT 4.0, 2000, XP, .NET). Scan not performed—Make sure you’re not pointing to a Linux or Windows 9x box. 622 Machine OS is not recognized. Please run with tracing on and send to technical support. Scan not performed—This can occur when scanning beta or new OS versions. 623 Machine service pack is not recognized. Please run with tracing on and send to technical support. Scan not performed—Check to see if the host has recently been service packed or is running a beta service pack. 701, 702—These errors mean the Microsoft cab file, “msscecure.cab,” can’t be downloaded. First http is tried (error 701), then https (error 702). Finally, an attempt to locate a local copy of the file is made. Make sure the computer is connected to the Internet, then see if there’s something blocking the download. Also check file accessibility and if there’s a local copy of the file, which is necessary.

Under MBSA’s Hood
How can this be? To understand and judge MBSA, you have to understand how it works. MBSA scans the computer to determine what OS, service packs and programs it’s running. It then parses the downloaded XML file and identifies security updates available for the software. It uses registry keys installed by the update, file version and checksums for each file installed by the update to determine if a patch has been applied. If one of these items is missing or incorrect, the patch is flagged as missing. MBSA reports the problem and, in some cases, points to a note that may explain why. You’ll often find that not all patches are easy to identify. You may have installed the wrong version for your system, installed a later version, or some piece of information may be missing. It may just be that there’s no way, at least with the current version of MBSA, to determine if the patch has been properly applied. Instructions are sometimes given for manually verifying patch status.

Table 3. In addition to reporting patching status, MBSA will scan the following OSes and products and report back the indicated information.

Check Issue Windows NT 4.0; Windows 2000; Windows XP More than 2 Admins? Possibly two many? Is auditing enabled? It should be. Is Auto Logon enabled? Vulnerability Unnecessary Services (FTP, telnet, www, smtp?) Not necessary on most systems. Is this machine a domain controller? Does it really need to be? Are you using NTFS? You should be. Is the guest account enabled? Not a good idea, however if XP and simple file sharing is not flagged as vulnerability. Any local accounts using: blank, same as user account, same as machine name, 'password', 'admin' or 'administrator'? Flagged as weak passwords. Also flags disabled accounts. Operating system version. x Do local accounts expire? Lists such accounts. All accounts should have passwords changed periodically. Is restrict anonymous set? Should be to prevent attacks that can enumerate user information, polices, share names. What shares are available? Protecting shares with permissions or removing if unnecessary. Is the latest service pack installed? Checks for the latest OS service pack. IIS 4.0 and 5.0 Are MSADC sample scripts and Scripts Virtual Directories removed? Removing these scripts removes potential tools for an attacker to use. Is the IISADMPWD Virtual directory removed? This was used by IIS 4.0 to enable password changes by users - it is not installed on IIS 5.0 by default, but is not removed during a migration from IIS 4.0 to 5.0. Is IIS being run on a DC? This is a high risk, and not recommended. User info resides on a DC and running a web server here makes it more difficult to secure. Has version 2.1 of the IIS Lockdown tool been run? The lockdown tool turns off unnecessary features. Is IIS logging enabled and is it using W3C extended log file format? Review of the log can find security issues, detect attacks and provide information on intrusions. Are parent paths enabled? Parent paths allows use of relative path names. This might be used by an attacker to traverse the directory structure and attack system areas of the server, and other sensitive areas. Are the sample directories, iissamples, iishelp and msadc sample directories present? They should be removed. Is the latest service pack installed? Checks for any IIS related service packs. SQL Server 7.0 and 2000 (& Microsoft Data Engine) Who has the sysadmin role? Sysadmin is administrative rights on the SQL server. Is the CmdExec right restricted to Sysadmin? Others who have this powerful right are listed. This right allows you to schedule execution of administrative tasks. Do SQL Server local accounts have simple passwords? In addition to checks mentioned above, checks to see if "sa" is used as password. What is the SQL authentication mode? Microsoft recommends the Windows Authentication mode. Mixed mode is available for legacy clients, but it stores user names and passwords in the SQL database. Is the built-in Administrators group given the Sysadmin Role? If so, they have full access to the databases. Maybe this is not what you want? Checks DACLs on four critical SQL directories. Only SQL service accounts and administrators should have access. Are SQL sa account passwords written in plaintext to the sql log files? The sa (system administrator account) is used in Mixed mode and passwords are saved in plaintext in SQL 7. In Windows authentication mode this is not an issue unless a domain account is chosen for SQL server services. Where does the SQL Server guest account have access to databases? Guest account access is listed. Restricting use of the guest account reduces access to databases. Is SQL running on a DC. This is not recommended. Is the Everyone group restricted to "read" on the SQL Server registry keys? Two keys are checked: HKLM\Software\Microsoft\Microsoft SQL Server and MSSQLServer Are SQL services accounts members of the local Administrators group, or the Domain Administrators group? Are they running under local system context? Restricting the privileges of service accounts should be done. Is the latest service pack installed? Checks for installation of the latest SQL service pack. Internet Explorer version 5.01 and newer Is the latest IE service pack installed? Checks for IE related packs installed. Are security zones configured? Lists current and recommended settings. If custom settings are different than the recommendations, does not attempt to determine if more secure. Office Products Is Office macro protection set? Checks on user-by-user basis if macro protection is set. What are Outlook Security Zones set at? Checks and reports on user-by-user basis.

It’s not a perfect solution, but it’s much better than relying on manual inspection, memory or nothing at all. Too bad there’s no way to flag these issues once you’ve resolved them so they don’t keep coming up on the report. That’s another thing you can do with my Access database—keep repeated automated patch issues that have been manually resolved from appearing on a report.

To alleviate the strain of reviewing multiple graphical reports, you’ll have to learn how to run MBSA without the graphical user interface.

MBSA "Gotchas" to Watch For You can install the Workstation service from the network connector properties. On the General tab, select “Install Client for Microsoft Networks.” If the Workstation service is installed and running, check the network connector properties. Is the “Client for Microsoft Networks” checked? This service must be bound to the network card to be used. You can’t scan other computers from one running Windows XP Home Edition. To work around this issue, you may be able to use Terminal Services. However, you must have Terminal Services Administration Mode installed on the server you wish to scan. Another version of mssecure.xml is available at xml.shavlik.com. Shavlik also maintains HFNetChk (Microsoft no longer has HFNetChk available for download, but you can use MBSA in HFNetChk mode). You can download version 3.86 of HFNetChk from Shavlik (the Microsoft version is 3.81) and use it with its mssecure.xml file. You can also mix and match. Use the XML file from Microsoft with HFNetChk 3.86 by using the ­ms switch. You can use the Shavlik XML file with the MBSA, but you must download the new CAB file and use the ­x switch to direct MBSA to use the local file instead of going to Microsoft. You can also point MBSA to the Shavlik file by using the command “mbsacli.exe /hf ­x http://xml.shavlik.com/mssecure.xml.” Using Shavlik’s XML file gives me different results. Shavlik says it has enhanced the file to deal with some of the more difficult to detect hotfixes, which may be the reason. Your mileage may vary. If you’re having trouble using the SUS server with MBSA, check for connectivity. The statement, “http://<susservername>/approveditems.txt,” should allow you to read the file in your browser. If you can’t read it, you’re not able to access the SUS server with MBSA. To use SUS server in MBSA use the syntax: “http://<susservername>” or “http://<ipaddress>.” To scan an Exchange Server, you must have the Exchange Admin tool on the scanning machine (install a copy from your Microsoft Exchange Server installation CD-ROM). You should update this with the latest Exchange service pack. To scan IIS remotely, you must install the IIS Common files on the scanning machine. (You don’t need a full install of IIS. To install the common files, start installing IIS using Control Panel | Add Remove Programs, Add | Remove Windows Programs, then uncheck all other IIS components listed.) While MBSA IP address scanning is limited to 256 IP addresses, you can use Shavlik’s HFNetChk 3.86 to scan larger address ranges.

Deep-Sixing the GUI
Running MBSA from the command line isn’t difficult. You just have to learn a little syntax, and you have to be able to enter it correctly. There’s no spell check or syntax checker in the command window. If you’re familiar with the syntax for HFNetChk, just enter mbsacli.exe with the /hf parameter followed by the HFNetChk-specific switch. If you’re new to the game or just want a refresher, here’s the scoop.

Two types of command-line scans are available. First, you can perform an MBSA-style scan; this will produce an XML file that can be viewed by the MBSA tool. It scans all products and does all evaluations. This is a good choice if you want to batch scans in a file and automate the process for later review. A second style scan, the HFNetChk-style scan, only looks for missing patches and can display results in the command-line window or place them in a delimited text file. It’s this form of the scan that can be used to provide input to a searchable database that can be used to produce reports in the manner John wanted.

Table 4. What the MBSA scan switches mean.

Switch Description -baseline -b Scan for only critical security updates (as determined by the Microsoft Security Response Center) -v Additional details on file versions found for each update; this may help you determine why a fix you think has been installed is marked as missing -nosum Does not perform checksum checks -x Does not perform registry checks -h hostname Specifies the NetBIOS name of the computer to scan Mbsacli /hf -h computer1,computer2,computer3, computer4 -i Specifies the IP address of the computer to scan Mbsacli /hf -i xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx -fip Specifies a file that contains the IP addresses of computers to scan (one IP address per line; 256 IP addresses max) Mbsacli /hf -fip mycomputerip.txt -fq Specifies name of file containing Q numbers that you want to suppress on output; use this to prevent the listing of fixes that you do not approve and do not want to evaluate the status of Msbsacli /hf notthese.txt -r Specifies a range of IP addresses to scan Mbsacli /hf ipaddressa - ipaddressz -d Specifies domain name to scan (network must allow UDP 137) Mbsacli /hf -d mydomain -n Specifies to scan the network (all computers which show up in network neighborhood) -history Identifies hotfixes that have been explicitly installed (not part of a rollup package); 3 possibilites depending on the number used with the history switch: 1 - those that have been explicitly installed 2 - those explicitly not installed, 3 both Mbsacli /hf -history 3 -t Number of threads used in the scan. Default is 64; maximum is 128. you may be able to modify the speed of the scan using this switch. -o Specifies the output format. Tab, provides a tab delimited format, wrap, wraps the data. This is the default and must be used if scanning more than 255 hosts. Mbsacli /hf -o tab -f myscan.txt -f Specifies the name of a file to put output in. -x Specifiy XML data source; without it the XML file will be downloaded from Microsoft Mbsacli /hf -x mssecure.xml (the file is in the same path as mbsacli) Mbsacli /hf -x http://servername/xmlfile.xml (the file is on a web server) -s Suppresses note and warning messages; ise a value of 1 to suppress note messages only, a value of 2 to suppress notes and warning messages -u Specifies a user name to uses when scanning; must be used with the -p password switch. -p Specifies the password to use when scanning; NTLM challenge response is used so the password is not passed over the network in the clear Mbsacli /hf -I xxx.xxx.xxx.xxx -u administrator - p password -trace Create a debug log Mbsacli /hf -trace -i ipaddress -v -z -sus Scan only for security updates that are marked as approved by SUS server Mbsacli /hf -sus "http://SUSserver" -about Displays information about mbsacli /hf -? or ?/ Displays a help menu about mbsacli /hf

Putting It Together
It’s time to put it all together now: scanning the computers on your network and preparing a report from the results. This is so simple, it’s almost anticlimactic. Three steps are necessary:

1. Use the HFNetChk mode of MBSA to scan computers on your network and place the results in a tab-delimited text file. The following statement will scan all computers in the tookool.com domain and place the results in the file myscan.txt:
   Mbsacli /hf ­d tookool.com ­o tab ­f myscan.txt
   
2. Next, place the file into an Access database:

a. Open Access and create a new database.
b. From the File menu, choose Get External Data, then choose Import.
c. In the Import box, browse to the file myscan.txt and click Import.
d. In the Import Text Wizard, make sure “Delimited ­ Characters such as comma or tab separate each field” is selected (this is the default), then click Next.
e. Ensure the “tab” check box is checked under Delimiters. Then check the box “First Row contains field names.” Access will then use these names as the field names in the table it will create in your database.
f. Click Next and select “In a new table.” (When updating scans with a new round of reports, make sure to change this to “In an existing table” and point Access to your table. This will append the data.)
g. Click Next twice, then select “No primary key.” Click Next.
h. Enter a name for the table, click Finish, then OK.

3. Finally, execute an Access query to list each computer and the missing hotfixes.

You can view each machine and its issues by opening the table, shown in Figure 2. Notice the error at the computer near the top. It was to be included in the scan, but NetBIOS ports weren’t open. In the real world, we might open up the ports and redo the scan or scan that machine locally for security reasons. It’s important to note that using MBSA freely on your network requires relaxing some security. If you’re hesitant to do that, you can still scan the computer locally.

Figure 2. The Access table shows the vulnerabilities found by HFNetChk. (Click image to view larger version.)

To make a better report for management, run the Report Wizard, as shown in Figure 3.

Figure 3. The patching information in a clear, easy-to-use report. (Click image to view larger version.)

To run the Wizard:

1. Select Reports in the Access database, then click the New icon.
2. Select Report Wizard, select the table from the drop-down box and click OK.
3. Click the double arrow “>>” button to place all fields on the report or, for a simple list without the notes and explanations, select fields one by one, then click Next.
4. Use the single arrow “>” button to group the report by machine name, then click Next three times.
5. Enter a title for the report and click Finish.

There you have it: A quick and dirty system for collecting patch information in an easy format. Like John, if you have patching practices already in place, you can set this up to audit the results.

For More Information Microsoft Baseline Security Analyzer download www.microsoft.com/technet/treeview/default.asp?url=/ technet/security/tools/Tools/MBSAhome.asp Knowledge Base 303215, “Microsoft Network Security Hotfix Checker Tool is Available” http://support.microsoft.com/default.aspx?scid=kb; EN-US;q303215 Microsoft Baseline Security Analyzer white paper http://microsoft.com/technet/security/tools/tools/ mbsawp.asp?frame=true Shavlik Web site www.shavlik.com Microsoft’s user newsgroup for MBSA—Locate the Microsoft.public.security.baseline_analyzer group on msnews.Microsoft.com. http://download.microsoft.com/download/e/5/7/ e57f498f-2468-4905-aa5f-369252f8b15c/mbsasetup.msi Frequently asked questions www.microsoft.com/technet/treeview/default.asp? url=/technet/security/tools/Tools/mbsaqa.asp Knowledge Base 20454, “Microsoft Baseline Security Analyzer is Available” http://support.microsoft.com/default.aspx?scid= kb;en-us;320454&sd=tech

Take it a step further and use them to finesse your patching operations, then keep the final reports as a record of the good work you’re doing. I’m sure you can think of other ways that this data would be useful, like valuable statistics on the improvements you’ve made to security.