Ask Us About... Security, April 2001

by Joel Scambray

Greetings to the security faithful this month, as we answer your questions about Microsoft product security. This month actually presents a double-dose of material, as my January column is now online after some unanticipated delays–it covers many of the burning questions I've seen on multiple occasions in the AUAS mailbox: security across domains within the same forest, using DCOM through firewalls, and an update on Win32® SSH server products.

As always, before we begin, I want to draw everyone's attention to an item of particular relevance that occurred since the last installment of AUAS. It seems that VeriSign, Inc., issued two code-signing digital certificates to an individual who fraudulently claimed to be a Microsoft employee (see Microsoft Security Bulletin MS01-017). Individuals in possession of these certificates could use them to sign malicious code and distribute it via the Internet. It is possible that unsuspecting users could be tricked into thinking the software was signed by Microsoft and execute it in a trusted environment. One possible scenario is the distribution of harmful viruses that masquerade as authentic Microsoft code.

See the bulletin for information on a patch and several mitigating workarounds. One additional recommendation that I always make to those who use Internet Explorer is to open the Internet Options Control Panel | Advanced tab | Security section and check the boxes next to "Check for publisher's certificate revocation" and "Check for server certificate revocation." Most certificates issued by major vendors today don't support revocation checking, but hey, at least you'll be ready when they do!

In the meantime, everyone should pay a little closer attention to those dialogue boxes that pop up to confirm execution of signed code. It's a shame that an event like this had to occur to remind us all of the fragile state of our current public cryptographic infrastructure, but maybe it's time we had a wake-up call. For those who want to read up on the underlying principles of digital certificates, try this MSDN Web Workshop on Public-Key Cryptography.

On This Page

Conference Update

Conference Update

OK, one more thing before we take questions. The MIS Training Institute (MISTI) is presenting its Conference and Expo on Windows 2000 Security and Control on May 1-3, 2001, in Dallas, Texas, United States. Some big names in security will be presenting at this conference, including a keynote speech by Howard Schmidt, Corporate Security Office for Microsoft Corporation, a session on hacker-proofing Web sites by David LeBlanc, Senior Security Technologist for Microsoft, and two sessions by Eric Schultze, Security Program Manager with the Microsoft Security Response Center: one on migrating from Microsoft Windows NT® 4.0 to Microsoft Windows® 2000 from a security perspective, and another on Windows 2000 security templates. I can heartily recommend David and Eric's presentations (having attended a few of them recently at other venues). And if you're willing to hang around after the show, I will be presenting a post-conference workshop on common Windows 2000 security compromises on May 4. Hope to see you there!

Exchange Client-to-Server Security

Q: We want to use Microsoft Outlook® clients to connect to our Microsoft Exchange servers over the Internet. How do we configure our firewall? And how do we protect our e-mail from eavesdropping and from being modified in transit between an Outlook client and Exchange servers?

A: I've actually answered this one in a previous column, but since I got a few similar requests in my mailbox this month, I thought I'd point everyone in that direction again.

Here are some additional tips about configuring the Exchange 2000 SMTP service securely. Within the Exchange System Manger, select Properties for the appropriate SMTP default virtual server. On the Access tab, you can find some of the main security features that govern connections to Exchange via SMTP: Authentication, Secure communication (i.e., SSL, which can provide integrity and confidentiality for SMTP traffic), Connection Control (where IP address and domain name-based access restrictions can be set), and Relay restrictions (which is where you can disable the dreaded "open relay" configuration that is abused by spammers - by default, Exchange 2000 is set up to require authentication in order to be able to relay). If a client does not support authentication, then you can simply add its IP address to the list of IP addresses that are allowed to relay. (This is useful in scenarios where a Web application needs to send e-mail - you can add the IP address of that Web server so that it can send e-mail through your Exchange server.)

You can further restrict spam by looking under the Messages tab and setting appropriate limits to the number of messages per connection the number of recipients per message. Depending on your application, the default numbers can be lowered here. Hope this sets you on the right path!

Physician, RevertToSelf

Q: The Microsoft IIS 5 Security Checklist recommends that you scrutinize RevertToSelf API calls within Web executables closely. Why is this?

A: To answer this question properly, I first have to provide a little background detail about the architecture of Internet Information Server/Internet Information Services. Bear with me - it will lead to an important security consideration.

The IIS process (Inetinfo.exe) runs as LocalSystem, one of the most powerful and privileged accounts on a Windows NT or Windows 2000 system. Inetinfo uses impersonation to service requests from remote users. (The IUSR_machinename account is used for anonymous requests, which are typical over the Internet.) The RevertToSelf API call can cause commands to be run as LocalSystem (for example, "Revert from IUSR to LocalSystem").

Stick with me while I clarify a bit more. Typically, RevertToSelf would be called from an Internet Server Application Programming Interface (ISAPI) DLL, often called an ISAPI filter or extension. (There are differences between filters and extensions, but that discussion is beyond the scope here.) ISAPI DLLs provide a powerful way to create dynamic Web applications without the performance penalty of Common Gateway Interface (CGI) executables that must fork off their own processes for each request.

When ISAPI extensions are called, they are actually wrapped in the Web Application Manager (WAM) object, which can run within the IIS process or "out of process." If run in process, WAM runs within Inetinfo and RevertToSelf returns control to the LocalSystem account. If run out-of-process, WAM runs within a separate process (mts.exe) and RevertToSelf gets the IWAM_machinename user context, which is only a Guest account with very limited privileges.

Running out-of-process extracts a slight performance hit, but prevents unruly ISAPI applications from crashing the IIS process. This setting is controlled via the IIS Admin tool under Properties of site | Home Directory tab | Application Protection. IIS 5 sets this to "Medium" by default, which runs out-of-process (a setting of "Low" runs in process).

So, where's the security impact? If an existing ISAPI DLL calls RevertToSelf or attackers can upload an ISAPI DLL to an IIS server and execute it via another existing vulnerability, they may be able to run commands as LocalSystem.

How do you protect against this? One easy way is to ensure that the Application Protection setting is set at Medium or higher (again, Medium is the default for IIS 5). Another is to scour your Web site's code base for RevertToSelf calls and to weed them out wherever you can (as suggested in the IIS 5 Checklist). And as always, keep up with patches, and scrutinize NTFS ACLs to help ensure that people can't upload and run their own DLLs on your IIS server. Remember, allowing untrusted people to upload and run code on your Web server is a big no-no, as covered in Immutable Law of Security #4.

'Til Next Time

Hope I've filled some gaps in your security armor this month, and I look forward to seeing you again next time around!

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.