Lsa2-fix and Priv-fix

In an ongoing battle of wits, hackers and security professionals look for holes in Windows NT. Hackers hope to bring the operating system (OS) to its knees, security professionals hope to find holes before hackers find them, and Microsoft developers repair the chinks in NT's armor. Microsoft has recently responded to a flurry of hacks when the company released several security-based hotfixes, including lsa2-fix, priv-fix, and pptp2-fix. Lsa2-fix corrects reporting problems with account lockout monitoring and tightens security requirements for retrieving service accounts and passwords. Priv-fix closes a back door for illegally acquiring administrator rights. Pptp2-fix contains performance enhancements and closes two security holes in Point-to-Point Tunneling Protocol (PPTP) connections. In this article, I discuss lsa2-fix and priv-fix. If you are running a Virtual Private Network (VPN) with PPTP, I recommend that you also investigate pptp2-fix.

Lsa2-fix
Lsa2-fix corrects two security problems in the Local Security Authority. LSA is the NT component that maintains and validates security credentials on a local system. The LSA database contains a list of built-in group accounts and passwords, domain trust accounts, and service account usernames and passwords. Lsa2-fix corrects an oversight in reporting account lockouts and encrypts the LSA database to better protect its security information. To understand how lsa2-fix works, you need to understand how NT implements account lockout monitoring. You also need to understand the need for encrypting the LSA database.

Account lockout monitoring. Most NT installations define an account lockout policy as a deterrent to unauthorized access. The lockout policy specifies the action to take after a fixed number of logon failures (i.e., when a user enters an invalid username or password repeatedly).

To establish an account lockout policy, start User Manager for Domains, go to the Policies menu, and select Account. Screen 1, page 168, shows the dialog box that pops up. Select Account lockout to activate a lockout policy. Selecting Duration under Lockout Duration lets you specify a lockout period (e.g., 30 minutes). If you select Forever under Lockout Duration, you disable the account permanently. An administrator must then manually clear the Account Locked Out checkbox in User Manager to reinstate the account.

Auditing logon and logoff failures does not capture server or workstation account lockouts in domain controller security logs.

Security auditing. Most NT installations enable domain security auditing to track logon and logoff failures and changes to domain security policies. You enable security auditing in User Manager. Select Policies, Audit to display the seven audit categories. As Screen 2 shows, you can enable auditing for success or failure (or both) in each category. Two of the categories you can monitor are Logon and Logoff and User and Group Management. The Logon and Logoff category tracks interactive and network logons (requests to establish network connections). The User and Group Management category monitors changes to individual and group accounts and passwords.

You enable security auditing on the Primary Domain Controller (PDC). After you enable auditing, all domain controllers audit the same events. When a qualifying event occurs, the domain controller where the event occurs records the event in its security log. For example, if you are auditing logon failures and a user enters an incorrect username or password, the authenticating domain controller (where the logon failure occurs) records the logon failure in its security log.

Auditing logon and logoff failures does not capture server or workstation account lockouts in domain controller security logs. To record these events, you must enable security auditing for the Logon and Logoff category on every system you want to monitor. To enable local security auditing, start User Manager, and choose Select Domain from the User menu. At the prompt, enter the name of the local workstation or standalone server. After you select the local machine, you'll see its name rather than the domain name in User Manager's title bar. Then, enable failure auditing for the Logon and Logoff category.

After you enable local auditing, you capture account lockout events in the security log of the local system, as Screen 3 shows. Unless you enable local security auditing on every NT server and workstation and you routinely scan these systems' security logs for event ID 539, break-in attempts can go undetected. Lsa2-fix corrects this reporting oversight.

LSA encryption. You install most NT services with a username that has elevated rights. NT stores the username and password associated with each service account in the LSA database. The hive file system32\config\security backs up the database. If you regularly back up your system and keep your Emergency Repair Disks (ERDs) current, the LSA database can appear in system32\config and winnt\repair directories, as well as on floppy disk and backup media.

Administrators can use API calls available in the Win32 Software Development Kit (SDK) to retrieve service usernames and passwords from the LSA database. A program that exposes service account information with these APIs appeared on the Internet in late July. Lsa2-fix addresses this security concern in three ways: It encrypts the LSA secrets database on disk, modifies LSA code so it returns private data only to local system components, and increases the privilege an application requires to open the security event log (system32\config\SecEvent). The encryption protects the entire database, including service accounts, domain trust accounts, and built-in group accounts and passwords.

Installing Lsa2-fix
Lsa2-fix supersedes lsa-fix, which corrected earlier performance and security problems. Because lsa2-fix modifies crucial security components and encrypts the LSA database, you must apply it to all the domain controllers on your network. After you install the hotfix, extend your domain security auditing policy to include success for the User and Group Management category. Then, when an account lockout occurs on an NT server or workstation, the authenticating domain controller writes the User Account Locked Out event (event ID 644) to its security log. If your network has many domain controllers, you must scan all the security logs to locate these records.

Lsa2-fix contains updates to eight .dlls (eventlog, lsasrv, msaudite, msv1_0, netcfg, samlib, samsrv, and xactsrv) and two executable programs (services.exe and srvmgr.exe). Because lsa2-fix encrypts the LSA secrets database, it is not compatible with the prehotfix format. Three preventive measures will help you revert to the prehotfix state if problems occur: Before you install the hotfix, you need to create an up-to-date ERD, make a copy of the files you might have to replace, and do a full backup of the system disk. If possible, install the hotfix on a test system before you modify production servers. As with all hotfixes, install lsa2-fix only if you think your organization is at a serious risk for the security breaches it corrects.

I don't think lsa2-fix is bug-free. First, I'm leery of the encryption portion of the hotfix. This feature is new, and I have doubts that it works properly in the first release. Second, I'm concerned that on-disk encryption might introduce unnecessary overhead. Third, although the account lockout reporting update seems appropriate for all sites, the LSA encryption issue applies to many fewer installations. You might want to install the account lockout portion but not the LSA encryption patch. The hotfix includes both patches, so you're stuck with all or nothing.

Priv-fix
Priv-fix updates two files, csrsrv.dll and csrss.exe, to correct a security breach that an NT hack called SecHole exploits. Only a local user with a valid account can run SecHole. When SecHole runs on an NT server or workstation, it lets ordinary users obtain administrative/debug rights on the server or workstation.

To assess your vulnerability to SecHole, review the accounts that have the right to log on locally to your domain controllers, Internet Information Server (IIS) servers, and Remote Access Service (RAS) servers. Start User Manager, and select User Rights from the Policies menu. Click the Rights field, and click Logon Locally. You might have to scroll down the list to see this choice. A dialog box shows you which accounts have local logon permissions. If you configured your servers and workstations with the same local Administrator account and password for easy maintenance, your vulnerability increases because a user can log on and run SecHole on all your machines.

If you think your users might download SecHole, you need to install priv-fix. The hotfix is easy to install: Double-click the executable file, and reboot your machine at the prompt.

Obtaining the Hotfixes
You can download lsa2-fix and priv-fix and their related Microsoft Support Online articles from Microsoft's Post-Service Pack 3 (SP3) hotfix site (ftp://ftp.microsoft.com/bussys/winnt/winntpublic/fixes/usa/nt40/hotfixespostSP3). For information about recent post-SP3 hotfixes, see Mark Joseph Edwards and Paula Sharick, "Service Packs and Hotfixes," November 1998. To stay up to date on Microsoft's latest security developments, go to the Microsoft Security Advisor Web site (http://www.microsoft.com/security).