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.

   Previous  [1]  2  Next