|
|
An Intro
to... by President, |
"A decent introduction to what Windows NT security is all about."
[Ed note: This is an article written for a Windows NT publication that was rejected because it was too long and had no pictures. I won't comment on whom the publishers thought their readership might be. Anyway, we submit it for your personal enjoyment.]
It’s getting both easier and harder to write articles about Windows NT security. Easier because as a user community we understand more and more about its security (although we yet have a long way to go) and harder because more and more readers have become accustomed to its basics. Superficial descriptions no longer suffice. Today we’ll try to satisfy both newcomers and those that have been around Windows NT security for a while. Don’t be complacent if you’re among the latter. A friend of mine who I consider experienced in these matters recently understood that he misunderstood a fundamental property of access control lists (ACLs), and a recent student who knew well the details announced that she finally "got it" – the broad, overall strategy of imposing ACLs on a file system. So sit back and enjoy our thoughts and challenges on Windows security. We hope to offer a little something for everybody.
Perhaps no other networking operating system has been as hotly debated and a more potent commercial force than Windows NT. While it’s not a "highly secure" operating system, it does display a significant commitment to security. It’s an impressive implementation of state-of-the-art security features that’s growing rapidly with the approach of the "Web world." However, misconceptions and divergent opinions abound. There’s a lot of hype among the facts. After a recent, extensive search through published works on Windows NT security looking for new and exciting "tips ‘n tricks" for making Windows NT secure, I found there weren’t many new ones. But then security is not about tricks. It’s about understanding the fundamentals then consistently and patiently planning, reviewing, and revising your practices and procedures, and this is much the tone we take today.
We begin by summarizing the cornerstone of Windows NT security – user authentication. You must understand its basics before you can make some central decisions about domain structure, the most fundamental determinant of who does what on your network and where they can do it. A networked operating system like Windows NT imposes security by granting specific services and fulfilling specific requests to some people and not others. Basic to this decision is "who is the person." Like most operating systems, Windows NT casts the user identity in a user account, a collection of information about what the user or users of that account can and cannot do on the system. Also like most operating systems, users can only gain services under an account if they can demonstrate they know its password.
The most basic tenet of Windows NT security is that it provides no significant services and fulfills no specific request until it associates a properly authenticated account with the request. When you physically log on, you specify an account and its password. This represents your identity on behalf of all the programs you run during your logon session. In the mainline Windows NT metaphor, there is no way to request local actions under another account.
When you request one of Windows NT’s remote operations, including file and print sharing, and a host of other services that use named pipes, like remote administration, the server first associates you, the client, with an account that’s visible on the server. In some cases, it’s the same account in use on the client (specifically, when it’s a domain account in a domain that both client and server share, but more on this later). In other cases, it’s a different account that in some way or another you have demonstrated that you know its password. All requests to the remote, "secondary" session from your client-side, "primary" logon session are represented on the server by this second account.
The only deviation from this scheme is that if the built-in Guest account is enabled, Windows NT server-side authentication uses Guest to match a remote request when it can find no match among its visible accounts. This allows unauthenticated, remote use of the computer. Even though that use may be tightly restricted by Windows NT’s access controls, it’s a dangerous practice. Windows NT Security 101 begins with "disable the Guest account."
Devising a Windows NT domain structure is one of your most important security tasks. While there are many "domain models" in the popular literature, the real secret is to understand how domains interact with Windows NT’s basic authentication mechanism and how you can use "matching accounts" to keep your domain structure simple.
A bit of terminology. Windows NT retails in two versions. Windows NT Workstation has only one basic configuration – that of a desktop-like workstation, although it can be used by many users who keep their own working environment (desktop colors and so forth). The product named Windows NT Server is a superset of the software in Workstation. It includes the ability to act as a "domain controller" or can function much like a Workstation with added services. The latter configuration is called a "server," although this poor word is overused. From a security perspective, we only care about Workstations and Domain Controllers. From a security perspective, the simple server configuration of Windows NT Server is the same as a Workstation.
Each account across a Windows NT network is stored on only one Windows NT computer, be it a workstation, domain controller, or server. (Backup domain controllers store copies of those on their corresponding domain controllers, but these are a special case.) A "local account" can be used only on the computer on which it is stored, either by someone sitting down and logging onto that computer (called a "primary" logon), or under a "secondary" logon session servicing some remote client user. (We might say a local account is "visible" only on its own workstation.)
When you log onto a local account then request a remote network service, your local account is not visible on the remote computer. Which account does it associate with your secondary, remote session? We know for sure it will be an account visible on the server to which you know the name and password. The details of the scenario depend somewhat on the service interface you use. File sharing, for example, effectively passes your client side name and password to the server who attempts to find an account of the same name and password. (Don’t worry – Windows NT doesn’t actually pass the password across the network, but the effect is the same as if it did.) If it finds a matching account name with a different password, it typically asks you for the server-side password. You may be given the opportunity to specify an account of a different name and its password. We call this process of finding an alternate account "account matching."
However, most accounts in a networking environment are "domain accounts." Domain accounts are stored on domain controller whose main job is to maintain those accounts and serve as the primary authenticator against those accounts. Although domain controllers may serve as general servers in a small environment, in larger environments they usually concentrate on security authentication.
Each workstation in a domain environment is a member of one and only one domain, and the domain controller is at the center of that domain. The domain accounts on a domain controller are visible and, in general, can be used on all the workstations that are members of that domain. Further, domain controllers can set up one-way "trust relationships" between themselves so that the accounts of one domain can be used on the workstations of another. If a domain A trusts a domain B, then B’s domain accounts can be used for both primary and secondary logon sessions on workstations in domain A, but not vice versa. They could be set up to trust each other and then both domains’ accounts are usable on their total workstation population. The key to understanding the security implications of trust relationships is:
| If a domain A trusts a domain B, then B’s domain accounts are usable on A’s workstations (and domain controllers). Thus the "usable in" and "trusts" arrows point in different directions. Don’t get confused. |
The manner in which you divide your network into domains is the most fundamental and strongest stipulation of who can do what on your network. While there are other, secondary restrictions, none are stronger. Read any of the popular treatises you like on the different domain models but keep this basic security principle in mind, use your common sense, and you’ll be well on your way to establishing the basis of your network security environment.
Do local accounts play a role in domain environments? Absolutely. Suppose just one user in domain A needs access to a computer in domain B, but B does not trust A. Making B trust A for this one user is unreasonable. The simple solution is to create a local account for this user on the computer in B. Same name, and, perhaps, same password. That particular user can then access the B computer as easily and transparently as ones on their own domain.
Local accounts are secret to keeping your domain structure simple. They handle the "exceptional" cases that might otherwise lead you to twist your domain relationships unnaturally.
Windows NT has the usual round-up of account security features. Your account holds the groups of which you are a member. Groups on Windows NT are largely shorthand’s for lists of users. The system could provide the same security without them, it’s just that you would do a lot more typing. However, as a shorthand they are a powerful way of simplifying access to objects, and as such bear careful planning and control.
There are a number of common-sense password controls imposed in a computer’s "account policy," which applies to all accounts stored on the computer. You can set minimal length of passwords, when they expire, whether user’s can change their password after they expire, and whether or not a user can use one of their last X passwords for a new one, where X is up to 24. You can also make users live with a new password for several days which discourages them from cycling through new passwords to get to an old favorite.
The most important password policy is the "locking" policy. When a bogus password is presented a specified number of times in a row within a specified time period, its account locks and cannot be logged onto. Accounts can unlock after a period of time, or administrators can designate that only they can unlock an account.
The locking parameters and the complexity of an account’s password (like its length and the kinds of characters from which it’s drawn) together determine the probability that it can be guessed. For example, a locking period of 6 tries in ½ hour with a ½ hour healing time means a penetrator can guess a maximum of 5 times per hour, or 120 times a day. Couple this with a password complexity of, say, 6 characters randomly drawn from lower-case alphabetics means the chances of someone guessing the password at this maximum rate for 1 month is about 1/100,000. This is the number you should care about. Raw password size is itself no measure of security.
Note that locking protection also applies to secondary logons. A remote user can lock your domain account by attempting to remotely access any computer on which that account is visible, preventing you from logging on anywhere. No security comes without a cost. Being an administrator means seeking the appropriate balance.
One exception to locking is that the local Administrator account never locks. Give it a nice, long, random password that you write down and lock up. Use this account only for "emergency" situations. Use instead other administrative accounts (which do lock) in day-to-day operations. Common advice worth continually repeating. The Windows NT 4.0 Resource Kit contains a utility that also locks the Administrator account except for local logons on domain controllers. A great idea but not really necessary if this account has a nice, long, random password.
Rights are special properties that administrators assign to accounts. Your account’s Rights propagate to all the programs you run in your local or remote logon sessions. These let your programs make special requests to the system that would not be fulfilled unless they had one of these Rights. Most are administrative in nature, and many used only by the operating system itself.
Each Windows NT computer (be it a Workstation, Domain Controller, or Server) has its own Rights database that associates Rights with some or all of the accounts usable on that computer. Hence, Rights are not stored in the account. Your domain account may have some Rights on some computers and other Rights on others. To minimize confusion, seldom change Windows NT’s default Rights policy, and when you must, build your custom Rights policies around domain-wide groups.
The two rights that govern local and remote logon are quite important. An account needs the former on a given computer to sit down and logon at its keyboard, and the second to establish a secondary, remote logon session on that computer. Their often unappreciated importance is that they can be effectively coupled with your domain structure and local matching account strategy to determine which accounts can be used where network-wide. These Rights can be just as instrumental in keeping your domain structure simple as local, matching accounts. Consider them carefully and use them creatively.
Along with authentication, access control lists (ACLs) form the cornerstone of Windows NT security. Without them you have have no security (except the light-hearted protections you find on Windows 95, which is not serious security). The older DOS/Windows 95 file system type called "FAT" does not have ACLs – only the newer Windows NT file system. If you’re concerned about security, never format your partitions FAT.
Every data object on a Windows NT system, whether it’s a user data file, Registry key, printer, or user-invisible "device object" can have an access control list (ACL), and most do. An ACL designates who can access the object in what manner. The kinds off access they allow differ a bit from object to object, but are generically: read, write, delete, change the ACL of the object, or make yourself the owner of the object. The owner of an object can always change its ACL, and you become the owner of any object your create.
If you’ve worked with Windows NT for any length of time, you’ve probably worked a bit with ACLs. We won’t belabor the basics of how you manage them. However, beware that there are a number of odd little (usually necessary) behaviors. It’s worth your while to a few days with a good book that takes you through the sordid details.
Your ACLs can run smoothly or turn into a horribly confused mess. The key is to organize your data into directory trees based on how they are to be protected. Each directory ACL has a default ACL that Windows NT applies by default to each newly created file. Your goal is to never change file ACLs from this default. Application programs are one reason why. For example, some applications create a "temporary" file in the same directory as the original document that may contain the data in the document. Most applications simply accept the default ACL on the temporary file, often because they were not programmed for Windows. If you protect the original file more tightly than its default, the temporary file is more loosely protected and your data exposed. More confusing yet, some programs do "file shifting." When you edit and save a file, they create an entire new file at the default ACL. If you previously tightened the protection on a file, you can loosen its ACL just by correcting a typo!
A directory’s ACL passes unchanged to new subdirectories. Therefore, the protections you afford a directory pass to its entire directory tree as that tree is created, and your goal is to make exceptions as little as possible. An imaginary picture of your file system ACLs, each distinct ACL value in a different color, should have broad patches of pure color — not a look strewn with multicolor confetti.
What most users fail to recognize is that they have now have one more, often overriding, consideration in how they structure their data directories. For example, a manager accustomed to working on Windows 95 (with no ACLs) may have structured their reports in directories named "Monday," "Tuesday," and so on. However, on Windows NT they may wish to protect them with a number of ACL values which do not correlate to the day on which the manager writes the report. This manager needs to reorganize the report directories based on these protection classes, for example: Public Reports, My Team Reports, My Boss’s Reports, and so forth.
There’s a small, mysterious ACL Right that bears special attention, called "Bypass Traverse Checking." Without this Right, if you do not have permission to enter a directory you can never gain access to any object in its tree, even if you are allowed access to that object. By analogy, if the door to a building is locked, you can’t get into its offices even if they are unlocked. This all changes when you give a user Bypass Traverse Checking. While they still cannot read or write a locked directory, they can pass through it to an object in the tree to which they have access (providing they know its pathname). By default, everyone gets this Right. I heartily recommend you remove it.
In summary, the secret is to plan your ACL directory structure completely and on "day-1." Base the structure on how the data is to be protected – and only secondary on other logical criteria. Aim for those broad patches of pure color. And turn off Bypass Traverse Checking!
How does Windows NT ACL-protect its sensitive areas, in particular the sensitive system root directory (usually named "WINNT") and the Registry? Rather loosely in versions prior to 4.0, but now (thankfully) quite properly. Most but not all of the sensitive directories and files in the WINNT are properly protected against modification by the general public, the Everyone group. However, the directory defaults are set up such that all new items give read, write, and delete to all newly created items. This minimized the hassle of installing new programs and running applications that tend to toss things into WINNT. Unfortunately, when you install new items, it’s up to you to protect them appropriately. And if you think most applications will even tell you which items they toss into the WINNT tree, much less how they should be protected, think again. Your only long-term hope is to make it clear to vendors that such security documentation weighs heavily in your buying decision. The Windows NT Registry is a large tree-structured database that holds thousands of configuration parameters for the operating system and its applications. In 4.0, the as-installed Registry is also well protected with the same philosophy that new entries are wide open.
Having said all this, it’s difficult for anybody outside or inside of Microsoft to vouchsafe the completeness of the WINNT or Registry protection. One fundamental problem is that there’s no strictly established methodology about what should go where inside WINNT or the Registry. WINNT\SYSTEM32 is the great dumping ground of third party (including Microsoft) applications. That so much utter fluff coexists beside some of the most sensitive files on Windows NT can only lead to problems. (For example, the "Read Me" file that Microsoft Developer Studio seemed to think was a necessary addition to the oft' perused files in my SYSTEM32 directory!)
Although a more complete set of specific advice is beyond our space allowance here, there are a few sources of help. Microsoft has a nice white paper on their Web site called "Securing Windows NT Installation" that makes some suggestions based on earlier document relating to C2 grading of Windows NT. I tend to avoid the configuration espoused by the C2CONFIG tool in the 4.0 Resource Kit. It’s a bit to nonspecific, leaves a lot uncovered, and is a little looser than the default install in a few areas.
Sites with modest security concerns can accept Windows NT as-installed, but need to reprotect the applications they install. Those with larger security concerns should batten down the ACLs but be prepared to ferret the inevitable application problems. (TIP: If you tighten down these ACLs, turn on auditing for write failures. When one of your users complains that something isn’t working, check the audit trail and adjust accordingly.)
There’s a third area that stores many critical Windows NT items, the internal hierarchy that serves as the root of all accessible data objects on the system including the file system and Registry. Regular users and even most administrators never see this hierarchy because there are no common tools for managing it. It’s critical that many items in this tree have proper ACLs. This is one area where we simply have to rely on Microsoft’s care and knowledge.
One of the difficult areas of security administration is making sure each administrator and operator has no more power than they need for their day-to-day duties, and that the more powerful roles are held by only a few trusted individuals. In my experience this is one of the most neglected aspects of overall system security largely because it just takes a lot of work to sort administrative duties out.
Members of the local "Administrators" group, which we call "full administrators," are all-powerful. Some administrators consistently try to curtail the powers granted these administrators, but there’s little hope and little point. A far better strategy is to grant this power to few individuals, try to assure they use it sparingly, and dole out the great majority of administrative duties to less-than-all-powerful groups, most notably the Server, Account, and Backup Operators on domain controllers, and Power Users on workstations. It’s surprising how many sites grant full administrative power to users who could and should make do with less.
You should also give considerable thought to creating certain network-wide administrative groups. Windows NT presents a simple metaphor where you place domain-wide full administrators in a predefined domain group called the "Domain Admins." This group is in turn included by default in the local Administrators group on each computer in the domain (although you can change this strategy if you wish). The Users and Guests groups follow a similar strategy, although they are not administrative. You can set up similar groups to ease the work and increase the simplicity of your domain-wide. For example, a Domain Power Users group include in the Power Users group of each workstation lets you easily allow universal Power User capabilities on workstations. (This grants no power on Domain Controllers, which is one of its features.)
The main reason for this concern about minimizing administrative access is that whenever an administrator runs an application, the application gains the full power of that administrator that it can use in any manner it likes even unseen by the administrator. If a powerful administrator ever accidentally runs a malicious program (an easy mistake to make) your security is out the proverbial window. We revisit this threat below.
Windows NT has a detailed and complete security auditing system, its security log, that coexists with its system and applications logs. You can enable auditing for seven classes of events, recording failures and/or successes. "Logon and Logoff" should always be enabled if you wish to audit at all, as should "Restart, Shutdown, and System." "Security Policy Changes" are useful but contain little detail about some of the changes. For example, you might see that an Account Operator changed a user’s account, but not what was changed. "Process Tracking" it too detailed to be of much use to people, although its events might be quite important for automated audit processing programs. "Use of User Rights" opens a floodgate and is of marginal benefit to most. Tons of audit data describing benign activities benefit no one, and only serves to obscure those events that might denote some genuine mischief.
Which leads us nicely to the most significant auditing category, "File and Object Access." Each object in Windows NT that has an ACL also has a similar looking set of audit control information. For example, for each file and directory of your choice, you can specify when an access audit event is generated based on user names, groups, and success or failure. This is an incredible amount of granularity and you’ll want to organize it carefully.
The problem with the Windows NT auditing system, and indeed most auditing systems, is that they generate too much detailed data for human analysis. Anyone who’s sorted through one of the audit trails comes to know the true meaning of finding a microchip in a manure field – too much chaff mixed with the kernels of wheat. Microsoft has left the automated analysis of this data to enterprising 3rd party suppliers, and a few are arising to the occasion.
My overall advice it to record events that don’t happen too often, like logons and logouts. Record object changes only where you have some specific purpose in mind. Wait for the sophisticated audit tools before you attempt anything more extensive. Auditing is no substitute for protecting your system in the first place – something about a barn door and bolting horses.
Capabilities in Windows NT (mostly Rights and permission to access objects via ACLs) are associated with the user identity. Each program a user runs has the full capabilities of that user. The program can use those capabilities in ways the user, who may be quite conscientious, does not detect. It gets worse than that. When one of your programs connects through an interprocess communication mechanism called a "named pipe," the holder of the other end of the pipe usually receives the full capabilities of your session and can use them in "creative" ways.
This means if a full administrator ever runs a malicious program, a program with a proverbial Trojan Horse, that program can totally subvert Windows NT security. Completely. Without exception. If you want to break into a Windows NT system, this is a wide and inviting avenue with few police.
The problem in today’s intranet-interconnected world is that it’s more and more difficult to avoid unknowingly bringing Trojan Horse software onto your system. The "macro" viruses serve as a prime example. Some programs, most notably Microsoft Word, allows one user (the evil one) to attach a program "macro" to a written document. When another user opens the document to read it (what harm could simply reading a document do?) the program runs, unseen by the reader. It has the full capabilities of the reader that it can use any way it wants: destroying data, mailing data to remote locations, or planting more permanent malicious code in previously safe programs and data – a virus. Vendors patch these problems as best they can depending on the degree of bad press they receive. However, most customers buy software for features, not security.
Consider also "DLL spoofing." Many programs, including administrative programs, use executable code from dynamic link library (DLL) files. The code runs in the full security context of the user. When a program wanders about looking for a needed DLL, it can look in many places, like the user’s current working directory, the directory in which its application is installed, and even directories in the user’s PATH variable. If you want to make yourself an administrator, just place a fake DLL in a location where a legitimate administrator unknowingly picks it up.
There are also a number of locations in the Registry where, if not properly protected, users can write values that "spoof" other users – get them to run a malicious program in place of a legitimate one they wish. While most of these locations are protected, there are lots and lots and lots of them, and we as a community simply don’t know if their protection is sufficient.
It all comes down to running only "trusted code," programs that in your faith and opinion harbor no malicious elements. But how to tell which from which is another story. The problem is that there are more and more open portals through which malicious programs can creep unnoticed. Enter the World Wide Web.
For Trojan Horse exposure, Web browsers are a class by themselves. There are many ways that simply clicking a hyperlink can download and run a program on your system with your full capabilities. This is one of the true battlegrounds between security and a world of cosmopolitan interconnectivity.
The two active Web page elements are prime centers of attention: Java and ActiveX. Both are programs that load from a Web page and run on your system. Their whole purpose is to do this automatically and invisibly. Because Java is an interpreted language, it can implement a security policy that can restrict Java programs, or "applets." For example, you might buy a security-aware browser with a security policy that lets you contain Java programs to reading and writing into a certain directory tree. These restrictions are sometimes called the "sandbox" and they are an important and effective constraint when properly implemented and consistently used.
ActiveX is a different story. These programs (called "controls") cannot be contained because they run as a regular executable program on your system. Microsoft is pioneering an encryption scheme called Authenticode that lets your browser assure that a control is properly "signed" by its creating company and untampered en route to your system. This is an excellent idea, but it doesn’t stop the programs from being malicious. It does give you a good idea of whom to blame! Authenticode is also being engineered to protect Java applets, and the resulting Authenticoded sandbox is what networking security should be.
It’s hard to formulate bottom-line advice in a world as wide as the Web, but you’d be wise to let no account with any degree of administrative capability run a Web browser – ever. If the user of such an account needs Web access, let them do so in an unprivileged account (although this can still bring malicious code onto your system). Educate your users on the dangers of Web-based Trojan Horses, and buy all the firewall proxy scanners your budget allows (more below).
We’ve already talked a bit about the Windows NT domain authentication strategy and some dangers of the Web. Now we mention a few points about working in a broad networking environment. Windows NT does not encrypt its networking traffic for confidentiality (hiding the date from prying eyes) or integrity (assuring you can detect when data has been maliciously modified in transit). This again is left to third party suppliers. Microsoft does assure confidentiality for its Remote Access Services (RAS) including when RAS traffic is carried by an intranet via the PPTP protocol. And U.S. citizens you can now get industrial-grade 128-bit encryption rather than the otherwise marginal 40-bit keys limited by U.S. export regulations. While I have always been suspicious of RAS’s key exchange algorithms, I’m willing to take them at face value.
It is at least theoretically possible to "hijack a session" on an Windows NT network. When the server establishes the remote session we described early in this article, it initially authenticates the user based on name and password. The system never sends the password across the network but instead uses a classic challenge-response technique. Once authenticated, the server sends an unprotected tag to the client and serves subsequent requests based on the presentation of that flag. An eavesdropper can easily read the tag and submit its own requests. While this is not an easy task, the only major barrier is that it gets into the arcane details of the networking protocols which are not widely available. However, this protection is classic "security by obscurity" which is little security at all.
Is this a security flaw? Not in my book. A security flaw is when a vendor promises one thing and delivers something weaker. Microsoft makes no pretense that its networks protect against these kinds of attacks. It does mean however that you should look to various add-on products if you deem this a threat to your site.
If you are connecting your network to an intranet or (gulp!) the Internet, you simply must do it through a firewall. Pick your favorite brand. The best of the bunch have application proxies that are quite smart about monitoring and screening certain kinds of intranet protocols. We use the Microsoft Proxy Server at our site, but there are many effective firewalls on the market.
Windows NT’s own native network sharing services, including file and printer sharing, and named pipes (which support many forms of RPC), can be easily and reasonably well isolated from an intranet to which your LAN is attached. First, you can bind these services to the NetBEUI protocol only, rather that NetBIOS-over-TCP/IP. Since NetBEUI protocol cannot pass out onto or in from a TCP/IP network, no outside agent can attempt to gain direct access to these services. Even if you choose to use NetBIOS-over-TCP/IP, this protocol scheme used UDP and TCP port numbers 137 through 139. If you configure your intranet gateways and routers to block these ports in both directions, you isolate these native NT services from the intranet. Of course, with either scheme your Windows NT systems cannot serve requests from the intranet. If you need to do so, encrypting protocols are your only effective protection.
Hacking finds holes and it’s an important activity against a system like Windows NT. One can find fame and even fortune by successfully breaking a target of this prominence. Hacks are inevitably over-hyped, but eventually a consensus develops on the various Internet based forums. If the claim is valid, Microsoft (who’s quite sensitive to security issues these days) invariably issues a prompt fix. This is a healthy process. Any commercial operating system the size and scope of Windows NT has security bugs – probably many of them. Hacking is one of the ways to exposed them. And it’s such great fun!
Two recent examples illustrate this process. The "PW Crack" attack claimed to easily decode user passwords on Windows NT. Briefly, Windows NT one-way encrypts passwords, called hashing, then stores them locally. It uses two hashes. The first algorithm has always been public, the other only recently exposed. Even so, the hashed passwords are stored in the Registry where only highly privileged users and programs can read them. If one can read the hashed password, one can mount a brute force attack where one takes a long list of possible user passwords, and one-by-one hashes them and compares them to one of the captured, hashed passwords. When you get a match you know the password. Given that most user passwords are cryptographically quite short, this is a relatively easy task.
The downside of this claim is that one must get past the Registry ACLs to read the hashed passwords in the first place. No system including Windows NT can remain secure when its items are not properly protected. But the surprising value of this attack is that the community realized that certain copies of the hashed passwords Registry might easily become exposed to the general public. For example, when you build an Emergency Repair Disk, Windows NT may store a copy of these hashed passwords unprotected in the file tree and on the floppy disk. Forewarned with this potential, administrators can take appropriate precautions.
There is another security issue related to this attack. Although Windows NT does not encrypt networking traffic, it does not pass cleartext passwords across the network, instead using a "challenge-response" authentication protocol. However, it has two formats for this protocol. The older one (no longer necessary for Windows NT but required to support older systems like Windows) has some weaknesses that make it easier for a network eavesdropper to mount brute force attacks against user passwords. In short, if you need to keep the older mode active, users need longer passwords to afford the same protection as the newer format.
The more significant "Red Button" attack showed that one can create a remote logon session without knowing a name and password. This is in direct contradiction to the basic Windows NT authentication policy we described early in this article. The attack obtains "Everyone" unauthenticated access to remote Registries, and who knows what else. This clearly needed to be fixed, but better found now than later.
My advice here is to keep your ear to the ground. Microsoft vigorously tracks these hacks and monitoring their Web site serves you well (http://www.microsoft.com/security).
It’s altogether too easy to rely on cute little security "tricks" that are useful in theory but hold little protection against a determined attack. Let’s examine an analogy. Suppose you purchased a Diebold safe as big as a refrigerator with walls as thick, and a huge, solid tumbler lock. You batten your valuables inside and turn the tumbler 14 times in each direction. You then place a small piece of cellophane tape across the door.
Question: Does this tape on the safe increase your security? In theory, yes. Is it worth it? Who knows? Tape is cheap. No self-respecting security guru will tell you not to do so for fear of sounding anti-security. The danger here is that an administrator who places several pieces of tape on their Windows NT safes may be lulled into a false sense of security, ignoring basic and much more difficult decisions and tasks.
Protections of this sort are also called "security by obscurity." A good example is the time-honored practice of renaming the administrator account, for a penetrator must now guess both the name and password. The chances of guess a randomly chosen 14-character password are astronomically small. However, if you rename the account under no circumstances should you then relax the password. Account names, even the administrative account names, are public knowledge among legitimate Windows NT network users and there’s never been a strong ethic for protecting them. A secret administrator name simply won’t stay that way long. Rename if you like, but it’s tape-on-the-safe and you should assess its value accordingly.
Finally we turn to the much discussed but almost universally misunderstood notion of Windows NT’s C2 evaluation. Most think that C2 rating means a system is secure (and perhaps that a system without this rating not secure). Not so. First, "security" is a relative term, like "user friendly" or "high-performance." What is "secure" to some users or sites is not to others. Second, security comes as much from how you manage a system as from its features. But let us return to C2.
C2 is an opinion. An opinion from an experienced, trained, largely unbiased team of government security analysts. This team has the full cooperation of the vendor (Microsoft) and access to source code, internal design documents, and the core software designers. The team works through often-tortured meetings with these designers to gauge their expertise, commitment, and thoroughness. At C2, the team will sort through some of the source code and virtually all the documentation and test results. They concentrate on fundamental system security architecture and are guided by the Trusted Computer Systems Evaluation Criteria, the "Orange Book." The team summarizes their study in a Final Evaluation Report, which for Windows NT is as fine an exposition of its basic security mechanisms as you’ll find.
C2 does not mean the system is "secure" in any particular sense of the word. However, it certainly should increase our confidence that the system’s security features have been responsibly implemented. Does C2 say the system is free from security flaws? No. But it helps. For example, when the team finds "problem areas" that are not in direct contradiction to the Criteria, they usually require the vendor to prominently note them in system documentation so that system administrators can at least work around the problems.
C2 is most definitely not a "mode" that you can turn on or off. The government does not give a fig as to what security features you do or don’t use. C2 is a point-of-sale badge of confidence, not perfect, not absolute, but definitely useful. And it’s features are yours to use or ignore as befits the "security" of your situation.
Windows NT’s U.S. C2 rating does not include its networking software. Does this mean the Windows NT is not secure because everyone uses its networking? No. It just means that we haven’t been given the same boost in confidence in networking as the rest of the system. (Anyway, Windows NT recently competed its European C2-like evaluation that included its networking component.)
Whether or not Orange Book evaluations will last much longer, and despite all they might be that they are not, that opinion from the evaluation team should certainly elevate our confidence in Windows NT a notch or two, even though it’s no claim to absolute "security."
Looking even beyond the upcoming version 5.0, we can make some guesses and issue a few opinions on the future of Windows NT security. Windows NT domains with their one-step trust relationships suffer by comparison to other systems in large environments. We can expect some improvements here. We’ll see alternative authentication cryptosystems, like Kerberos (technologically outdated by well standardized), that shore up the already reasonably secure Windows NT mechanisms. And public-private key authentication is a wonderful sign. ACLs will probably not change much, and we’ll always be wanting more sophisticated audit analysis tools.
The "nets" are becoming even more important and extending even further into our work-a-day worlds. There are three ways to counter networking security threats: encryption, encryption, and encryption. Publicly available cryptography has made more progress in the last few years thanks to the Internet than the two decades preceding. With U.S. government bending slightly on its 40-bit key export restrictions, we are close to having all the strong public/private and symmetric key cryptosystems we need. The secret now is to practically implement them, and with today’s schemes it all depends on the "certificates" of the public/private key cryptosystems. If we can weave an effective certificate infrastructure, the problem of en route attacks on information is essentially solved. Microsoft will concentrate much of its cryptographic attention on Windows NT, and once we can cryptographically protect from network "taps" and readily manage certificates, most of our networking concerns will be minimized.
However, our Trojan Horse threat is worse than ever. In the long run, increased security for Windows NT and all other commercial systems depends on their ability to limit the capabilities that "programs" – in their myriad forms – gain regardless who runs them. While good operational practice helps, it’s not fully reliable. Features for limiting what such programs can do is important to long-range security.
But most of all, security comes as much from administrative diligence as from operating system features. You simply must take the time to learn the basics and carefully plan your environment. Inspect it frequently, and give "tape-on-the-safe" the minor importance it deserves. Sort through the hype and keep your ear to the ground. Security is yours to use or lose, and Windows NT is a decent place to make your stand.
Steve Sutton is President of Trusted Systems Services, Inc., a security services, consulting, and training company specializing in Windows NT security (http://www.TrustedSystems.com). He is the author of the textbook Windows NT Security Guide (Addison-Wesley), and has almost 20 years experience in planning, designing, teaching, and marketing secure operating and networking systems.
-- Steve
Sutton
ssutton@TrustedSystems.com
© 1997 Trusted Systems Services, Inc., all rights reserved. Copying of this document is permitted so long as attribution is prominently given to the Trusted Systems Services web site http://www.TrustedSystems.com, and so long as the copied portions are unchanged. This article may not be sold. It may not be combined with other text into composite articles except by quotation with attribution.