Windows NT Security Issues

These issues are listed in no specific order. Some of these are general security issues for all computers, some are unique to Windows NT. This list is not all inclusive. The emphasis is on more obscure issues, since the general topic of computer security is already well addressed by many books. Suggestions for additions to this list are welcome.

The length of this list does not indicate that NT is not secure. From both the official ("is Windows NT C2 certified yet?") and practical points of view, NT is more secure than most brands of Unix. (and yes, as of Sept 1995, NT is officially C2 certified in certain configurations).

Internet issues

NT supports several types of networking:

Remote registry access

NT installs by default with Everyone given write access to much of the registry. To see just how much, use the Somarsoft DumpAcl program. In NT 3.51, this was a major problem due to the remote registry access feature of Registry Editor. Any user could manipulate the registry on any server or workstation on which this user has an account (normally this means all servers in a domain environment), or on which the guest account is enabled.

NT 4.0 fixed this problem by introducing the following registry key: 


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg
This key is present by default on NT 4.0 server. It is NOT present on NT 4.0 workstation, but can be added. The presence of this key disables remote registry access, other than to administrators.

In order to understand the importance of protecting the registry, consider some potental attacks on an unsecured registry:

Permissions set improperly

If the file system has a large number of files (say 500,000), it is impractical to examine the permissions on each file using file manager. Somarsoft DumpAcl produces a report of permissions which groups files and directories with the same permissions, so the report of file system permissions is much shorter. Permissions are only shown for the root directory and files and directories below the root whose permissions differ from those of the root. If all files and directories have the same permissions, a report of permissions consists of a single item.

One of common ways for files to get "wrong" permissions is due to differences between the way permissions are treated when copying versus moving a file. Copying a file causes the file to inherit permissions from the directory into which the file is copied. Moving a file preserves existing permissions on the file. So, a user might create a file in a temporary directory whose initial permissions give Everyone full control. This user then decides to add some data to the file that they don't want other users to change. So they move the file to a directory where only they have write permission. However, the file will still have the original permissions, giving Everyone write permission. If the user had copied the file and then deleted the original, the file would have the same permissions as the directory. The Somarsoft DumpAcl report makes it very easy to spot files with "wrong" permissions.

Remote procedure calls

NT programs use remote procedure calls (RPCs) to allow various system services to be performed on a remote computer (i.e. a computer other than the local computer where the program is executing). For example, the ability to modify the registry on remote computers is implemented using remote procedure calls.

There are mechanisms in NT for the RPC server to learn the username of the RPC client and then to limit the functions it will perform based on that username. However, as shown too many times in this document, there is a big difference between having good security mechanisms and having good security. If the RPC server ignores the username or incorrectly gives too many capabilities to the Everyone account or whatever, then there is a security hole. Since this whole aspect of NT seems poorly documented, there is really no telling how many security holes there are in this area.

Securing a shared workstation

Many users have asked how to secure a shared workstation so users cannot do any damage to the machine. For example, a workstation in a computer lab at a university. As described above, there is no way to secure the registry. The file system can be secured by setting the entire drive to the following permissions: 


    SYSTEM                full control

    Administrators        full control

    Everyone or Users     read only

Permissions should then be reset on the %SYSTEMROOT%\SYSTEM32\CONFIG dirctory as follows: 


    SYSTEM                full control

    Administrators        full control

    CREATOR OWNER         full control

    Everyone or Users     add permission only

These settings allow users to create a profile, but prevent them from reading other users profiles, to avoid the security issues described in the section on Profiles contain sensitive information.

Permissions should also be reset on the TEMP directory (C:\TEMP or whatever) as follows: 


    SYSTEM                full control

    Administrators        full control

    CREATOR OWNER         full control

    Everyone or Users     read/write/execute access to directory

                          no access specified for files

These settings allows users to use the TEMP directory, but avoid problems with users being able to read temporary files containing sensitive information that were created (and never deleted) by other users. Even if user remove files with sensitive information from the temporary directory, there is the issue of permissions being retained when a file is moved instead of copied (discussed in the section on Permissions set improperly). So the permissions on the TEMP directory should be set so initial permissions on a file are restrictive. Users can later make the file world-readable if they want to.

There are other files and directories to which users of a shared workstation may need write access:

The above list is not all-inclusive. You can enable failure auditing on all files and then examine the audit logs after making the most of the file system read-only to determine what files users need write access to. You can also use the Somarsoft DumpAcl program to dump and print file permissions prior to making any changes.

Macro runs when document is opened

Various application programs (including Microsoft WinWord, Excel and Access) contain very powerful macro languages which can perform file i/o, call Win32 API's, and otherwise do anything a virus written in assembler language or C could do. These macros can be configured to run automatically when a file is opened in the application program. So, the old distinction between data and programs is now blurred. In the past it was possible to tell users "feel free to exchange data files with untrusted users, since these never carry viruses, just don't exchange .EXE, .DLL, .COM and other executable files". Now users have to be told to suspect all files. This severely impacts users ability to get their jobs done.

Also, Postscript files have file i/o capability. So if you open a postscript file in an interpretor, it might go out and modify any files to which you have write access. Some interpretors have explicit options to disable file i/o.

Also, Windows Help files (.HLP extension) can call DLLs (typical use is to customize the Help program in some way). So, suppose you receive a package containing a .HLP, .EXE and a .DLL file all together. You want to browse the .HLP file to see what this package is all about and whether you trust it enough to run the .EXE file. You assume the .DLL is called by the .EXE only. When you open the .HLP file, the .DLL is executed and it's too late if you decide the package is untrustworthy.

Some Internet Web browser are setup to automatically start up the application associated a document suffix. So if you click on an URL ending in .DOC, that file will be fetched and WinWord will be started with that file as the command line. If that file contains a macro, it will be run. If that macro is malicious, too bad for you.

WinWord and Access both allow the user to hold down the shift key when opening a document to prevent any macro from running. It is difficult to get in the habit of doing this (I am speaking from experience), especially when most of the Word or Access documents you open are your own, and therefore known to be safe.

WinWord 7.0 contains a feature which appears to warn users of macros which run during document loading, and give the user to option to not run the macro. This feature is enabled by default.

File sharing issues

The SMB file and print server protocol used by NT is much more resistant to impersonation and session hijacking than the NFS file sharing protocol used on Unix. This is significant since NFS is one of the biggest security weaknesses on Unix.

It is remotely conceivable that a gateway machine could hijack an SMB session and then read/write any files to which the true user of that session had access. However, the likelihood of this happening is very small, since true gateway machines are seldom used on LANs due to performance reasons. If the machine attempting the impersonation or hijacking is merely a node on the same Ethernet or Token Ring as the client and/or server, then it would probably be very difficult to perform the impersonation or hijacking. In particular, it would be difficult to get packets routed to the impersonating machine instead of the true destination machine.

In any case, the much more relevant security risk is that user data is transmitted in the clear and so can be easily read by any computer on any LAN over which the data passes. Remember that if you connect to a remote network drive over the Internet or other insecure connection, you are passing data back and forth whenever you read or write a file on the network drive. File manager gives the illusion of the data being local, which makes remote files easy to use, but which can also lead to security breaches.

This risk of eavesdropping does not exist for logons passwords, since these are never transmitted in the clear over the network, but rather a challenge-response protocol is used instead.

In the long run, it would be nice if Windows NT were designed so that all SMB protocol data passed over the network was automatically encrypted, using a key which was randomly chosen for each NetBios session. No directly competing operating systems have this feature and, until some do, it is unlikely NT will. If you have a need to transmit data over an insecure network and you want to be protected from eavesdroppers, you will need to use some sort of encryption. For example, there are router boxess that can encrypt all TCP data, but not the IP header which is used for routing. Put one of these routers at two sites and configure with the same key all data passed between those sites with be secure. You are still open to traffic analysis, however. Traffic analysis is a concern, for example, when an undercover spy wants to send reports back to the home office, or similar scenarios.

There may be some special network cards (with NT drivers, please) which perform on-the-fly encryption, to avoid the problem of eavesdropping on a LAN. Presumably the netcards would have to be configured by an administrator to contain a shared key. Manufacturers of such netcards who would like a link, please drop me a note.

Profiles contain sensitive information

Some users put their userid and password on the command line of the program manager item, for example for Microsoft Mail. This way they can start mail by just double-clicking the mail icon, without having to type in their password. This password will be embedded in the user profile.

The local user profile is stored in %SYSTEMROOT%\SYSTEM32\CONFIG and also on a file server share, if a named, domain-wide user profile has been assigned for the user. Permissions on these directories should be like: 


    SYSTEM                full control

    Administrators        full control

    CREATOR OWNER         full control

    Everyone or Users     add permission only

This is how permissions are initially set on %SYSTEMROOT%\SYSTEM32\CONFIG. Since CREATOR OWNER has full control, each user will have full control of their own profile. Since Everyone and Users have only add permission, they will be able to create a profile, but won't be able to read other users profiles.

In some cases, such as with 3270 emulator programs, passwords are included in keyboard macros (so the user can use F12 or whatever to initiate the entire logon sequence). These macros may be stored in the user profile or a file. If a file, users should be warned to make sure the directory where this file is stored is not world-readable. This is primarily a concern on shared workstations.

Ctrl-Alt-Delete does NOT protect against all trojan horses

Supposedly, requiring a user to press Ctrl-Alt-Delete to bring up the login screen protects against application level trojan horses, since the operating system always traps this key sequence. However, it does not protect against a trojan horse which has some cooperation from the keyboard device driver nor from a DOS program, masquerading as NT.

A DOS trojan horse would be particularly easy to write and install, provided the NT workstation allows booting from the floppy drive without a hardware password, or this hardware password can be circumvented, somehow. Once the DOS trojan horse program had captured the user's password and transmitted it over the network to the malicious user, it could throw up a fake blue screen of death, alleging some driver problem. The user would call the network administrator, the problem would go away after a cold reboot, and the incident would be dismissed as an NT or hardware fluke and would soon be forgotten.

Passwords in general

If a password is short and obvious, then it can be guessed. If it is written down in a notebook, it can be discovered. So pick a long password, consisting of a mixture of upper and lower case letters and punctuation, never write it down, and change it often (but not so often you feel the need to write it down). This is all well-known, but so important that it is worth repeating nonetheless. Finding someone's password written down is the lowest-tech way to break into a system, but unfortunately also the most common.

Special shares

NT shares the %SYSTEMROOT%\SYSTEM32\REPL\IMPORT\SCRIPTS directory, so that users can read their login script during login. Normally, all of the scripts are readable by Everyone. So be careful what you put in these scripts and this directory. Other special shares are created by other installed services, such as SNA server or SMS. Use Somarsoft DumpAcl to dump a list of shares and their permissions. And examine the permissions on the directories underlying the shares. Remember that the final access permission on a shared directory is the intersection of the share and NTFS permissions. So while you are setting permissions to restrict access, be careful you don't unintentionally completely remove access.

Win32 services default to running under SYSTEM account

Many of the internet Unix breakins occurred when someone discovered a bug in a TCP/IP service and took advantage of this bug to break into the system. For example, the infamous Internet worm took advantage of a bug which caused the stack to be overwritten if the finger daemon received bad input. Obviously, you should try to only run services which do not have bugs. However, the danger if there is a bug is greatly reduced if the service runs under an ordinary user account with restricted permissions, instead of under the SYSTEM account (which corresponds to the Unix root account). So, for example, run your SMTP service under an smtpuser account, and give this account limited privileges, instead of running it under the SYSTEM account.

Viruses and trojan horses

If you are not familiar with viruses, there are many good books on the subject. NT is better secured than DOS from viruses, provided you normally run under an ordinary user account (not administrator), and keep most system files protected against modification by user accounts. NT is also secure against boot sector viruses, which are the most difficult to eradicate, provided you never boot with a floppy in the drive, since NT does not allow non-privileged programs to write directly to disk.

A trojan horse (as I define it), is a program which secretly does something "bad" at the same time it openly does something "good". For example, a program might openly provide an interface to an online service, but secretly transfer private files to/from your computer while you are logged on.

Trojan horses are probably a much greater long-term threat than viruses. Viruses typically only destroy data in a fairly crude and therefore noticable way. Since the damage is soon noticed, the data can be recovered from backups (assuming the network administrator is doing their job properly). A trojan horse program, on the other hand, might perform very subtle damage, which might take years to notice. For example, it might search your network for files containing currency values, and then modify some of this values. Or the trojan horse might leak private data to the outside world, which might never be noticed.

The best precaution against viruses and trojan horses, is to treat an unknown program similarly to how you would treat a new business partner. Namely, watch for subtle clues of suspicious behavior, check references, run a credit check, don't give the person a blank check the day you meet them, etc. You should treat an new program with the same degree of caution.

Data on disk not encrypted

Anyone who has physical access to a machine can read file system data by either reinstalling NT (the installer can pick the initial Administrator's password and Administrator can read all files) or booting from a DOS floppy and reading raw sectors using a low level disk utility. In both cases, the user would need access to the floppy drive. On many machines, the floppy can be disabled via the BIOS. There are two ways to get around a disabled floppy:

These techniques require opening the computer case, so there should be no risk for machines stored in open areas where opening a case would be immediately noticed.

If the case can be opened, then you will need to encrypt data on disk. There are various products which allow you to do this, with varying degress of user-friendliness and transparency. (Any manufacturers who would like me to list their product and add hypertext links to their Web pages, just drop me a note).

If you need military grade security, it should be noted that fragments of any file that is stored unencrypted in memory can be written to the paging file. So software encryption products will not be sufficient in this case. What you need instead is a disk controller which encrypts data on the fly as it is transferred between memory and disk. Typically, the user would be prompted for a password by the disk controller BIOS during cold boot. An example of where military grade security is needed is a embassy which contains secret data on PCs. These PCs might fall into the hands of a hostile intelligence agency with adequate resources to extract information from the fragments of data in the paging file. For most users, such military grade security is not really necessary.

Backup/Restore user rights allow reading/writing all files

It is obvious that to perform a backup, the operator needs to be able to read all files. What is not obvious is that tape need not be involved. It is trivial to write a program in C which takes advantage of the backup right to read any file in the system. So be careful of who you give the backup right to. Users who have both backup and restore rights can read any file, modify it and write it back, or they can take ownership or change permissions.

User Manager is used to assign rights to users. There is an option in User Manager to audit the use of user rights, and this should include the backup and restore rights. However, because of a poor design of the audit logging mechanism, exercise of these rights are not logged unless a registry value is set as follows: 


key  : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

name : FullPrivilegeAuditing

type : REG_BINARY

value: 1

This issue is further documented in the NT 3.51 resource kit.

Administrator, services, drivers are "all-powerful"

The administrator can take ownership of any file and thereby obtain read/write access to it. Some users have complained about this aspect of NT, which they view as a security hole. In fact, this same issue has arisen in all previous operating systems, including mainframes and other computers which are traditionally viewed as secure. It has been issue for thousands of years, in fact: "But who will guard the guards themselves?"-Satires,IV,Juvenal. There is no magic solution.

Some policies that might lessen the risk from rogue administrators (and other users) include:

These are similar to the procedures that are used in such situations as securing jewels in a bank vault, or guarding secret military plans. It goes without saying that it can be expensive to implement the procedures described above.

Note that services which run under the system account and device drivers also have essentially unlimited powers. They can read/write any file, establish network sessions in the background and thereby transport data out of your network, create accounts, etc. See also the section on viruses and trojan horses.

Data on backup tapes not encrypted

The NT backup program does not encrypt data on tape. So anyone who has a tape can read it on another machine on which the user has restore privileges, such as their personal NT workstation.

FTP/Telnet passwords

Microsoft does a good job of warning people about the fact that FTP passwords are transmitted in the clear. Especially for machines connected to the Internet, it is probably best to allow only anonymous FTP, so that no one ever attempts to transmit a password to your machine over the internet. If you FTP or Telnet from your machine to another machine on the internet, the same warning applies: any password you enter or any data you transmit, could be intercepted by other machines on networks over which the data is passed.

FTP service directory

When using the FTP server that comes with NT 3.51, the home directory you specify for the FTP service is only the initial current directory. Ftp users can change their current directory. So if you specify a home directory of c:\ftp, any ftp user can change to c:\ and thence change to any subdirectories under c:\. Normal NTFS permissions will apply, of course, to whatever account the ftp user is running under. If you don't want ftp users to be able to see the root directory of your primary partition, you should create a separate partition for ftp and then configure ftp so that it can only read and/or write to that partition. The IIS FTP server in NT 4.0 does not have this problem.

Computer security in context

The possibility of outsiders breaking into a system is, for whatever reason, the security issue most people concentrate on. In reality, you are most likely to suffer serious computer related losses due to natural disaster (such as a hard disk failure) or from internal theft or misuse of data. Don't get so wrapped up with trivial issues that you neglect the bigger computer security context. This is obvious, but worth repeating nonetheless.

Application software issues

The really valuable data on a computer system is what is produced by applications and stored in file and databases. It is very important to write and install these applications with an eye on security. It does no good to follow all the guidelines above and then have a database setup in such a way that anyone with an account can read the entire database. Or to have a transaction processing monitor which runs under a privileged account and allows unprivileged users to submit requests that give them access to the entire file system.

Return to the Somarsoft home page.
Send comments and questions to info@somarsoft.com
All material Copyright © 1995-1997 by Somarsoft, Inc.