Ask Us About... Security, May 2001

by Joel Scambray

Lots of good questions came into the mailbox this month on a variety of topics, so we may jump around a bit in this column. Let's get to it!

On This Page

Security Notification E-Mail Service

Security Notification E-Mail Service

Q: How do I get myself listed on an automatic e-mail notification list for bugs, fixes, and so on, that affect security?

A: I get at least one of these questions per month, so here are the signup instructions for the Microsoft Security Notification Service again: https://www.microsoft.com/technet/security/bulletin/notify.mspx. There's no better way to receive news of Microsoft-released patches and hotfixes. I also recommend subscribing to security mailing lists like those mentioned in my first column, so that you're aware of issues as they arise.

What Happens to Those Saved Passwords?

Q: I want to remove the file that is created when I choose to remember my password in certain Windows dialog boxes. What is this file called on Windows 2000 Professional?

A: Under Microsoft Windows® 95 and Windows 98, there was a file you could delete to expunge saved passwords, but with Windows NT® and Windows 2000, this capability does not exist. Under Windows NT and Windows 2000, in certain situations like the one you mention, passwords may be cached in something called the LSA Secrets store, where they are not accessible by the standard user. (Even the Administrator account lacks built-in tools to access LSA Secrets.) Windows XP will provide a feature called the Credential Manager (also known as the Network Identification Keyring) to manage multiple credentials on a system, including passwords and digital certificates. Credential Manager enables you to add, delete, and edit credentials that you re-use regularly, including those associated with applications. Could it be a single sign-on for the masses? Hallelujah!

Services for UNIX Security

Q: Are there any known security issues in Windows Services for UNIX 2.0? I plan on deploying it at a company with high security demands.

A: For those that don't know, SFU is a collection of Win32® versions of widely used UNIX programs. I highly recommend it.

One specific issue I can think of is related to an interaction between Internet Explorer and the telnet client that ships with SFU. (The problem is with Internet Explorer, not SFU.) As you may be aware, telnet sessions can be invoked by Internet Explorer using the "telnet:" syntax in the address line of the browser. If a Web site supplied a link to a malicious telnet server and also supplied an additional command-line switch that logs a transcript of the telnet session to a file on disk, the telnet server could write arbitrary content to the log file. If the log file was constructed to be executable (like a batch file) and was written to one of the Windows start-up directories, it would be launched when Windows was restarted for any reason. The log-to-file switch is only available with the telnet client that ships with SFU.

Since this problem could also be exploited through HTML-formatted e-mail messages, it is important that anyone with SFU installed get the patch from Microsoft Security Bulletin MS01-015. Don't be confused by the title of this bulletin; it addresses a number of unrelated issues with Internet Explorer, including the telnet invocation problem just described.

Also, installation of SFU 2.0 creates an account called SFUUSER, which belongs to the Users group by default. SFUUSER is used only in certain circumstances by the SFU Remote Shell and Cron services (roughly equivalent to remote command prompt and AT Scheduler under Windows). If you are not planning to use these SFU services, I'd disable or delete this account. See the Microsoft Knowledge Base article 258859 for more information.

A quick survey of the Knowledge Base also turned up this problem: a Windows client computer may be able to access UNIX Network File System (NFS) resources, even though the client has not been given specific access to the resource when the client has the same name as an NFS client group. See the Knowledge Base article 289826 for more information.

On a broader note, it's important to realize that SFU introduces many UNIX-Windows compatibility features and tools. (We already noted the NFS utilities.) Important among these features are the Server for NIS, Password Synchronization, and User Name Mapping, which separately provide integration of UNIX and Windows user account information (some of which are optionally installed). Although I have not implemented these features personally, I am apprehensive when a functionality can manipulate user credentials, which are the keys to the kingdom. Investigate the appropriate and most secure way to deploy these features on your network, should you choose to implement them. See the main SFU link earlier on this page for several white papers on these features.

One powerful tool installed by SFU is a telnet server. Since telnet provides remote command-line access to a system, you want to make sure that it's locked down. Knowledge Base article 231470 discusses security considerations for SFU telnet servers.

SFU also may not support all of the security features available to native UNIX implementations. For example, the SFU Single Sign-On Daemon for Compaq True64 UNIX does not support Enhanced Security Mode features (see Knowledge Base 264502). Consult your UNIX system documentation to identify situations like this.

Assuming UNIX resources are properly locked down, the simple availability of these tools is probably not a major concern. But if you haven't secured your UNIX systems, SFU will allow a whole new crowd of Windows users to reach out and touch them, and vice-versa—from your UNIX users to your Windows systems. Dumb security decisions on either side of the house will probably be aggravated even more due to this wider and more diverse audience once SFU is deployed.

Phew! Who would've thought that interoperability could introduce so many potential security hazards! It's a shame that opening the door of integration always leaves room for uninvited guests—but that's the nature of security.

Windows 2000 Peer-to-Peer Compatibility

Q: I installed a new computer running Windows 2000 on a peer-to-peer Windows network made up of five computers running Windows 98 and a server running Windows 2000. When I attempt to access the new Windows 2000-based computer from a Windows 98–based computer, I get a message requesting a password for access; there is no place to enter a user name, only a password. I've tried passwords for all of the users that I set up on the computer running Windows 2000, and none of them works. However, I can access the new Windows 2000–based machine from the server that is running Windows 2000 without any problem, that is, a place to enter the password appears. Help!

A: You've come across a major difference between Windows 95/Windows 98/Windows Me and Windows NT/Windows 2000, a common stumbling block in scenarios like this. Windows 95, Windows 98, and Windows Me implement share-level security, which only specifies passwords to gain access to resources. There is no such concept of user accounts on Windows 95/Windows 98/Windows Me (and no, the "user" that you log on to Windows 95/Windows 98/Windows Me is not really an account, it's just a profile that centrally stores your preferred environmental configurations).

Windows NT and Windows 2000, on the other hand, both implement user-level security, which requires a valid user account to gain access to system resources.

Since Windows 95, Windows 98, and Windows Me have no concept of user accounts that map to Windows NT or Windows 2000, they don't even have the capacity to supply different user names when logging into Windows network resources. It automatically responds with the user name of the active profile in Windows 95, Windows 98, or Windows Me (the same user name supplied when logging on at boot time). There are two workarounds to this situation.

One is to create a user account on the Windows 2000 system with the same name as the profile stored on the Windows 95/Windows 98/Windows Me box. That way, when you try to log on to the Windows 2000 system, this user name will automatically get passed along, and since it matches the existing account on the Windows 2000 system, it will get granted access, assuming the correct password is supplied.

The other way is to implement a Windows NT or Windows 2000 domain, which you could do using the other server that is running Windows 2000 in your environment. Then each Windows 98 system could be made a member of the domain and would prompt for domain logon at boot time. The domain logon screen provides an input field for a user name. The added benefit here is that user accounts and passwords are stored on the domain controller where they can be centrally managed and more tightly secured. For more optimal security, install the DSClient from the Windows 2000 installation CD-ROM under Clients\Win9x\Dsclient.exe. (Knowledge Base article 239869 has more information about installing this extension.) A Windows 2000 domain controller exports many additional services, so be sure these are guarded closely. (See my March 2001 column for advice on securing Windows 2000 domain controllers.)

Shall We Meet Again?

See you in my next column during the month of June!

Joel Scambray is a Principal of Foundstone. He is co-author of Hacking Exposed: Network Security Secrets and Solutions from Osborne-McGraw Hill.

Send your Security questions to the Ask Us About Security mailbox. If your question is selected, you will see your answer in a forthcoming column.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is," without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.