The Hacker's Encyclopedia 1998/hackers_encyclopedia.iso/hacking/systems/windowsn.txt

Text File | 2003-06-11 | 24.2 KB | 458 lines

**************************************************************************
   Info: Windows NT Security Issues
 Source: http://www.somar.com/
**************************************************************************

Lax registry permissions

NT installs by default with Everyone given write access to much of the
registry. To see just how much, use the Somar 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.

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.

I have raised this isues of lax permissions with Microsoft and they looking
into it.

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.
Somar 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 Somar 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. cc:Mail is an example.
   * 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 Somar 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.

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.

Interesting Note. I was just reading about 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.

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.

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.

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 Somar 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

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.

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 there 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
examples 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. The use of the backup right as well as accesses to files can be
logged in the Audit log. Users who have both backup and restore rights can
read any file, modify it and write it back. As with the Backup right, use
of the restore right can be logged. User Manager is used to assign rights
to users and enable auditing of the use of user rights.

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

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.

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 SQL Server setup in
such a way that anyone with an account can read the entire database. Or to
have an 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.

Send comments and questions to [e-mail]
All material Copyright ⌐ 1995 Somar Software. Last updated 3 June 1995.