Ask Us About... Security, March 2000

by Joel Scambray

Welcome – please come again!

Drum roll please: Introducing the first TechNet Question &Answer column centered around security, Ask Us About… Security. Simply stated, the objective for this monthly piece will be to answer your questions about how to configure Microsoft products securely, new and old Microsoft security technologies, and general security best practices.

As a Q&A forum, the content will be necessarily driven by you, the reader. To answer your questions, I will plumb the depths of my experience, which encompasses over six years of immersion in information technologies, including stints as a field technician, test lab analyst, IT manager, and a security consultant to Fortune 500 organizations. Along the way I've written numerous articles, reviewed dozens of products, and even written a book on hacking tools and techniques https://www.hackingexposed.com/. And if I can't pull the answer from my own gray matter, then I'll serve as your conduit to the inside track at Microsoft, where the solution is sure to be found.

But enough about me. What's on your mind, security-wise? Send me your questions Ask/Security and I'll try to answer as many as time allows – the best ones I will share with everyone in this space (anonymously of course, to protect the security of readers). It's not as lucrative as Who Wants to be a Millionaire, but maybe -- just maybe – we'll both learn something.

Where can I find up-to-date information on Microsoft product security issues?

No, this isn't a softball I'm using just to pad my column pixels. [What? I don't get the analogy.] In my experience, a great many questions can be answered simply by pointing people to the right resource, and I figure there's no better place than the first column to highlight some of the best spots. Besides, Microsoft's link to product security bulletins has recently been changed. Previously, The Microsoft Security Advisor https://www.microsoft.com/security was the only place to find such information. Security bulletins can now be found on this portion of the TechNet site https://www.microsoft.com/technet/security/default.mspx, with links to archived bulletins, a sign-up form for Microsoft's email notification service, and links to several guides to securing networks, Web sites, and other portions of your IT infrastructure that need constant care and attention. Of course, I'd be remiss if I didn't point readers to some non-Microsoft resources as well. Some of my personal favorites for keeping up-to-date on the latest Windows security issues include:

Note: The sites listed in the above list are not administered by Microsoft, and Microsoft makes no warranty regarding the services found on them.

There are probably thousands of Web sites that deal with security, and of course these are only a few. Please send your favorites to TechNet Ask/Security and we'll periodically publish them in the archive to this column.

Q: My company is implementing Active Directory. What are some basic steps we can take to prevent unauthorized access to information contained in AD?

A: The answer to this question is sizeable, and will thus be broken up into two parts. Part two will appear in next week's column.

Like any directory implementation project, AD requires generous amounts of three key ingredients: planning, planning, and planning. Some of the security issues I have encountered while working with Release Candidates include:

1. Relaxed access control on AD objects due to backwards compatibility requirements for NT4 RAS servers. When installing AD, a binary decision must be made: relax permission on user information stored within the directory, or lose backwards compatibility with NT4 RAS servers. Guess which one most organizations will choose? Be aware that directory queries using standard LDAP-based tools (such as the ldp client from the Win 2000 Resource Kit) can yield potentially sensitive information if permissions are relaxed. Plan the migration of legacy RAS servers accordingly.

2. Physical security of AD systems to prevent unauthorized access to the ntds.dit file (the directory itself, stored in %ststemroot%\winnt\NTDS). By booting the system in DSRepair mode, raw access to ntds.dit can be achieved. Someone with the right know-how could manually alter directory content in a malicious fashion. Password hashes are also stored in AD. And yes, NTFSDOS from Sysinternals https://www.sysinternals.com/ still works on Windows 2000.

Stay tuned for more AD security tips next week. And remember, this is far from an exhaustive list that is sure to expand as AD sees real-world fire after February 17. Send your own tips to my mailbox Ask/Security

Q: Microsoft recommends turning off "parent paths" in IIS4, stating that it is a security risk if enabled. I am having a hard time convincing my managers to have the Web developers rewrite their code because of a "security risk," especially since I have been unable to exploit this issue myself. Is there any information that you can give me or anything that I can try?

A: Ahh, the ancient question: do actions count for more than words? Unfortunately, it usually takes a good scare to raise awareness of a potential business risk. That being said, I do NOT endorse unauthorized attacks on systems, even those you may administer in exchange for a biweekly paycheck. I'll let the debate over these statements rage offline, but meanwhile, you can check out this NTBugtraq thread https://www.ntbugtraq.com/default.asp?pid=36&sid=1&A2=ind9902&L=NTBUGTRAQ&P=R1228 for a discussion possible exploits of this problem, and other solutions.

Should this prove to be a dead end, then the only route left to you is using words. Send your developers these two articles from Microsoft's Knowledge Base. The first one explains how parent paths can be disabled (but not much on why...). The second provides a solution to errors returned to users if parent paths are disabled (essentially, a global find and replace on all ASP code replacing ../<filename.ext> with /<virtual path>/<filename.ext>). This isn't brain damage, even for a large ASP codebase, I shouldn't think (the usual caveats about regression testing apply here).

184717 : AspEnableParentPaths MetaBase Property Should Be Set To False https://support.microsoft.com/default.aspx?scid=kb;en-us;184717&sd=tech

226474 : Err Msg: Active Server Pages, ASP 0131 Disallowed Parent Path https://support.microsoft.com/default.aspx?scid=kb;en-us;226474&sd=tech

In my opinion, your developers should recode the apps, whether you can show them a specific vulnerability or not. This is especially true if your company depends on their Web site for any type of customer relations, or if there is any linkage to back office systems -- i.e. mission critical. I personally would not engage in any serious online transactions with a company that doesn't consider this a risk.

You should also refer to the IIS Security Checklist https://www.microsoft.com/windows2000/en/server/iis/htm/core/iisckl.htm for more information on this topic.

Until next time…don't accept any suspicious packets from strangers.

Joel Scambray is a Principal of Rampart Security Group https://www.ramsec.com/ . He recently co-authored Hacking Exposed: Network Security Secrets & Solutions https://www.hackingexposed.com/ , from Osborne-McGraw Hill.

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.