Ask Us About... Security, June 2000

by Joel Scambray

June 2000

Welcome back for another action-packed episode of TechNet's new security column. As you read, note the many references to Microsoft Knowledge Base https://support.microsoft.com/default.aspx?scid=FH;EN-US;KBHOWTO&sd=GN&ln=EN-US articles. How about a long round of applause for Microsoft Product Support Services for keeping us all up-to-date!

On This Page

Antisepsis for I LOVE YOU

Antisepsis for I LOVE YOU

As to be expected, I received more than a few messages last month that screamed "Help! How do I stomp the LOVE LETTER bug on my Exchange server!?!?!?" Those who were listening on various security mailing lists (see below) got a timely earful of advice, which I will largely repeat here.

First of all, those that aren't already running third-party antivirus tools on their mail servers and at Internet gateways will hopefully look into it soon (hint https://support.microsoft.com/default.aspx?scid=kb;en-us;49500&sd=tech). None of the procedures outlined below will protect an Exchange server from infection, only eradicate the virus after the fact. For more general reading on virus protection strategies, KB article 224436https://support.microsoft.com/default.aspx?scid=kb;en-us;224436&sd=tech will help you fortify your shop against mail-borne malware.

Some specific advice on what to do against the Love Bug can be found in KB article 224493https://support.microsoft.com/default.aspx?scid=kb;en-us;224493&sd=tech, which details the use of isscan.exe. It allows administrators to scan the Exchange Server 5.x private or public information store and remove messages or message attachments. It removes files based on attachment file name and size, as well as subject line and date of the message itself. It removes files that are infected with the Melissa Virus by default.

Since the first variant of the Love Bug arrived in a fairly standard format, with a defined subject line (e.g. "ILOVEYOU"), you can use the Microsoft Exchange Mailbox Merge program (Exmerge.exe), version 3.71 to find which mailboxes have messages meeting specific criteria (including Folders, Dates, and Message Details) as defined in KB article 246916https://support.microsoft.com/default.aspx?scid=kb;en-us;246916&sd=tech. Symantec has posted information on the 29 known variations https://www.symantec.com/avcenter/venc/data/vbs.loveletter.a.html of LOVE if you're inclined to perform this sort of search. Obviously, this approach is quite labor-intensive with the many variations out there now, but may help with spot checking.

For end users, the advice is the same as it's always been: don't open any suspicious mail attachments. To assist in this, set the Outlook Tools | Options | Security | Attachment Security to High. I also set my Security Zone to "Restricted sites" on this same tab (those less paranoid than me may find this too restrictive, but it hasn't ever been a problem in my experience). Outlook Express users can use the Inbox Assistant to filter messages according to subject line (see 187298https://support.microsoft.com/default.aspx?scid=kb;en-us;187298&sd=tech).

As this article "went to press" (I write about two weeks before the eventual publish date), Microsoft posted an update to Outlook that offers three ways to protect users from email viruses (adapted from Microsoft's prose):

• E-mail attachment security prevents users from accessing several file types when sent as e-mail attachments.

• Object Model Guard prompts customers with a dialog box when an external program attempts to access their Outlook address book or send e-mail on their behalf.

• Heightened Outlook default security settings increase the default Internet security zone setting within Outlook from "Internet" to "Restricted sites" (glad to know I was setting mine right so far!).

For those worried about scripts simply run from disk, not just via email attachments, a new utility from Cerberus Information Security removes file associations for VBS,VBE,WSF,WSH,JS and JSE on Windows 98, NT and 2000. A less drastic solution posted to the NTBugtraq mailing list by Matt Rising suggested re-associating the VBS (and other) extensions with an "interception batch file" like the following example:

        wscript ask.vbs %1

Matt posted a sample ask.vbs script in his original post https://www.ntbugtraq.com/default.asp?pid=36&sid=1&A2=ind0005&L=ntbugtraq&F=&S=&P=3865.

Authentication Blues

A couple of authentication-related questions hit he AUAS mailbox this month. I'll tackle one of them this time around.

Q: Could you go over the default encryption methods used by Microsoft clients being authenticated by an NT or 2000 DC? I think that the username and password are encrypted by default, but can't remember.

A: Both NT and 2000 utilize challenge/response authentication, wherein the server issues a random value to the client, which then performs a cryptographic hashing function on it using the hash of the user's password, and then sends this hashed value back to the server. The server then takes its copy of the users hash from the local SAM or AD, hashes the random value, and compares it to the client response. Thus, no passwords ever traverse the wire, even in encrypted form (this is described more fully in KB 102716https://support.microsoft.com/default.aspx?scid=kb;en-us;102716&sd=tech

).

Homogenous Windows 2000 environments can uses the built-in Kerberos v5 protocol that is new in 2000. Kerberos is a time-tested standard that provides for mutual authentication of client and server, and also does not send passwords over the network. KB article 217098https://support.microsoft.com/default.aspx?scid=kb;en-us;217098&sd=tech describes the Windows Kerberos authentication process; a more general Kerberos FAQ can be found here https://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html. Windows 2000 is completely backwards compatible and will downshift to the appropriate authentication protocol if necessary. Microsoft recently released their specification for the Kerberos authentication PAC https://www.microsoft.com/technet/archive/interopmigration/mgmt/kerberos.mspx so that interoperability with non-Microsoft Kerberos deployments is easier.

Some time back, a weakness with one of Window's older authentication algorithms (LANMan, or LM) was publicized, whereby an attacker with the ability to eavesdrop on the network could guess the password hash relatively easily and then use it an attempt to guess the actual password offline. To combat this, Microsoft released an improved NT-only algorithm with Service Pack 4 (NTLM v2). Windows 95 and 98 clients can't participate in NTLM v2, so this wasn't a universal fix, but it can significantly improve the security of Windows NT-only networks..

For a description of how to set up NTLM v2 on NT clients and servers, read KB 147706https://support.microsoft.com/default.aspx?scid=kb;en-us;147706&sd=tech. Note that on Win 2000, this is configured under the "LAN Manager Authentication Level" setting under the Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options node within the Group Policy or Local Security Policy MMC snap-in. Another tip when testing on Win 2000 is to use the secedit tool to refresh local and domain-wide policies after changing the LM Authentication Level setting:

secedit /refreshpolicy MACHINE_POLICY

Here's a quick summary of authentication mechanisms:

I have purposely left out of this discussion consideration of MS-CHAP and other authentication protocols used by Windows in order to keep things simple. Consult the KB for more info (it's a great excuse for laziness, isn't it?).

Additional resources

I spent some time updating my subscriptions to various security mailing lists this month, and thought I'd pass along some resources that I forgot to mention in my kick-off column.

One is the NTSecurity.net https://www.ntsecurity.net/ site, which has long been a great source for up-to-date security analysis, reviews, and news. I finally subscribed to their Win2KSecAdvice mailing list after watching my colleagues get all the dirt first. Some of the other mailing lists I recommend are Security Focus https://www.securityfocus.com/' Bugtraq, FocusMS, and Incidents; NTBugtraq https://www.ntbugtraq.com/; and SANS Windows Security Digest https://www.sans.org/newlook/digests/ntdigest.htm. Some of these are high-volume lists, so if you want to cut down on the inbox damage, use the SET [list_name] DIGEST command as explained in each lists' FAQ.

Two new tools debut for auditing Win 2000

The RAZOR https://razor.bindview.com/ team recently released new versions of two powerful NT auditing tools that now work on Win 2000. These tools require Administrator privilege and in no way compromise Windows security. Administrators have full control over the machine, so these tools highlight the critical need to protect these accounts with strong passwords, local-only logons, use of the runas command under Win 2000, and other security measures discussed in past columns.. Additionally, they employ a programmatic technique called "DLL injection" that is not supported by Microsoft and may have unintended consequences. I will discuss them briefly here so that readers are aware of their capabilities and to encourage more careful consideration of how secret this information really is to anyone with Administrator privilege.

The widely-used pwdump2 password hash-extracting tool has long been employed by administrators and hackers alike to dump the LANMan and NTLM password hashes from the NT SAM. This new version of pwdump2 now works on Windows 2000 Domain Controllers, which no longer store hashes in the SAM, but rather Active Directory. It also does away with the requirement for manually finding the Process ID for lsass.exe. Extraction of password hashes is useful for system administrators who want to get a birds-eye view of password policy compliance from the perspective of a real-world attacker. The hashes can be passed through readily available brute force guessing tools in an effort to determine how long it would take an average computer to calculate the actual passwords using only the hashes. Such evidence can be eye-opening for users and management alike, and should help motivate greater attention to security within an organization (I've seen it happen almost everywhere it's tried).

The second tool is called lsadump2, which uses DLL injection to bypass the normal access control on security information stored by the Local Security Authority (LSA) in a form called LSA Secrets (KB 184017https://support.microsoft.com/default.aspx?scid=kb;en-us;184017&sd=tech and 230681https://support.microsoft.com/default.aspx?scid=kb;en-us;230681&sd=tech). Various version of LSA Secrets-dumping tools have circulated the Internet for some time now, but this is the first "official" public disclosure that I have seen. The important thing to realize about LSA Secrets is that it potentially contains passwords for accounts that logon from external domains, as well as Dial-up Networking passwords. Like pwdump2, lsadump2 can be an eye-opening audit tool for those that think they run a tight environment. All it takes is the compromise of one poorly-secured system with an external logon account, and intruders can island-hop into the external domain. This is not to say that such accounts are bad per se, but can be abused if not guarded carefully. As the saying goes, a chain is only as strong as its weakest link -- the availability of tools like lsadump2 shows that security needs to be strong on every system, not just the "important" servers.

Once again, these tools are for administrators concerned with auditing NT/2000 systems, require Administrator privilege, and do not introduce problems to environments where it is guarded tightly.

Plenty more on tap for next month, so stay tuned!

Joel Scambray is a Principal of Foundstone https://www.foundstone.com. He recently co-authored Hacking Exposed: Network Security Secrets & Solutions https://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.