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:
* Standard TCP/IP services (such as FTP, WWW, SMTP)
Most of the books on Internet security address TCP/IP issues
exclusively and very well. Since NT machines (especially not Internet
gateways) do not normally support NFS, NIS, Sun RPC, r* commands,
telnet server, and so on, it is not difficult to plug most of the
holes in TCP/IP with respect to NT. The biggest risks are likely to be
the SMTP and HTTP servers, so make sure you run these services under
an ordinary user account, and not the System account.
Given the simplicity of the subset of the HTTP protocol implemented by
the Microsoft Information Web Server, and given the current hysteria
about Internet security, you would think that server would have been
made secure from the day one. Unfortunately, the initial release had
some gaping security hole which would allow anyone on the Internet to
easily delete any of the files on your computer to which that Web
server had delete access. Not only that, but their actions wouldn't
even have been logged! Read Andy Baron's discussion of the whole
sordid affair. Or visit the World Wide Web Security FAQ for more
information about Web security.
HTTP CGI scripts can be a grave security risk if the person writing
them doesn't know what they are doing. Don't let unskilled users write
CGI scripts! The Unix oriented security books provide good guidance on
this subject, since there is nothing NT specific about CGI scripts.
* SMB services (native Windows file/print sharing, named pipes, NT RPC)
Few books on Internet security even acknowledge the existence of SMB.
An NT workstation installs by default with a Guest account enabled
with a blank password. If you attach such a workstation to the
Internet, anyone can connect to any shared directories on that
machine, login as Guest and wreck havoc with your filesystem. Or they
can connect to the registry on that machine (which is always shared,
as described below) and mess it up.
DISABLE THE GUEST ACCOUNT!!!
Also, it is possible to write a program that iteratively attempts to
login as administrator to your machine. Here is some example source
code for such a program. This program will generate over 1,000,000
login attempts per minute on an Ethernet. The number of logins on the
Internet might be smaller, but will still be high enough to crack
simple-minded password.
You can and should set a limit on failed logon attempts for all
accounts other than administrator. Once this limit is reached, the
account will be disabled for a time interval (for example 10 minutes).
This will severely limit the ability of a crack program to break the
password. You cannot set such a limit on the administrator account.
This is to avoid the possibility of denial of service attacks, where
all accounts on the computer are disabled due to repeated login
failures. However, you can and should rename the administrator account
to something obscure, and also make the password for the administrator
account long and obscure. You might also want to disable the
administrator account from logging on over the network.
The best solution is to disable SMB services altogether over TCP/IP.
If you have a router, you can disable udb/tcp ports 137, 138, 139 (the
NetBios over TCP/IP ports). If you have a direct dial-up connection,
you can remove the binding between the Server, Workstation and NetBios
services and the TCP/IP protocol. You can retain the bindings between
these services and the NetBeui protocol, to allow remote file access
to the gateway machine from within your internal network. This is the
solution I used in my network. See my site description for more info.
Once you have secured the gateway machine, you'll want to secure the
internal network. The simplest way to do this is to disable routing on
the NT gateway machine. You can install a firewall on this gateway
machine, to allow Internet access to users on your internal network.
If your users are primarily interested in Web and mail access, then
simple using a proxy Web server (such as the Purveyer Web Server) will
accomplish everything a firewall would.
* Netware services (various products)
There is no reason to be running any Netware services on an NT machine
connected to the Internet, so this is not an issue.
Lax registry permissions
NT installs by default with Everyone given write access to much of the
registry. To see just how much, use the Somarsoft DumpAcl program. This is
a major problem because the registry on any machine running NT, both
servers and workstations, can be accessed remotely using Registry Editor.
So a user running on some workstation can modify the registry on any server
or workstation on which this user has an account (normally this means all
servers), or on which the guest account is enabled.
Since the registry is similar to a file system, the obvious solution is
either to stop sharing the registry or else set registry permissions
securely. Unfortunately, there is no way to stop sharing the registry
currently. As far as setting permissions, this is possible in theory but
impractical because of the complexity of the registry. It is doubtful that
anyone besides Microsoft can give guidance as to exactly which registry
keys can be made read-only for ordinary users and which must be writeable
by ordinary users. It is not acceptable to set permissions on the
HKEY_LOCAL_MACHINE root key and let those permissions be propagated to all
subkeys. This will cause various problems with the functioning of NT (it
did when I tried it at least). If it is possible, then Microsoft needs to
explicitly say so. Furthermore, some keys should not even be readable by
Everyone (since they may contain sensitive data). If you assign read-only
permissions at the root of the registry and let this permission propagate
to all subkeys, you will inadvertently give read access to Everyone for
some keys which were not readable by Everyone before.
It is possible to enable auditing of the successful change of all registry
keys and then write a program to scan the audit log looking for changes
made by other than the admininstrator, but this seems a poor way to run a
system. It is analogous to letting all users write to all files, then
auditing the changes and punishing users who changed files they weren't
supposed to change. It is clearly better to just deny write permission to
begin with if you don't want the user changing the file or registry key.
Consider various scenarios. A malicious user changes a few registry entries
so that various services begin functioning strangely, but not so strangely
that it is obvious what has happened. The problems are not reproducible at
other sites and the sysadmin feels like a fool. If logging is enabled, the
sysadmin might eventually track the problem to the user who made the
changes, but in reality, most sysadmins will just reinstall NT. The user
might then wait a few months, then make the changes again. So the sysadmin
comes to the conclusion that NT needs reinstallation every few months to
keep things running properly.
It is also possible for a user to make the changes while logged on using
another users account (the other user stepped out of the room without
locking their workstation, or they wrote their password down in a notebook
and the malicious user found it, etc, etc). In this case, even if the
sysadmin traces the changes using the registry audit logs, they won't find
the real culprit.
Or how about this. Suppose the malicious user has an account and write
access to some directory on a server. For example, the user's home
directory. The user then creates a trojan horse program which does the
following:
1. Starts another program, whose path is the first command line
parameter. The remaining command line parameters are passed unchanged
to the other program. This way the user notices nothing suspicous
happening.
2. Gives the user administrative privileges, if possible. It will be
possible if the account under which the program is executing is an
administrator. If not possible, then exit.
3. (optional) Sends a mail message to the user informing them of success.
4. Performs some registry cleanup to erase all traces of itself.
The user then replaces some appropriate executable file path in the
registry with the path of this trojan horse program, followed by the
original path as the first parameter.
Note of Dec 1, 1995. A previous version of this whitepaper listed
HKEY_LOCAL_MACHINE\SOFTWARE\CLASSES\txtfile\shell\open\command as an
appropriate registry value to change. Perhaps someone at Microsoft read
this previous version because now the NT 3.51 resource kit recommends
making the HKEY_LOCAL_MACHINE\SOFTWARE\CLASSES tree read-only. They also
closed most of the other holes of this sort. But there is still the
PathName value under the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RasMan\CurrentVersion key. And if
this key doesn't exist on your system, then just use Somarsoft DumpAcl and
Somarsoft DumpReg together to find some other key which Everyone can write
and which has a .exe file as one of its values.
When the trojan horse program executes, it will start the original program,
give administrator privileges to the malicious user, notify the malicious
user via an email message or whatever and then erase all traces of itself.
The user can then do whatever they want to the server, including taking
steps to erase all traces of the attack. There is little you can do to stop
such an attack by someone who has an account on your network.
I have raised this isues of lax permissions with Microsoft and they are
supposedly "looking into it". I first raised the issue with Microsoft back
in late 1993, immediately after NT was released. In May 1994, I made the
information public, in the help file of the first version of Somarsoft
DumpAcl. In January 1995, I put it up on this Web Server. In November 1995,
Microsoft indicated via the NT 3.51 resource kit (page 43) that they do
acknowledge there to be a problem. But the solution they give just won't
cut it in the real world. Either we can or we cannot make the entire
HKEY_LOCAL_MACHINE tree read only to Everyone. If we cannot, then we need
to be able to disable sharing altogether. If this isn't possible, then
there will be a security hole. There is no way an average administrator can
review the permissions for 6000 registry keys, one by one, and decide in
each case whether this is a security problem and whether that key should be
made read-only or no access to Everyone. Only hackers have this sort of
time on their hands.
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 add permission only
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:
* Some applications require write access to the application directory to
store data.
* Many older Windows applications require write access to the
%SYSTEMROOT% directory to store .INI files. Newer 32 bit applications
should use the user registry instead of .INI files.
* DOS graphic programs require write access to
%SYSTEMROOT%\SYSTEM32\CMOS.RAM.
* The builtin NT backup program requires write access the
%SYSTEMROOT%\SYSTEM32 directory to store temporary files.
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
A WinWord document can contain a macro which runs when the file is opened.
These macros can perform very powerful operations, including file i/o,
sending mail or calling Win32 services. So a malicous user might ask
another, unsuspecting user to read a document the first user wrote. This
document contains a WordBasic macro which runs when the document is opened.
The macro copies all files from the unsuspecting user's personal
directories to a directory to which both users have read and write
permission. The macro then sends mail to the malicious user notifying them
of what happened. The document may take a while to start up, but the
unsuspecting user assumes this is because the document is long. The
malicous user later deletes the WordBasic macro from the document and
notifies the unsuspecting user to replace any copy they made, so that all
potentially incriminating evidence is destroyed.
It is also possible to write the macro so it calls a user written DLL that
does something useful, as well as copying files and performing other
hostile acts. This DLL might be large and complicated so that it would be
very difficult to disassemble it and prove that it was doing something
wrong. Even if you were able to prove that the DLL was accessing your
files, the author could say this was due to a bug in the DLL. If you
demanded the source from which the DLL was compiled, the auther could give
you some modified source. When you pointed out that this source could not
be used to build the DLL exactly, the author could reply that the source
had been modified to fix bugs since the DLL was originally built, which is
a perfectly reasonable explanation. By using a DLL in other words, there is
never any incriminating evidence.
There are other programs besides WinWord which can create files which
contain embedded macros which execute automatically when the file is opened
in the creating application. For example, Microsoft Access and Lotus Ami
Pro (these are just the programs I am aware of, I am sure there are many
others). Also, Postscript files, believe or not, 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. 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.
Why authors of programs feel the need to include powerful embedded macro
languages is something I really don't understand. It is possible to
accomplish most of what embedded languages do using DDE or OLE automation.
The advantage is that the end user learns one scripting language
environment and then applies it to different applications, as opposed to
learning a new language for each application. Microsoft has decided to
include VBA in all of their products, which reduces the amount of learning
to some extent. But why, I ask, not just provide good OLE Automation
capabilities so we don't need embedded macro languages at all, but can
instead use a separate Visual Basic program?
In any case, if it is absolutely necessary (for political or marketing
reasons) to include an embedded scripting language in an application, then
users should be allowed to set an option in the application so that they
are prompted before any macros are run (e.g. "this document contains an
embedded macro. Do you want to run this macro?"). There should be no way
for the document to override this option and the option setting should be
persistent (saved in a .INI file or the user's registry profile). If
absolutely necessary, the application can be designed so that if the user
refuses to run the macro, the application will refuse to open the document.
(In response to the WinWord Template virus, Microsoft has created a patch
for WinWord, which will notify you before running any autoexec macros. This
patch is available as self-extracting file WD1215.EXE from
http://www.microsoft.com/kb/softlib).
Interesting Note (5 May 1995). The big news this week is the Good Times
mail "virus". This is a hoax which alleged that there was a way to write a
mail message such that if you read the mail message, all your files would
be deleted. Users reading this hoax become frantic that they can no longer
read any mail without endangering their system. Actually, there is an
element of truth to this. If the mail message included an attached Word
document, then reading that attachment might cause a macro to be run which
deleted all your files. These attachments can be sent using SMTP MIME or
Microsoft and other propertiary mail systems.
WinWord Template Virus (28 Aug 1995). In case you haven't yet heard, there
have been press reports of a virus written in Wordbasic. This virus does
some fairly innocous things, like make you save the current document as a
template. It could have been much worse. Microsoft is scrambling to put a
virus scan and removal program out on the BBS's. We would be better served
by an option in WinWord which, when enabled (and enabled should be the
default although for marketing reasons it won't be), would cause WinWord to
prompt for user authorization before running any WordBasic macros.
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\EXPORT\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:
* Resetting the BIOS. Typically this is done by setting a jumper which
causes a slow discharge of the battery needed to preserve the BIOS
settings in CMOS. Discharge might take several hours, or several
minutes, depending on your motherboard. Don't trust manufacturer's
specs, since this is not something anyone tests.
* Moving the hard drive to another machine and reading it there.
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. There is no magic solution.
Some policies that might lessen the risk from rogue administrators (and
other users) include:
* Only hire trustworthy people to be administrators. In many
situtations, an administrator can be dispensed with. For example, the
owner of a small business might be their own administrator, instead of
relying on some outsider. Day-to-day NT administration is sufficiently
simple that this is a realistic option. On those occasions when an
outsider is required, the administrator can stand by and watch that
nothing suspicious is done.
* Have administrators work in teams and review one another's work.
* Establish a rule that says no one is allowed in the computer room
alone, especially not after hours, but also daytimes when the office
is nearly empty. If an administrator has to access the computers after
hours due to an emergency, they should be accompanied by a security
guard who should be trained sufficiently to be able to ask what the
administrator is doing, judge whether the answer or actions sound
suspicious, and who should always file a written report of the
incident.
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, 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.
Note as of January 19, 1996. The new Internet Server that is currently in
beta test has a more secure FTP server. This FTP server will eventually
replace the one that is builtin to NT 3.51.
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 (for example, a store clerk stealing customers's credit card numbers
and selling them to criminal organizations). Don't get so wrapped up with
trivial issues (like how some computer science student found a hole in the
40 bit Netscape encryption scheme - big news of Sep 21, 1995) 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-1996 by Somarsoft.