Security Advisor
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
- 04/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:
- You need the tool to view the reports.
- Each report covers one computer. You can scan many computers from
one, but there’s no report consolidation.
- Report details, especially on specific patch status, are confusing.
- 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:
- 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
- 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.
- 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:
- Select Reports in the Access database, then click the New icon.
- Select Report Wizard, select the table from the drop-down box and
click OK.
- 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.
- Use the single arrow “>” button to group the report by machine name,
then click Next three times.
- 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.
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.