White Paper: Microsoft Baseline Security Analyzer V1.2

Updated : July 1, 2005

On This Page

Abstract
What's new in MBSA V1.2
MBSA V1.2 Capabilities
Scanning Modes
Description of Vulnerability Checks
Windows NT Support
Additional Resources

Abstract

The Microsoft Baseline Security Analyzer (MBSA) is a tool that allows users to scan one or more Windows-based computers for common security misconfigurations. MBSA will scan a Windows-based computer and check the operating system and other installed components, such as Internet Information Services (IIS) and SQL Server™, for security misconfigurations and whether or not they are up-to-date with respect to recommended security updates.

What's new in MBSA V1.2

MBSA is a security assessment tool for Windows 2000, Windows XP, and Windows Server 2003 systems. It scans for common misconfigurations in the operating system, IIS, SQL, and desktop applications, and can check for missing security updates for Windows, Internet Explorer, Windows Media Player, IIS, SQL Server, Exchange, Microsoft Office, Microsoft Data Access Components, Microsoft Virtual Machine, MSXML, BizTalk Server, Commerce Server, Content Management Server, and Host Integration Server. MBSA V1.2 was released in January 2004.

MBSA V1.2 has the following new features and updates since the Version 1.1.1 release:

Additional Language Support

MBSA V1.2 is now localized for English, German, French, and Japanese versions of Windows. Users can download builds of MBSA in each language. These builds will download the mssecure.xml file containing localized security update information for that language when available from the Microsoft Download Center. All localized builds will fall back to using the English mssecure.xml file (with checksum checks disabled when scanning a non-English machine) if the matching localized xml file is not available.

Additional Product Support

MBSA V1.2 has added security update checks for the following products:

  • Exchange Server 2003

  • Microsoft Office (local scans only; see list of products).

  • Microsoft Data Access Components (MDAC) 2.5, 2.6, 2.7, and 2.8

  • Microsoft Virtual Machine

  • MSXML 2.5, 2.6, 3.0, and 4.0

  • BizTalk Server 2000, 2002, and 2004

  • Commerce Server 2000 and 2002

  • Content Management Server (CMS) 2001 and 2002

  • SNA Server 4.0, Host Integration Server (HIS) 2000 and 2004

    Note: the Microsoft Office support was added via integration of the Office Update Inventory Tool.

Alternate File Support

MBSA V1.2 has added the capability to support alternate versions of a file. Files may have different version numbers and/or checksums due to:

  • QFE (Quick Fix Engineering)/LDR (Limited Distributed Release) vs. GDR (General Distributed Release) of a security update

  • Multi processor vs. uni processor releases of a security update

  • Non-security bulletin updates to security bulletin updates

  • Revised (updated) security bulletins

Previous versions of MBSA reported such updates with a yellow X, with a warning message that a "file version greater than expected" was found. MBSA V1.2, with its new alternate file version support, will have the ability to suppress this warning and verify the above cases if any of the files listed in the mssecure.xml match those found on the scanned machine.

Check for New Version

MBSA V1.2 can check if new versions of MBSA have been released by Microsoft. If a new version of MBSA is released, the user will be notified of the update in both the GUI and CLI.

Additional Windows Vulnerabilities Checks

MBSA V1.2 added a check for Automatic Updates feature settings, as well as a check for Internet Connection Firewall (ICF). For Automatic Updates, MBSA will report if this feature is enabled and whether it is configured to automatically download and automatically install updates, or whether it is enabled and controlled by Group Policy. For ICF, MBSA will scan against all network connections on the machine that support ICF, and report whether the firewall is enabled and whether any ports are open to external traffic.

Custom Internet Explorer Zones Interpretation

MBSA 1.2 now interprets custom IE zone settings and compares to recommended default zone level settings. The scan reports will identify any individual zone settings that have custom settings below the recommended defaults for the overall zone.

New MBSA Command Line Switches

MBSA 1.2 adds the following new command line switches, which can be used with mbsacli.exe or mbsacli.exe /hf:

  • -unicode (generates Unicode output for users running Japanese MBSA or scanning Japanese Windows machines)

  • -nvc (prevents MBSA from checking if newer tool version is available)

MBSA V1.2 Capabilities

MBSA V1.2 can scan machines that are running Windows 2000, Windows XP Professional, Windows XP Home Edition, and Windows Server 2003. MBSA can be executed from any machine that is running Windows 2000 Professional, Windows 2000 Server, Windows XP Home, Windows XP Professional, or Windows Server 2003.

System Configuration Checks

Windows Operating System

In general, MBSA scans for security issues in the Windows operating systems (Windows 2000, Windows XP, Windows Server 2003), such as "Guest" account status, file system type, available file shares, members of the Administrators group, etc. Descriptions of each OS check are shown in the security reports with instructions on fixing any issues found.

Internet Information Server

This group of checks scans for security issues in IIS 4.0, 5.0, and 6.0, such as sample applications and certain virtual directories present on the machine. The tool also checks if the IIS Lockdown tool has been run on the machine, which can help an Administrator configure and secure their IIS servers. Descriptions of each IIS check are shown in the security reports with instructions on fixing the issues found.

Microsoft SQL Server

This group of checks scans for security issues in SQL Server 7.0 and SQL Server 2000, such as the type of authentication mode, sa account password status, and SQL service account memberships. Descriptions of each SQL Server check are shown in the security reports with instructions on fixing any of the issues found.

Desktop Application Checks

This group of checks scans Internet Explorer 5.01+ zone settings for each local user account and macro settings for Office 2000,Office XP, and Office System 2003.

Security Updates

MBSA can determine which critical security updates are applied to a system by referring to an Extensible Markup Language (XML) file (mssecure.xml) that is continuously updated and released by Microsoft. The XML file contains information about which security updates are available for particular Microsoft products. This file contains security bulletin names and titles, and detailed data about product-specific security updates, including: files in each update package and their versions and checksums, registry keys that were applied by the update installation package, information about which updates supersede others, related Microsoft Knowledge Base article numbers, and much more.

When you run MBSA for the first time it must obtain a copy of this XML file so that the tool can find the security updates that are available for each product.1 The XML file is available on the Microsoft Download Center Web site in compressed form (digitally signed .cab file). MBSA downloads the .cab file, verifies the signature2, and then decompresses the .cab file to the local computer on which MBSA is running. Note that a .cab file is a compressed file that is similar to a .zip file.

After the .CAB file is decompressed, MBSA scans your computer (or the selected computers) to determine the operating system, service packs, and programs that you are running. MBSA then parses the XML file and identifies security updates that are available for your combination of installed software. MBSA determines if a specific update is installed on a given computer by evaluating three items: the registry key that is installed by the update, the file version(s), and the checksum (if running MBSA from the command line) for each file that is installed by the update. If any one of these checks fail, the update will be flagged as missing in the scan report.

MBSA not only scans for Windows security updates but also for updates associated with other products. MBSA V1.2 scans for security updates available for the following products:

  • Windows 2000

  • Windows XP

  • Windows Server 2003

  • Internet Explorer 5.01 and later (including Internet Explorer 6.0 for Windows Server 2003)

  • Windows Media Player 6.4 and later

  • IIS 4.0, 5.0, 5.1, and 6.0

  • SQL Server 7.0 and 2000 (including Microsoft Data Engine)

  • Exchange Server 5.5,2000, and 2003 (including Exchange Admin Tools)

  • Microsoft Office (local scans only; see list of products).

  • Microsoft Data Access Components (MDAC) 2.5, 2.6, 2.7, and 2.8

  • Microsoft Virtual Machine

  • MSXML 2.5, 2.6, 3.0, and 4.0

  • BizTalk Server 2000, 2002, and 2004

  • Commerce Server 2000 and 2002

  • Content Management Server (CMS) 2001 and 2002

  • SNA Server 4.0, Host Integration Server (HIS) 2000 and 2004

When using the MBSA GUI version (mbsa.exe), the -v and -nosum switches are used. The -v option will display the reason why a security update is considered “not found”. The -nosum option does not perform checksum checks.

When using the MBSA command-line version (mbsacli.exe), users would have to call the two switches listed above to match the MBSA GUI scan results, as they are not called by default. Users can also explicitly call the -v, and -nosum switches when doing an HFNetChk-style scan via mbsacli.exe (using the /hf switch) to match the GUI results.

Note when running MBSA in HFNetChk-mode (mbsacli.exe /hf) Office security updates will not be checked, as Office updates are only scanned through the MBSA GUI and mbsacli.exe via the Office Update Inventory Tool code.

Software Update Services (SUS) 1.0 Support

MBSA V1.2 provides support for performing the security updates portion of a scan against a local SUS 1.0 server. Users can select this option in the MBSA UI or in the MBSA command line interface. This portion of the scan will then be performed against the list of approved security updates on the local SUS server, rather than against the complete list of available security updates listed in the mssecure.xml file downloaded by the tool at runtime.

Systems Management Server (SMS) Support

The SMS 2.0 Software Update Services Feature Pack provides enterprise customers with a security patch management solution for Windows 2000, Windows Server 2003 and Windows XP clients. The Feature Pack uses MBSA technology to carry out automated, ongoing scans of client computers for installed or applicable security updates. This data is converted to and included in the Systems Management Server inventory information, and can also be viewed from a central point through web-based reporting. System administrators can select and import the latest Windows updates directly from Microsoft for distribution using Systems Management Server.

SMS 2.0 customers using the Feature Pack may refer to Microsoft Knowledge Base article 822643 to obtain an update for the Feature Pack that uses this latest release of MBSA.

Scanning Modes

Selecting Computers to Scan

Single Computer

In its simplest mode of operation MBSA can scan a single computer. The typical scenario for this would be "self-scan". When you choose the "Pick a computer to scan" action you have the option of entering the name or IP address of the computer you wish to scan. By default, when you pick this option the computer name displayed will be the local computer on which the tool is running.

Multiple Computers

If you choose "Pick Multiple Computers to Scan" you will have the opportunity to scan more than one computer. You have the choice of scanning an entire domain by entering the domain name, or you can specific a range of IP addresses and scan all of the Windows-based machines found within the range.3

Requires Administrator Access

In order to scan a computer Administrator access is required. In the case of a "self-scan" the account with which you run MBSA must either be the Administrator or a member of the local Administrator's group. In the case where you are scanning multiple computers you must be an administrator of each computer or a domain administrator.

Types of Scans

MBSA-Style Scan

An MBSA-style scan will scan and store results in an individual XML file to then be viewed in the MBSA UI (as was done in MBSA V1.1.1). MBSA-style scans can be performed using the MBSA GUI interface (mbsa.exe) or through the MBSA command line interface (mbsacli.exe). These scans include the full set of available Windows, IIS, SQL, and security update checks.

HFNetChk-Style Scan

An HFNetChk-style scan will check for missing security updates only and will display scan results as text in the command line window, as was done in previous standalone versions of HFNetChk. This type of scan can be performed through mbsacli.exe with the "/hf" switch, which indicates an HFNetChk scan to the MBSA tool engine.

Viewing Security Reports

Every time that you perform an MBSA-style scan, a security report is generated for each scanned computer and saved on the computer on which MBSA is running. The location of these reports is listed at the top of the screen (stored under the user profile folder). Security reports are saved in an XML format.

You can easily sort the reports by computer name, scan date, IP address or security assessment. This feature allows you to easily compare security scans over a period of time.

Network Scans

MBSA can be used to remotely scan up to 10,000 machines at a time from a central machine given the system requirements as outlined in the readme file. MBSA was designed to be run within a domain under an account that has local Administrative privileges on each machine being scanned.

In a multi-domain environment, where a firewall or filtering router separates the two networks (two separate Active Directory domains), TCP ports 139 and 445 and UDP ports 137 and 138 must be open in order for MBSA to connect and authenticate to the remote network being scanned.

Scans Involving Localized Builds/Different OS Languages

MBSA downloads mssecure.cab and extracts the mssecure.xml file, which contains data for security updates available for each product, and uses this file to check whether the scanned machines have the latest security updates installed.

Now that MBSA V1.2 is available in four languages, there are four versions of the mssecure.xml file for each language, as different versions of products may have different file versions and/or checksums.

Checksum checking is performed when running mbsacli.exe or mbsacli.exe /hf. Checksum checks are performed if the OS language of the target machine and the language of the mssecure.xml file match; otherwise, they are skipped. Checksum checking provides the highest level of confirmation that the versions of the patched files on the target machine are the exact files approved by Microsoft. Checksum checks can be forced at the command line via the -sum switch, or disabled via the -nosum switch.

The following list describes the different scenarios that may be encountered when using different languages of a machine OS, mssecure.xml, and MBSA UI:

  • A Japanese system with the Japanese version of MBSA installed that scans a Japanese system:

    • Japanese mssecure.cab file attempts to be downloaded, and scan results are shown in Japanese.
  • A French system with the Japanese version of MBSA installed that scans a French system:

    • Results are shown in Japanese (due to Japanese version of MBSA installed), except the information provided by the system [e.g., dates, filenames, etc.], or taken from mssecure.xml, will be in French. MBSA attempts to download the French mssecure.cab file as a French system is being scanned.
  • A German system with the German version of MBSA installed that scans a German machine but cannot download the German mssecure.cab file:

    • Since MBSA fails to download the German mssecure.cab file, it attempts to find a previously downloaded version of this cab in the local MBSA folder. If this fails MBSA will fall back to downloading and using the English mssecure.cab file and using the English mssecure.xml file for the security updates portion of the scan.

Description of Vulnerability Checks

Windows Checks

Administrators Group Membership

This check identifies and lists the individual user accounts that belong to the Local Administrators group. If more than 2 individual Administrative accounts are detected, the tool will list the account names and flag the check as a potential vulnerability. In general, it is recommended to keep the number of Administrators to a minimum as Administrators essentially have complete control over the computer.

Auditing

This check determines whether auditing is enabled on the scanned computer. Microsoft Windows has an auditing feature that tracks and logs specific events on your system, such as successful and failed logon attempts. By monitoring your system's event log, you can help identify potential security issues and malicious activity.

Auto Logon

This check determines whether the Auto Logon feature is enabled on the scanned computer, and if the logon password is encrypted in the registry or stored in plaintext. If Auto Logon is enabled and the logon password is stored as plaintext, the security report reflects this as a high-level vulnerability. If Auto Logon is enabled and the password is encrypted in the registry, the security report flags this as a potential vulnerability.

Note If you get the message "Error Reading Registry," your Remote Registry service might not be enabled.

Auto Logon stores your logon name and password in the registry, allowing you to automatically log on to Windows 2000 without typing in your user name or password in the logon user interface. However, Auto Logon could also enable other users to access your files and use your name to commit malicious acts on the system (for example, anyone with physical access to the computer can boot the operating system and automatically be logged on). If you have Auto Logon enabled and you do not want to change it, make sure that you do not store any sensitive information on the computer. Since anyone who has physical access to your computer can use the autologon feature you should only use this feature in an environment that is both trusted and secured.

You can store the password that you use for automatic logon as plaintext in the registry or you can encrypt it as a Local Security Authority (LSA) secret.

Automatic Updates

This check identifies whether the Automatic Updates feature is enabled on the scanned machine and if so, how it is configured. Automatic Updates can keep your computer up-to-date automatically with the latest updates from Microsoft by delivering them directly to your computer from the Windows Update site (or from a local Software Update Services (SUS) server if you are in a managed environment). Automatic Updates is available on Windows 2000 SP3 machines and higher.

Automatic Updates can be configured to automatically download and install updates on a machine, automatically download but notify the user of updates before installing, or notify the user before both downloading and installing updates on a machine.

Check for Unnecessary Services

This check determines whether any services contained in the services.txt file are enabled on the scanned computer. The services.txt file is a configurable list of services that should not be run on the computer that is scanned. This file is installed by the MBSA and stored in the installation folder for the tool. The services.txt file should be configured by the tool user to include those specific services to be checked on each scanned machine. The services.txt file installed by default with the tool contains the following services:

MSFTPSVC (FTP)

TlntSvr (Telnet)

W3SVC (WWW)

SMTPSVC (SMTP)

A service is a program that runs in the background whenever the computer is running the operating system. It does not require a user to be logged on. Services are needed to perform user-independent tasks such as a fax service that waits for incoming faxes.

Domain Controller

This check identifies whether the computer that is being scanned is a domain controller.

For a Windows Server 2003, Windows XP or Windows 2000, a domain controller is the server that authenticates domain logons and maintains the security policy and the security accounts master database for the domain. Domain controllers manage user access to a network, which includes logging on, authentication, and access to the directory and shared resources. Domain controllers also hold all domain user accounts, including key administrator accounts. For these reasons, domain controllers should be considered key resources that need strong protection. You should verify that you really need this machine to be a domain controller and that you have taken the appropriate steps to secure the access to this machine.

File System

This check determines which file system you are using on each hard drive to make sure that it is the NTFS file system. NTFS is a secured file system that allows you to control or restrict access to individual files or directories. For example, if you want to allow your co-workers to be able to view your files, but not change them, you can do this by using the Access Control Lists (ACLs) provided by NTFS.

Note For this check to succeed, the drive must be shared using administrative drive shares.

Guest Account

This check determines whether the built-in Guest account is enabled on the scanned computer.

The Guest account is a built-in account used to log on to a computer running Windows Server 2003 or Windows 2000 when a user does not have an account on the computer or domain, or in any of the domains trusted by the computer's domain. On Windows XP machines that use simple file sharing, all user connections from the network are mapped to the Guest account as part of the security model. If the Guest account is enabled on Windows 2000, Windows XP machines (not using simple file sharing), or Windows Server 2003 machine, it will be flagged in the security report as a vulnerability. If the Guest account is enabled on Windows XP machines that use simple file sharing, it will not be flagged as a vulnerability.

Internet Connection Firewall

This check identifies whether Internet Connection Firewall (ICF) is enabled on the scanned machine (for Windows XP and Windows Server 2003), for all active network connections, and whether any static inbound ports are open in the firewall. ICF is firewall software that provides protection for computers by controlling what information is communicated from your machine to and from the Internet or other machines on a network. ICF is included in Windows XP and Windows Server 2003 Standard Edition and Enterprise Edition.

Local Account Passwords

This check identifies any local user accounts that are using blank or simple passwords. This check is not performed on domain controllers. As a security measure, Windows Server 2003, Windows XP and Windows 2000 operating systems all require user authentication through passwords. However, the security of any system depends on both technology and policy - the manner in which systems are set up and managed. This check enumerates all user accounts and checks for the following passwords:

  • Password is blank

  • Password is the same as the user account name

  • Password is the same as the machine name

  • Password uses the word "password"

  • Password uses the word "admin" or "administrator"

This check also notifies you of any accounts that have been disabled, or are currently locked out.

MBSA will try to change the password on the target machine by using each of these passwords. If this operation succeeds, it indicates the account is using that password. MBSA will not reset or change the password permanently but it will report that your password is simple.

You should note that this check can take a long period of time, depending on the number of user accounts on the machine. Administrators may want to disable this check before scanning Domain Controllers on their network.

Note This check may produce event log entries in the Security log if auditing is enabled on the machine.

Operating System Version

This check determines which operating system is running on the scanned computer. Windows Server 2003, Windows XP, and Windows 2000 introduced new levels of reliability and availability for all or your business operations, such as finer grained control over file permissions.

Password Expiration

This check determines whether any local user accounts have non-expiring passwords. Passwords should be changed regularly to mitigate against password attacks. Each local user account with a non-expiring password will be listed.

Restrict Anonymous Users

This check determines whether the RestrictAnonymous registry key is used to restrict anonymous connections on the scanned computer.

Anonymous users can list certain types of system information, including user names and details, account policies, and share names. Users who want enhanced security can restrict this function so that anonymous users cannot access information.

Shares

This check determines whether there are any shared folders on the computer that is being scanned. The scan report will list all shares found on the computer, including Administrative shares, along with their share-level and NTFS-level permissions.

You should turn off shares, unless needed, or you should secure them by limiting access to specific users via share-level and NTFS-level permissions.

IIS Checks

MSADC and Scripts Virtual Directories on IIS

This check determines whether the MSADC (sample data access scripts) and Scripts virtual directories are installed on a scanned Internet Information Services (IIS) computer. These directories typically contain scripts that, if not required, should be removed to help reduce the attack surface of the computer.

The IIS Lockdown tool turns off unnecessary features in IIS 4.0, 5.0, 5.1, and 6.0 such as this one, thereby reducing the system's exposure to attackers.

IISADMPWD Virtual Directory

This check determines whether the IISADMPWD directory is installed on the scanned computer. IIS 4.0 enables users to change their Windows passwords and to notify users that their passwords are about to expire. The IISADMPWD virtual directory that installs as part of the default web site in IIS 4.0 contains files that are used by this feature. This feature is implemented as a set of .htr files in the \System32\Inetsrv\Iisadmpwd directory and an ISAPI extension named Ism.dll.

IIS on Domain Controller

This check determines whether Internet Information Services (IIS) is running on a system that is a domain controller. This is flagged in the scan report as a high-level vulnerability unless the computer being scanned is a Small Business Server.

It is recommended that you do not run an IIS web server on a domain controller. Domain controllers contain sensitive data such as user account information, and they should not be used in another role. If you run a web server on a domain controller, you increase the complexity involved in securing the server and preventing attacks.

IIS Lockdown Tool

This check determines whether Version 2.1 of the IIS Lockdown tool, part of the Microsoft Security Tool Kit, has been run on the scanned computer. The IIS Lockdown Tool works by turning off unnecessary features in IIS, thereby reducing the attack surface available to attackers.

The IIS Lockdown tool is not needed for IIS 6.0 on new Windows Server 2003 installations since it is locked down by default (services must be explicitly enabled by the IIS Administrator when the IIS role is configured). For upgrades to IIS 6.0 from IIS 5.0 installations, the IIS Lockdown tool should be used to ensure only the required services are enabled on the server.

IIS Logging

This check determines whether Internet Information Services (IIS) logging is enabled, and if the W3C Extended Log File Format is used.

IIS logging goes beyond the scope of the event-logging or performance-monitoring features of Windows. The logs can include information such as who has visited your site, what the visitor viewed, and when the information was viewed last. You can monitor attempts, either successful or unsuccessful, to access your Web sites, virtual folders, or files. This includes events such as reading the file or writing to the file. You can choose which events you want to audit for any site, virtual folder, or file. By regularly reviewing these files, you can detect areas of your server or your sites that may be subject to attacks or other security problems. You can enable logging for individual Web sites and choose the log format. When logging is enabled, it is enabled for all the site's folders, but you can disable it for specific directories.

IIS Parent Paths

This check determines whether the ASPEnableParentPaths setting is enabled on the scanned computer. By enabling parent paths on IIS, Active Server Pages (ASP) pages can use relative paths to the parent directory of the current directory - that is, paths that use the .. syntax.

IIS Sample Applications

This check determines whether the following IIS samples file directories are installed on the computer:

\Inetpub\iissamples

\Winnt\help\iishelp

\Program Files\common files\system\msadc

The sample applications typically installed with IIS illustrate dynamic HTML (DHTML) and Active Server Pages (ASP) scripting and provide online documentation.

SQL Checks

MBSA V1.2 scans against all instances of SQL Server and MSDE found on scanned machines.

Members of the Sysadmin Role

This check determines the number of members of the Sysadmin role and displays the results in the security report.

SQL Server roles are used to group together logins that have the same rights to perform operations. The fixed server role, Sysadmin, gives system administrator rights to all of its members.

Note If you get the "No permissions to access database" error message, you might not have permissions to the MASTER database.

Restricting CmdExec Rights to Sysadmin

This check ensures that the CmdExec right is restricted to Sysadmin only. All other accounts that have the CmdExec right are listed on the security report.

SQL Server Agent is a service available on Windows XP and Windows 2000 that executes jobs, monitors SQL Server, and sends alerts. With SQL Server Agent, you can automate certain administrative tasks by using scripted job steps. A job is a specified series of operations performed sequentially by SQL Server Agent. A job can perform a wide range of activities, including running Transact-SQL scripts, command-line applications, and Microsoft ActiveX scripts. Jobs can be created to run tasks that are often repeated or scheduled, and they can automatically notify users of job status by generating alerts.

SQL Server Local Account Passwords

This check determines whether any local SQL Server accounts have simple passwords, such as a blank password. This check enumerates all user accounts and checks for the following passwords:

  • Password is blank

  • Password is the same as the user account name

  • Password is the same as the machine name

  • Password uses the word "password"

  • Password uses the word "sa"

  • Password uses the word "admin" or "administrator"

This check also notifies you of any accounts that have been disabled, or are currently locked out.

SQL Server Authentication Mode

This check determines the authentication mode used on the SQL Server that is being scanned.

Microsoft SQL Server provides two modes for securing access to the server: Windows Authentication Mode and Mixed Mode.

In Windows Authentication Mode, Microsoft SQL Server relies solely on the Windows authentication of the user. Windows users or groups are then granted access to the SQL Server. In Mixed Mode, users may be authenticated by Windows or by SQL Server. Users that are authenticated by SQL Server have their user name and password pairs maintained within the SQL Server. Microsoft strongly recommends that Windows Authentication Mode always be used.

Windows Authentication Mode

This security mode allows SQL Server to rely on Windows to authenticate users in the same way as other applications. Connections made to the server using this mode are called trusted connections.

When you use Windows Authentication Mode, the database administrator allows users to access the computer running SQL Server by granting them the right to log on to SQL Server. Windows security identifiers (SIDs) are used to track Windows authenticated users. As Windows SIDs are used, the database administrator can grant access directly to Windows users or groups.

Mixed Mode

In SQL Server, Mixed Mode relies on Windows to authenticate users when the client and server are capable of using NTLM, or Kerberos logon authentication protocols. If either party is incapable of using a standard Windows logon, SQL Server requires a user name and password pair, and compares this pair against those stored in its system tables. Connections that rely on user name and password pairs are called non-trusted.

Mixed mode is supplied for two reasons: 1) backward compatibility with older versions of SQL Server; and 2) compatibility when SQL Server is installed on Windows 95 and Windows 98 operating systems. (Trusted connections are not supported on Windows 95 or Windows 98 -based computers when they are acting as the server.)

SQL Server BUILTIN\Administrators in Sysadmin Role

This check determines whether the built-in Administrators group is listed as a member of the Sysadmin role.

Note If you get the "No permissions to access database" error message, you might not have permissions to the MASTER database.

A SQL Server role is a security account that is a collection of other security accounts. It can be treated as a single unit when you are managing permissions. A role can contain SQL Server logon permissions, other roles, and Windows user accounts or groups.

Fixed server roles have a server-wide scope. They exist outside of the databases. Each member of a fixed server role is able to add other logins to that same role. All members of the Windows BUILTIN\Administrators group (the local administrator's group) are members of the sysadmin role by default, which gives them full access to all of your databases.

SQL Server Directory Access

This check verifies that the following SQL Server directories have limited access to SQL service accounts and local Administrators only:

  • Program Files\Microsoft SQL Server\MSSQL$InstanceName\Binn

  • Program Files\Microsoft SQL Server\MSSQL$InstanceName\Data

  • Program Files\Microsoft SQL Server\MSSQL\Binn

  • Program Files\Microsoft SQL Server\MSSQL\Data

The tool scans the access control list (ACL) on each of these folders and enumerates the users contained in the ACL. If any other users (that is, aside from the SQL service accounts and Administrators) have access to read or modify these folders, the tool marks this check as a vulnerability in the security report.

SQL Server Exposed sa Account Password

This check determines whether SQL 7.0 SP1, SP2, or SP3 sa account passwords are written in plaintext to the setup.iss and sqlstp.log\sqlspX.log files in the %windir% and %windir%\%temp% directories. The splstp.log\sqlspX.log file is also checked on SQL 2000 if domain credentials are used in starting the SQL Server services.

If Mixed Mode authentication is used while setting up the SQL Server, the sa password is saved in plaintext format in the setup.iss and sqlstp.log files file for SQL Server 7.0 SP1, SP2, and SP3. Administrators using Windows Authentication mode (which is the recommended mode) would only have credentials at risk if they chose to provide a domain credential to be used when starting the SQL Server services automatically.

SQL Server Guest Account

This check determines whether the SQL Server Guest account has access to databases (excluding master, tempdb, and msdb). All databases to which the account has access are listed in the security report.

Note If you get the "No permissions to access database" error message, you might not have permissions to the MASTER database.

In SQL Server, a user logon account must be authorized to access a database and its objects in one of the following ways:

  1. The logon account can be specified as a database user.

  2. The logon account can use a guest account in the database.

  3. A Windows group logon can be mapped to a database role. Individual Windows accounts that are members of that group can then connect to the database.

Members of the db_owner or db_accessadmin database roles, or the Sysadmin fixed server role, create the database user account roles. An account can include several parameters: the SQL Server logon ID, database user name (optional), and up to one role name (optional). The database user name does not have to be the same as the user's logon ID. If a database user name is not provided, the user's logon ID and database user name are identical. After creating the database user, the user can be assigned to as many roles as necessary. If a role name is not provided, the database user is only a member of the public role.

Members of the db_owner, db_accessadmin, or sysadmin roles can also create a guest account. The guest account allows any valid SQL Server login account to access a database even without a database user account. By default, the guest account inherits any privileges that have been assigned to the public role; however, these privileges can be changed to be greater or less than that of the public role.

SQL Server on Domain Controller

This check determines whether SQL Server is running on a system that is a domain controller. It is recommended that you do not run SQL Server on a domain controller. Domain controllers contain sensitive data such as user account information, and they should not be used in another role. If you run a SQL Server database on a domain controller, you increase the complexity involved in securing the server and preventing against attack.

SQL Server Registry Key Security

This check ensures that the Everyone group is restricted to Read permission for the following registry keys:

HKLM\Software\Microsoft\Microsoft SQL Server

HKLM\Software\Microsoft\MSSQLServer

If the Everyone group has more than Read permission to these keys, it will be flagged in the security scan report as a high-level vulnerability.

SQL Server Service Accounts

This check determines whether the SQL Server service accounts are members of the local or Domain Administrators group on the scanned computer, or whether any SQL Server service accounts are running under the LocalSystem context.

The MSSQLServer and SQLServerAgent service accounts are checked on the scanned computer.

Note If you receive the "No permissions to access database" error message, you might not have permissions to the MASTER database.

Security Update Checks

Service packs are well-tested collections of updates that focus on a variety of customer-reported concerns with a Microsoft product. They generally fix issues to the product since the product's general availability. Service packs are cumulative - each new service pack contains all the fixes in previous service packs, plus any new fixes. They are designed to ensure platform compatibility with newly released software and drivers, and contain updates that fix issues discovered by customers or via internal testing.

A security update, on the other hand, is an interim update that usually addresses a specific bug or security vulnerability. All security updates offered during a service pack's lifetime are rolled up into the subsequent service pack. Each security update identified by this tool has an associated Microsoft security bulletin that contains more information about the fix. The results of this check identify which security updates are missing, and provides a link to the Microsoft web site to view the details of each security bulletin.

This tool checks to ensure that you have the latest service packs and security updates for the following products and components:

  • Windows 2000

  • Windows XP

  • Windows Server 2003

  • Internet Explorer 5.01 and later (including Internet Explorer 6.0 for Windows Server 2003)

  • Windows Media Player 6.4 and later

  • IIS 4.0, 5.0, 5.1, and 6.0

  • SQL Server 7.0 and 2000 (including Microsoft Data Engine)

  • Exchange Server 5.5, 2000, and 2003 (including Exchange Admin Tools)

  • Microsoft Office (local scans only; see list of products).

  • Microsoft Data Access Components (MDAC) 2.5, 2.6, 2.7, and 2.8

  • Microsoft Virtual Machine

  • MSXML 2.5, 2.6, 3.0, and 4.0

  • BizTalk Server 2000, 2002, and 2004

  • Commerce Server 2000 and 2002

  • Content Management Server (CMS) 2001 and 2002

  • SNA Server 4.0, Host Integration Server (HIS) 2000 and 2004

Desktop Application Checks

Internet Explorer Security Zones

This check lists the current and recommended security settings for the IE zones for each local user on the scanned computer.

The Microsoft Internet Explorer Web content zones divide the Internet or intranet into zones with different levels of security. This capability permits you to set global default settings for the browser that allow all content on trusted sites or disallow certain types of content, such as Java applets or ActiveX controls, depending on the Web site of origin.

The Internet Explorer browsing software comes with four predefined Web content zones: Internet, Local intranet, Trusted sites, and Restricted sites. In the Internet Options dialog box, you can set the security options you want for each zone, and then add or remove sites from any zone (except Internet), depending on your level of trust in the site. In corporate environments, administrators can set up zones for users. They can also add or remove (in advance) the authentication certificates of software publishers that they do or do not trust so that users do not have to make security decisions while they are using the Internet.

For each security zone you can choose a high, medium, low, or custom security setting. Microsoft recommends the high setting for sites in a zone of uncertain trustworthiness. The custom choice provides advanced users and administrators with more control over all security options, including the following:

  • Access to files, ActiveX controls, and scripts

  • The level of capabilities given to Java applets

  • Site identity designation with Secure Socket Layer (SSL) authentication

  • Password protection with NTLM authentication (depending on which zone a server is in, Internet Explorer can send password information automatically, prompt the user for user and password information, or simply deny any logon request)

Internet Explorer Enhanced Security Configuration for Administrators

This check identifies whether the Internet Explorer Enhanced Security Configuration for Administrators has been enabled on computers running Microsoft Windows Server 2003. If the Internet Explorer Enhanced Security Configuration for Administrators has been installed, this check will also identify Administrators who have the Internet Explorer Enhanced Security Configuration disabled.

Internet Explorer Enhanced Security Configuration for Non-Administrators

This check identifies whether the Internet Explorer Enhanced Security Configuration for users other than Administrators has been enabled on computers running Microsoft Windows Server 2003. If the Internet Explorer Enhanced Security Configuration for non-Administrators has been installed, this check will also identify non-Administrators who have the Internet Explorer Enhanced Security Configuration disabled

Office Macro Protection

This check determines the security level for Microsoft Office System 2003, Office XP, Office 2000, and Office 97 macro protection on a user-by-user basis. PowerPoint, Word, Excel and Outlook are all checked by the MBSA.

Macros automate repetitive tasks. They can be time-saving tools, but macros can also be used to transmit viruses when a user opens an infected document containing a malicious macro. Opening or sharing an infected document can enable the malicious macro to spread to other documents on your system, or to other users.

Windows NT Support

Microsoft ended Windows NT support December 31, 2004. However, the ability for MBSA 1.2.x to detect security updates on the NT platform has not been removed. Published updates for Windows NT have not been removed from mssecure.xml. Furthermore, MBSA 1.2.x will continue to scan for IIS 4.0, SQL and NT security mis-configurations in an unsupported manner. The next version of MBSA will not offer security update detection or security configuration assessment for the NT platform. Please refer to https://support.microsoft.com/lifecycle/ for more information.

Additional Resources

Microsoft Security Strategies and Solutions

Microsoft Security Website: https://www.microsoft.com/security/

MBSA Website: https://www.microsoft.com/technet/security/tools/mbsahome.mspx

Microsoft Security Response Center Security Bulletin Severity Rating System https://www.microsoft.com/technet/security/bulletin/rating.mspx

Locate a Partner Who Can Help With Microsoft Security Solutions

Microsoft Certified Providers Directory

https://directory.microsoft.com/resourcedirectory/Solutions.aspx

Microsoft Consulting Services

https://www.microsoft.com/services/microsoftservices/default.mspx

1 Each time MBSA is run it will attempt to connect to the Internet to download the CAB file from Microsoft. If an Internet connection is not available, the tool will look for a local copy of the CAB/XML file in the tool installation folder. Each time the file is successfully downloaded during a scan, a local copy will be stored on the machine in the event that subsequent scans fail to connect to the Internet. Otherwise, for machines that never connect to the Internet, users can separately download this file from the Microsoft Download Center site and copy it onto the machine running the tool.

2 The .CAB file is digitally signed by Microsoft Corporation. The MBSA tool verifies the digital signature to ensure the authenticity of the file and that it has not been replaced by a bogus or corrupt file.

3 In an MBSA-style scan, when given a domain or range of IP addresses, MBSA will try to verify each machine account in the group. The tool will list which computers could not be verified and will continue to scan those that respond. In an HFNetChk-style scan, the HFNetChk engine will look for two IP ports required for scanning on each machine and will fail it if cannot access these ports. This pre-scan checking does not rely on ICMP.