Ask Us About... Security

by Joel Scambray

May 2000

On This Page

And the winner is…

And the winner is…

Last week I asked readers what is an appropriate length for NT/2000 passwords, and what characters make for the most secure passwords. I am constantly peppered with questions of this nature, and well I should be: in almost all of the authorized penetration tests I have participated in, at least one NT/2000 system has fallen victim to a remote password guessing attack or a local dictionary attack on the SAM file. When considering the security of a multi-user environment, password composition should be at the top of your list.

A few of your wrote in to the Ask Us About…Security (heretofore AUAS) mailbox with the right answers, but for those who didn't, here's a quick refresher:

1. Surprise! On NT, passwords are strongest when they are 14 characters long, the maximum allowed by the User Manager GUI. But who can remember a 14-character password? The next best "magic number" is 7 characters. This is because the LANMan algorithm used to store the passwords within the SAM file breaks them into 7-character chunks before encrypting them. Thus a 10-character password is really 7 characters plus 3. The 3 are trivially guessed by modern password cracking tools, and it may provide clues to the composition of the other 7 (take, for example, the five-finger mambo: QWERTYUIOP – cracking the last three characters might make you guess about the other 7).

   Win 2000 introduces an interesting twist. The 14-character limit is raised to 127, but the LANMan hash is still used for backwards compatibility, and passwords are thus still vulnerable to the same types of attacks as with NT. Also, if you have non-2000 clients in your environment that do not support passwords longer than 14 characters, you may be stuck with this limit for awhile. At any rate, enforcing >14 character passwords is still unrealistic for most human-interfaced applications, so you are left with the same magic number on 2000: 7 characters makes the best password.

2. Anyone who's implemented the passfilt DLL from Service pack 2 onwards knows what characters make for secure passwords: different case (capital and lower), numerals, and special characters like !$%&. The basic idea is to make attackers search an increasingly larger wordspace in order to successfully guess your password. What is lesser known is that the non-printing ASCII characters increase the wordspace even further, and have the added benefit of preventing brute force attacks by most password guessing software (brute force attacks differ from dictionary attacks in that they simply guess randomly generated strings of characters until the find the right one). The non-printing ASCII characters can be accessed via setting the NUMLOCK key and holding down ALT while typing the appropriate three-digit ASCII code (such as 255). This is obviously a cumbersome requirement for everyday users, but non-printing ASCII codes are great for service accounts that never should be logged in interactively.

Judicious use of these principles will keep attackers guessing – for a long time. The same basic principles hold true for Win 2000, even though it makes such attacks harder to launch, since passwords are stored using strong encryption, or stored entirely within the Active Directory if it is installed.

Deleting built-in accounts

A reader inquired this week about deleting or disabling the built-in Administrator account in order to prevent unlimited password guessing against that well-known target. This is still not possible (even under Win 2000), but the account can still be renamed and the passprop utility from the NT Resource Kit can be used to enable lockout for the Administrator. Recently, a tool called DelGuest was posted by https://www.ntsecurity.nu that allows for the deletion of the Guest account, which formerly was not possible. Although the Guest account can be disabled or locked out, and is thus not as juicy a target as Administrator without passprop, attackers can still determine which account is Admin or Guest using the user2sid/sid2user tools and launch password guessing attacks against them. DelGuest provides a mechanism for narrowing this window just a little bit more. If you are using the Guest account to provide anonymous access to the domain, DelGuest will obviously break things. Which would be a good thing – you shouldn't be doing this anyway! Caveat emptor: according to the author, "DelGuest uses a way to access the SAM database which is definitely not supported by Microsoft, and it would be very difficult for me to determine that this technique can never cause corruption of the SAM database in any case. Thus, you have to be aware of the risk that DelGuest may corrupt the SAM database, which would be a very bad thing indeed." I have personally used this tool with no side affects on an NT 4 Workstation.

The New Firewall API

Another reader wrote in to report that he'd heard something about a new NT firewall API and wanted to get more details. Thanks this week to Ron Cully, Lead Product Manager for Windows Networking, who took some time out to answer the query (the words below are mostly Ron's with some paraphrasing).

Windows 2000 includes an API intended for use by firewall solutions to intercept traffic to perform inspection and filtering operations. This API runs in the kernel mode level of the OS. It allows multiple filters to hook in and intercept traffic before it passes in to the IP stack. This layer sits between the IPSec layer and the IP stack. If IPSec is active, firewalls can inspect traffic after it is decrypted and before it goes to IP as packets arrive. Firewalls can also inspect outbound traffic before it gets encrypted by IPSec. The firewall APIs are present on all flavors of Win 2000, so it will be possible to build personal firewall tools for Windows 2000 Professional as well more traditional network access control products using the Server versions. These APIs can take advantage of many of the network throughput improvements made in Win 2000 over NT 4, which has traditionally been a deciding factor for purchasers of enterprise-class firewall systems (Win 2000 Professional recently achieved a sustained 2.4 Gbps in point-to-point WAN testing conducted by the University of Washington, Nortel Networks, Microsoft, and others; this is reportedly a new industry record for a single system). Also, because the firewall hooks execute in kernel mode, performance is enhanced by eliminating context switching. This being said, packet-forwarding performance of Win 2000 in high throughput environments has not yet been tested publicly, and vendors who do not properly take advantage of these APIs may not perform as well as expected.

IIS auditing tools

A curious admin wrote in this week and asked about tools that can be used to perform a security audit on IIS. Aside from the tools normally used to check the security of the underlying OS (here's a good archive), I was recently pointed towards mdutil.exe, the IIS Metabase manipulation tool found on the NT Option Pack CD-ROM. A good overall description of what the IIS Metabase is and what mdutil is capable of can be found here.

From a security standpoint, mdutil is handy for dumping all of the configuration data for IIS to a command prompt. The resulting blob can be compared to a given policy and violations flagged easily. For example, one could use mdutil to check for unauthorized anonymous FTP services on a system by using it thusly:

mdutil get msftpsvc/1/AllowAnonymous

The Metabase is essentially the Registry for IIS, and as such it contains just about every feasible configuration parameter, including those relevant to security. To get a better idea of what its hierarchical structure looks like, run "mdutil enum /" to view the top level hives, and then try "mdutil –help" to see what parameters you can use to perform GETs like the one above. Of course, as with the Registry, be extremely careful when using mdutil as it can also be used to write values to the Metabase. The AUAS mailbox welcomes any suggestions for a list of security-relevant Metabase parameters that would form the basis of an IIS security audit.

Keep those email queries coming to the address below, and I'll keep my eye on what's boiling out of the security cauldron for next month's session.

Joel Scambray is a Principal of Foundstonehttps://www.foundstone.com/. He recently co-authored Hacking Exposed: Network Security Secrets & Solutionshttps://www.hackingexposed.com/, from Osborne-McGraw Hill.

Send your Security questions to the Ask Us About Security mailbox TechNet_AskUs_Security@css.one.microsoft.com. 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.