Service Pack 3 is Really Security Pack 3

Microsoft recently released Windows NT 4.0 Service Pack 3 (SP3), which includes more than 180 fixes for known problems. After examining SP3, I call it Security Pack 3, because it adds five strong new security features to NT, including a neat password-filtering tool for enhancing overall security. (This password filtering tool, passfilt.dll, first came with SP2, but almost no one knew it was there. I want to make sure everybody knows about this tool now that it's also in SP3.) The five security-related changes to NT Workstation and Server are

1. Server Message Block (SMB) signing
2. Password filtering
3. Anonymous user restrictions
4. System keys
5. CryptoAPI 2.0

Let's look at each new feature in detail.

Crash Course on SMB Signing
SMB signing is incredibly useful and overdue. Microsoft, IBM, and Intel jointly developed the SMB protocol, which defines program-level commands for obtaining or providing remote file services in a network environment. A new version of the SMB authentication protocol, the Common Internet File System (CIFS) file-sharing protocol, comes with SP3. This subset of SMB is tuned for use on the Internet. Microsoft has submitted the CIFS specifications to the Internet Engineering Task Force (IETF) as an Internet Draft for ratification as an industry standard. For simplicity, I'll refer to SMB and its subset protocols as SMB. The SMB protocols let systems transparently access files that reside on remote systems. These protocols transparently share any item, such as a printer, that is mapped into the file space.

Some background on TCP/IP network traffic will help you understand SMB signing: TCP/IP network traffic consists of packets. Each packet contains a header that carries information such as a source and destination IP address. Each time you connect to a shared resource, such as a server's disk drive, you generate and transmit packets to the server for action. The server sends packets back to your system for an action such as mapping a drive and displaying its contents. This connection and packet exchange process is an SMB session.

In the past, SMB sessions (e.g., sharing resources) did not ensure the authenticity of the SMB packets sent and received. When users tried to connect to a shared resource, they were successful if their permissions allowed the connection. From that point, all SMB session traffic passed between the client and server without validation. The security risk lies in non-validated packets, which make it possible for someone to create and insert rogue packets into the network traffic stream to launch a messaging attack. In fact, someone on the network between you and the server could intercept the entire SMB session, mounting a man-in-the-middle attack. Or someone could completely hijack the SMB session.

After you implement the new SMB signing feature, client and server can use a strong mechanism to mutually authenticate SMB sessions, packet by packet: client and server agree that they will digitally sign each packet to ensure its authenticity. Then both client and server inspect every packet to ensure that the packet came from the system it was supposed to come from, thus eliminating the possibility of attacks. This approach adds overhead to the systems, but the security is worth the sacrifice, and you might not even notice the difference.

Installing SP3 introduces SMB signing to your NT Workstation and NT Server systems. On NT Server, SMB signing is disabled by default, but on NT Workstation, it's enabled by default. You need to edit the Registry to use SMB for communications with NT Server. You can configure SMB signing in two ways: enabled and required. Enabled means that if a client system has SMB signing enabled, it will be the preferred communications method. Required means that all clients must use SMB signing to communicate with the NT system.

You need to enable SMB signing to use it on NT Server. If you turn on RequireSecuritySignature by setting its value to 1, while SMB is enabled, NT Server must use the signing technique for all connections. (For information about turning on RequireSecuritySignature, see, "SMB Signing.") Clients that don't use SMB signing won't be able to communicate via SMB with the NT system (e.g. sharing won't work).

You need the updated service packs for Windows 95 and other Microsoft client systems that will participate in SMB signing with an NT system. The current incarnations of non-NT OSs know nothing about this new authentication technique and won't work with your NT systems if you require SMB signing. If you only enable SMB signing, the non-NT OSs continue to work with NT; however, they'll be vulnerable to SMB attacks. Take the time to upgrade your non-NT OSs; it's worth the effort.

Samba, a freeware UNIX-based SMB server, does not support this new SMB signing functionality. (For information about Samba, see "Samba," March 1997). Adjust your Registry entries accordingly (i.e., don't require SMB signing) on NT systems that need to communicate with non-Microsoft SMB servers such as Samba, HP's HP/X, or LAN Manager for UNIX.

We need to talk about encrypted passwords for non-Microsoft SMB servers. Installing SP3 changes the way NT transmits passwords. In the past, NT transmitted its passwords to an SMB server in clear text. With SP3 installed, NT transmits passwords in an encrypted form, by default. This approach is great unless you're using non-Microsoft SMB servers. SMB servers expect to receive passwords in clear text, so the connection might not function after you install SP3 unless you make some adjustments. You can either reconfigure your SMB server to accept encrypted passwords (for Samba, see encryption.txt, which comes with the distribution) or reconfigure NT to send passwords in clear text. (I prefer to reconfigure NT, but if you must turn off this feature, see the sidebar, "Clear Text Passwords for SMB.")

Password Filtering
SP2 had a handy tool called passfilt.dll, which appears again in SP3. On its first release, no one noticed the tool, so I'll explain it in detail.

Password filtering gives you an additional level of control, which all secured environments can use. The Administrator can force certain password restrictions on user password choices. If the password choice doesn't match the criteria, NT rejects it, forcing the user to choose again. Poor password choices are a major avenue into your network.

The password filtering DLL requires users to choose a password at least six characters long. The password can't contain any part of the username or real name and must have three of the four following character types: uppercase letters, lowercase letters, Arabic numerals, and non-alphanumeric characters. For instance, "rockets98" is not a valid password, whereas "d0^X\k >" is valid--and much tougher to crack. If a password passes this test, it is allowed; if the password fails the test, passfilt.dll rejects it. Password filtering is pretty slick and long overdue. (For the steps to use this tool, see , "Password Filtering,").

In addition, you can audit the loading of Notification Packages by setting the audit policy in User Manager. Auditing will note each DLL loaded during password changes and user additions. This approach can help you detect a Trojan horse on your system. Auditing is a good idea, because a would-be intruder can easily modify a DLL to intercept passwords as they change. Microsoft provides the complete source code for passfilt.dll on its Web site. You can download the code and modify the password filtering rules.

Many arguments focus on how long to make passwords. Cryptography experts say that unless Microsoft changes the cryptography system it uses for the Security Account Manager (SAM) database (where usernames and passwords reside), the best password length is six to eight characters. This length considerably extends the amount of time hackers will need to crack a password. Brute force guessing of passwords is a popular way of penetrating a network today. At least three well-known NT password crackers are out there, so don't think that no one is trying to hack your network.

The ANONYMOUS Account
NT has a feature that lets anonymous users list domain usernames and all existing shares--whether they're hidden or not. These sessions are called null sessions. NT uses ANONYMOUS accounts for system-to-system communications, and listing user information. These accounts can be a potential security risk, as the RedButton program revealed. RedButton successfully attaches to a remote NT system using a null session and reveals sensitive information from the Registry. (For details about RedButton and other security exposures and defenses, see Mark Minasi, "NT Security Scares?" and John Meixner, "Foil Attacks on Your Registry," July 1997.)

Most people don't know about the built-in ANONYMOUS account--or how to use it: But if you're auditing security events and you open your Event Viewer to examine the security logs, you might find a few entries attributed to the anonymous user. These entries are very visible because the username clearly appears next to each security log entry. Security log entries related to anonymous access don't contain much interesting information unless you're a developer, but you can see that the account exists.

To address anonymous user access, SP3 adds the ability to disable it. SP3's new built-in group, Authenticated Users, works hand-in-hand with restricting anonymous user access. This group is similar to the Everyone group, except that anonymous users (or null session connections) never become members of the Authenticated Users group. Thus, you can assign permissions and rights to most users, while omitting the dangerous ANONYMOUS account.

However, disabling anonymous user connections has some implications. In a single-domain model, NT can always list account information as needed; but in a multidomain model, you can run into some restrictions if you disable the ANONYMOUS account. (The following example is derived from Microsoft's Knowledge Base article on this subject.) Say you have two NT domains: one for accounts and one for resources. The resources domain has a one-way trust relationship with the accounts domain (i.e., resources trusts accounts, but accounts doesn't trust resources). Users from the accounts domain can use the one-way trust to authenticate and access the resources domain. But suppose a user in the resources domain wants to grant some type of access to a user in the accounts domain. To select which users to grant access to, the resources domain user needs to obtain a list of users and groups from the accounts domain. How? By using a null session connection with the ANONYMOUS account. You use a null session because the one-way trust prevents the resources domain user from being authenticated for access to the accounts domain. If you disable anonymous user access, this approach won't work. The resources domain user who is trying to grant an accounts domain user privileges must proceed in one of two ways: either manually enter the known domain/username combination, or use an account from the trusted accounts domain to log on to the resources domain.

This new feature lets administrators allow only authenticated users to list account names and exclude anonymous connections. On the surface, this new feature sounds like it could hinder your ability to easily administer your domains. However, you have to consider the added security control this feature brings (to learn how to implement this functionality, see "Anonymous User Restrictions").

Multidomain NT shops can restrict anonymous connections without much loss of functionality, but plan in advance and take the proper steps before enabling this feature. In the resources domain and accounts domain example, before you enable this feature, add members of the trusted accounts domain to specific local groups. Then users logged on using accounts from the trusted accounts domain can continue to use authenticated connections to obtain a list of account names to manage security access control.

System Keys
You probably recall the recent release of NTCrack and PWDump utilities that dump the Security Accounts Manager (SAM) database and attempt to crack user passwords. System keys go a long way toward preventing such attacks. With SP3, you can create a system key for NT. Without the key, you can't boot the NT system at all. System keys use strong encryption techniques to increase protection on account password information stored in the Registry in the SAM database. Therefore, these passwords are much more difficult to attack, even if someone manages to obtain a copy of the SAM either directly from your NT system or from your Emergency Repair Disk. Protect access to your Emergency Repair Disks fiercely, as they contain incredibly sensitive systems information and a complete copy of your SAM database! In addition, check the permissions on your %SYSTEMROOT%\Repair directory, because it has copies of sensitive system information.

SP3 introduces the capability to use strong encryption techniques to increase protection of the SAM database. Ordinarily, only Administrators can use the Registry editor to access the SAM, and even Administrators can't directly view its contents. But you can easily fool NT into granting complete and unhindered access to the SAM. I won't say how, but disabling the Schedule service goes a long way toward stopping this security risk. That's right: Disable the Schedule service completely. But keep in mind that this action disables the use of AT commands for scheduling automated program execution.

This strong encryption capability is optional, and by using a 128-bit random cryptographic key (or password encryption key) to encrypt the password data, strong encryption protects private account information. Only private password information is strongly encrypted in the database, not all the account information. Every system using the strong encryption option will have a unique password encryption key. The key is encrypted with a system key. You can use strong password encryption on both NT Server and NT Workstation, where account information is stored. Strong encryption adds protection to the SAM, subsequent backup copies of Registry information (Emergency Repair Disk and Repair directory), and system backup tapes.

To use strong encryption, you need to run the syskey.exe utility that SP3 installs in the %SYSTEMROOT%\System32 directory. Only members of the Administrators group can run the syskey.exe command. This tool initializes or changes your system key, the master key used in protecting the password encryption key. Before you start, remember that protecting access to your system key is paramount. If someone compromises it, you could be in trouble. (Implementing the system key feature is too detailed to explain and is better left for a separate article or Microsoft's Knowledge Base article. Be sure to read Knowledge Base article Q143475 carefully before you start.)

Instead of giving you step-by-step instructions, I'll explain some features and design characteristics of system keys. Three options are available for managing the system key; these options are all designed to meet the needs of different NT environments.

1. Use a machine-generated random key as the system key, and use a complex obfuscation algorithm to store it on the local system. This option provides strong encryption of password in-formation in the Registry and allows unattended system restart.
2. Use a machine-generated random key, and store it on a floppy disk. The floppy disk is required for the system to boot and before users can log on. You must insert it when you see the prompt after NT begins the startup sequence. If you adopt this method, the system key is not stored anywhere on the local system, only on the floppy disk.
3. Use a password that the Administrator has chosen, to derive the system key. NT will prompt for the system key password during the initial startup sequence. The system won't become available for users to log on until after you enter the key. The password is not stored anywhere on the system. An MD5 (encryption algorithm) digest of the password is used as the master key to protect the password encryption key.

Of these three options, number 2 and number 3 introduce a new prompt during NT initialization: You need to manually provide your key for initialization to continue. These two options provide the strongest protection, because the master key is not stored anywhere on the system, and you can control access to the external password key or floppy-based key.

If you require unattended booting, you'll need to store the system key on the hard drive. But don't worry, the system key is reportedly stored using a complex obfuscation algorithm, and is accessible to only core OS security components. Microsoft says it will provide the means to obtain the system key from a tamper-proof hardware device attached to the system, thus creating the fourth, and most powerful way of handling system keys. I don't know when Microsoft will implement this fourth method.

A warning to would-be system key users: If you forget your system key or lose the floppy disk, you might not be able to start your NT system. Therefore, protect system key information diligently by creating backup copies of the floppy or giving the password to more than one person. If you lose the system key, you have only one way to recover the system: Use an ERD to restore the Registry to a state before you enabled strong encryption, and start over from scratch to implement the feature. If you want to use the password version of the system key feature, consider creating a long password, dividing it into parts, and giving an equal part to several different users. This way, no individual can boot the system, and all holders of a part of the password must enter their parts in the correct order before the system will boot. This approach can seem paranoid, but some people need this level of control.

You can configure strong encryption independently on the Primary Domain Controller (PDC) and each Backup Domain Controller (BDC). Each domain controller will have a unique password encryption key and a unique system key. You cannot use keys across multiple systems; each system must use a unique key set, regardless of domain participation roles. Before enabling the feature on your domain controllers, ensure that BDCs are completely in sync with the PDCs. Also, create a fresh ERD before you start. (Be sure to read Microsoft's Knowledge Base article Q143475 on this topic.)

CryptoAPI 2.0
As with many of Microsoft's names, CryptoAPI is an acronym. It stands for Cryptography application programming interface. CryptoAPI 2.0 gives developers core cryptographic and certificate functions and is an upgrade to CryptoAPI 1.0.

CryptoAPI provides the underlying technology to add security features to applications. Examples are the ability to digitally sign a document and send it over the Internet, and the ability to verify an individual's identity in an exchange of personal information. Signing documents is like attaching a secret code, or certificate, that you can positively identify as belonging to a certain owner. If owners protect their personal certificates from being copied, no one will be able to use a digital signing technique to impersonate them. This approach is like having a driver's license that identifies only you.

Certificate authorities are agents entrusted to issue the keys and attest to the validity of a given cryptography key. To get a key, you contact a certificate authority, such as Verisign, which will give you all the information about how to obtain a security certificate. (Find Verisign on the Web at http://www.verisign.com.)

You can see the CryptoAPI in action if you're using Microsoft's Outlook Express client (formerly, Microsoft Internet Mail). In the configuration settings under Tools, Mail Options, Security, you can configure your key certificate for signing email messages--once you have a key.

CryptoAPI 2.0 uses a service-provider model: Cryptographic Service Providers, such as the Microsoft RSA Base Provider included with SP3, provide the cryptography. This model lets developers easily adapt their applications to evolving cryptographic technologies and government export policies. Exporting cryptographic tools that use key lengths longer than 56 bits is a Federal offense (see Mark Smith's editorial, "The Key to the Kingdom," June 1997, for more information about this situation).

CryptoAPI 2.0 supports existing standards, such as X.509 v.3 certificate formats, ASN.1 encoding, and both PKCS #7 and #10 for encapsulation. Thus, applications using CryptoAPI can operate with other certificate-based systems that adhere to the same standards.

Microsoft says the release version of CryptoAPI 2.0 contains several updates to the developer's release of September 1996, including both parameter changes and naming changes. These changes are reflected in the crypt32.dll and wincrypt.h files. For complete details on the new CryptoAPI 2.0, be sure to consult the documentation at http://www.microsoft.com/security/tech/misf6_2-f.htm or http://www.microsoft.com/workshop/prog/security/capi/cryptapi.htm (if your browser doesn't support frames).

NT Security Info
You've been briefed on the new security enhancements in SP3. So, how do you keep up with all the new holes that are popping up these days? Monitor the security resources on the Internet. You'll find numerous mailing lists, Web sites, whitepapers, Frequently Asked Question (FAQ) lists, and other information sources. Try locating a good digest of security information. Digests usually contain only the important items you need, such as new security risks, new tricks, and new tools. One example that caters exclusively to NT security concerns is my free NT Security Digest (NTSD), published each month. Point your Web browser to http://www.ntsecurity.net, or http://www.ntshop.net (both lead to the same site).