It will probably move to Incolumitas future WWW-server, whenever we
feel that there is a web server that is secure enough and we got the time
to set it up.
0.1 Legaleeze
First off, unfortunately, I must include this goobedygook.
This text is not an endorsement for any product.
Nor is it a cookbook to be used by crackers to gain access to Windows NT
systems. The text tries to shed some light at security related issues
and problems with Windows NT. Microsoft, and more especially, their technical
writers and sales forces, often leave out several key words and key information
when describing Windows NT.
The document is mainly a collection of pointers to other information already
available, if you know where to look.
I am in no way affiliated with Microsoft
All trademarks, etc. are honored. Microsoft probably is the biggest holder
of trademarks in this document. To keep them happy and their lawyers unhappy,
I'll include extra blurb for them here. Microsoft is the keeper of the
following trademarks, amongst others, e.g. product names:
Microsoft, Windows, Windows NT, MSN, the Microsoft Network
All included material are copyrighted by their respective owners/copyright
holders.
Links to all kind of protected pages where you have to be a
member of some exclusive club of any sort, such as the Microsoft MSDN
Online, is denoted with three dollar signs. Example: $$$: Exclusive Members Only
0.3 Current version and updating information
The current version number of the FAQ is 0.41 The FAQ was last updated
29th of October 1997.
Please submit contributions and requests for updates to the
current maintainers
(ntsec@incolumitas.se) of the FAQ.
Updated all sections that contain links to Microsofts Knowledge Base. Since
Microsoft have changed their file structure and naturally the links that
points to the articles, we have to follow it. Please report broken links
to the maintainer.
Posters to the NT-security mailing list <ntsecurity-request@iss.net>.All texts
posted to the list is included by kind permissions of their respective
author.
People who have gotten texts included in this FAQ are
The so called orange book is part of the DoD "rainbow" series of books.
The official name is Department of Defense Trusted Computer System Evaluation
Criteria. There is another book, a red one, which is a "interpretation"
of the Orange Book. The NCSC has published a number of different interpretations
of the TCSEC. These interpretations clarify Orange Book requirements with
respect to specific system components. The formal name of the red book
is the NCSC's Trusted Network Interpretation of the Trusted Computer
System Evaluation Criteria. It is an interpretation of Orange Book
security requirements as they would be applied to the networking component
of a secure system. The Red Book does not change the original requirements,
it simply describes how a network system should operate in order to meet
Orange Book requirements for a C2 secure system.
Microsoft had a certain version of Windows NT, with a specific configuration,
on a specific hardware platform evaluated by NSA. The outcome was that
that specific setup is considered C2 compliant and the NSA guys from the
National Computer Security Center, NCSC, also wrote a report entitled the
NSA?s Final Evaluation Report on Microsoft. Inc.: Windows NT Workstation
and Server Version 3.5 with U.S. Service Pack 3. National Computer Security
Center, 23 June 1995.
The evaluation was just according to the orange book, not the red
book. Microsoft has since them continued the evaluation process to also
match the red book (i.e. networking parts) criterias, but this is not yet
finalized.
To have a C2 compliant setup, you must amongst other things have
Identification and Authentication mechanisms
Discretionary Access Control mechanisms
Auditing
Object Reuse
In practice, it also means that you have to
Turn off networking completely (since NT is just evaluated to the orange
book, not the red)
Disable floppy disk
Change the standard file system permissions to be more restrictive
Change a lot of permissions in the registry
That leaves you a not so usable client-server system. There is a tool that
come with the resource kit called c2config
that you might use to harden your system to a C2 level. You might also
want to see Microsoft's web page entitled
What is C2 Evaluation? Microsoft Sets the Record Straight
(http://www.microsoft.com/syspro/technet/boes/winnt/nt351/c2bltn.htm).
There is an on-line
html version (http://www.pinsight.com:80/~royg/security/dod/rainbow.html)
available of the rainbow series books that you might want to check out.
Microsoft has a blurb that describes the characteristics
of a secure system - C2 and beyond (http://www.microsoft.com/ntserver/c2char.htm).
There is a paper on a new information technology security standard called
common criteria (http://csrc.ncsl.nist.gov/nistpubs/cc)
that is available on-line. It is a proposed ISO-standard.
1.2 Crypto
Cryptography is one of the foundations for much of the new computer security
mechanisms. It provides protection from interception of clear text data
including: passwords, network packets, and storage (DASD and RAM). Crypto techniques
are also used for checksums, integrity control, etc.
The following links might be useful to read up on crypto issues:
RSA has a neat FAQ on crypto
issues (http://www.rsa.com/rsalabs/newfaq) you might want to look at.
Consensus has a FAQ on the
Secure Socket Layer, SSL (http://www.consensus.com/security/ssl-talk-faq.html)
Microsoft have a mail alias which everyone can use to send questions,
alerts, bug reports, etc. According to Microsoft, members from
development teams participate on an internal mail exploder.
The mail address is secure@microsoft.com
Get their PGP-keys here (http://www.microsoft.com/security/pgpkeys.txt). For information on PGP, see the PGP-section in this FAQ.
2.1.1 Where do I get patches, or, what is a Service
Pack or a Hot Fix?
Microsoft have an on-line database, called the software library, with program
fixes for both the NT operating system as well as applications. In Microsoft
lingo a patch or program fix is called service pack (SP). There are a
number of service packs out, both for different versions of Windows NT
as well as applications such as SNA server.
Service packs are cumulative. This means that SP2 contains all of
SP1 as well as the fixes introduced in SP2. Service packs often update
a great amount of code by replacing major DLLs. Since most large
applications (such as back office and development components) bring
their own versions of "system" DLLs, service packs has to be applied
after each and every "system update", where the term "system update"
is not clearly defined. Any action that replaces any component updated
by a service pack or hotfix has to be followed by applying latest SP
and all hotfixes. Remember that adding hardware often install new
software, which may have to be updated by SP and/or hotfix.
Hot fixes are intermediate fixes released between service
packs and are not considered fully regression tested, and as such not
recommended by Microsoft to be applied unless one really need the
feature they provide. Lately, a bunch of security problems have been
solved by means of releasing hot fixes.
Another thing on the subject is language or locale. If you are
running a non US version of NT, you will not be able to apply all of
the hotfixes. Some of them are not language dependent, while others
refuse to install on anything else but a US version. If you have the
option to do so, run US version of NT at least on your servers. By
doing so, you will have the option of installing a hot fix dealing
with a security problem immediately when it's released and not have to
wait for the next SP to appear. Not to mention that you'd have to wait
for the next SP to be ported to your language, which of
course may take a while, the time depending on what language you are
using.
If you cannot, or do not want to, download software like this from the
net, you can contact your local Microsoft representant and ask them about
the service pack you need.
Impersonation is the ability of a thread to execute in a security context
other than from that of the process that owns the thread. This enables
a server to act on behalf of a client to access its own objects.
A privilege is used to control access to a service or object more strictly
than is normal with discretionary access control.
For more information, see
Microsofts article on Privileges
(http://www.microsoft.com/msdn/sdk/platforms/doc/sdk/win32/sys/src/security_15.htm)
2.1.5 What is an ACE (Access Control Entry)?
Access-Control Entries that is used to build Access-Control Lists (ACLs).
Each ACE contains the following information:
A SID, that identifies the trustee. A trustee can be a user account, group
account, or a logon account for a program such as a Windows NT service.
An access mask specifying access rights controlled by the ACE.
Flags that indicates the type of ACE and flags that determine whether other
objects or containers can inherit the ACE from the primary object to which
the ACL is attached.
For more information, see
Microsofts article on Access-Control
Entries, ACEs (http://www.microsoft.com/msdn/sdk/platforms/doc/sdk/win32/sys/src/security_10.htm)
Microsofts article on Access-Control
Lists, ACLs (http://www.microsoft.com/msdn/sdk/platforms/doc/sdk/win32/sys/src/security_9.htm)
2.1.7 What is SRM (Security Reference Monitor)?
The Security Reference Monitor is the kernel mode component that does the
actual access validation, as well as audit generation.
2.1.8 What is LSA (Local Security Authority)?
LSA stands for Local Security Authority. This is an internal subsystem
(as opposed to an environmental ditto, such as Win32) within Windows
NT that "generates access tokens [...], manages the local security
policy, and provides interactive user authentication services" (from
"Windows NT resource guide", ISBN 1-55615-653-7).
2.1.9 What is SAM (Security Account Manager)?
SAM stands for Security Account Manager and is the one who maintains
the security database, stored in the registry under HKLM\SAM. It
serves the Local Security Authority (LSA) with SIDs. The SAM maintains
the user account database.
2.1.10 What is a secure channel?
There is some confusion on this point when you consult the Microsoft
sources on the subject. Ever since MS discovered the Internet, a
secure channel is any point-to-point network connection established
between a client and a server that "provides privacy, integrity, and
authentication"
(see
$$$: Microsoft Internet Security Framework: Answers to Frequently
Asked Questions ).
"Before Internet", a secure channel was (and still is) the magic
connection between WNT computers in a domain. This kind of channel is
used for transportation of sensitive data, such as user credentials
during a domain logon and replication of the account database between
DCs.
The secure channel is established as soon as the domain member machine
is booted and is based on a shared secret that is used as the key for
encrypting the data that travels through the channel. Each domain
member has a machine account defined in the domain SAM database that
is created when the machine joins the domain. The password of this
account is used as the shared secret for encryption of the
channel. The member machine stores it in the registry, where it can be
retrieved using the
lsadump program by Paul Ashton <paul@argo.demon.co.uk>.
A problem with this is that the initial password (on a WS account) is
poorly chosen (unicode(machine-name)). This means that anybody that
can listen in to the network at the time of a domain join will be able
to calculate the session key used to encrypt the channel, and by this
can get hold of the user credentials of anybody doing a network logon
from that particular machine. The password is changed as soon as the
machine is rebooted after joining the domain and then periodically
changed every 7:th day, but the new password is communicated through
-- guess what -- the now not so secure channel, so as long as the
listener keeps his ear on the wire, he will have the session key. No
known solution, but the algorithm for encrypting the new password is
not published (yet).
Each process has an associated access token which is used by the
system to verify whether the process should be granted access to a
particular object or not. The access token consists of a user SID, a
list of group SIDs representing the groups the user belongs to, and a
list of user rights (privileges) the user is blessed with.
In general, any computer that is not physically secured is not fully secured.
If anyone is able to get access to the machine, it is possible to boot
it from a diskette, CD-ROM or just steal the hard disk and use it in another
computer.
2.2.1 Are there any NT based viruses, or can NT be susceptible for other viruses?
Some types of viruses, such as those written in a high-level language
such as Java, MS Word scripting language, Excel macros, etc, will be able
to perform some tricks on a NT machine as well.
According to DR Solomon, the MS Word based concept virus spread widely
in part because several companies, including Microsoft, have shipped CD-ROMs
containing the virus.
Windows NT machines can be affected by other types of viruses if you
use, for example, dual boot to run some other type of operating system
on the same hardware, e.g. OS/2, UNIX or other version of Windows. When
using a coexisting, bootable operating system, if you have a virus in effect
that destroy the boot sector or something like that, your NT partition
will probably be destroyed as well.
"many old DOS viruses work fine in a DOS box under NT. Most old boot
viruses will prevent NT from booting and might give a 'inaccessible boot
device' error. "
Since Windows NT machines are used as file servers for other systems, such
as MS-DOS, Windows 3.X and other clients, there are a number of NT-based
anti-virus programs. Some of them are
2.2.2 How do I get my computer C2-level secure,
or, what is c2config?
On the CD-ROM that is included in the NT Resource Kit, there is a program
called c2config that can be used for tighten the security of a NT based
computer.
Be aware, that c2config will not work well on systems with localized
environment, e.g. a german NT that uses ACLs in german, not in english.
2.2.3 Are there any known problems with the screen
saver / screen lock program?
Yes. In version 3.5 and 3.51, if the administrator decide to kick a user
off, then the admin has a small time window to see the content of the users
current screen and desktop.
Another problem is that a tool from the Resource kit might be (miss-)used
to deactivate the screen saver on a remote computer. See article Q142018
on shutdown.exe in the Knowledge Base.
2.2.4 How can I secure my client computers
against my users?
One way to make it harder for the local user to do any harm to the system
is to have a local PC without any hard disk or floppy disk. To boot, the
system will need to talk to a boot server over the network.
Check out Dan Shearer's document on
remote boot (ftp://lux.levels.unisa.edu.au/pub/doc/RemoteBoot.txt)
In the case that you do have a hard disk, mandatory profiles is a
way of restricting the users access to the computer. A couple of things
pointed out by David LeBlanc in a posting to the NT Security mailing
list:
Remove the execute right from the inheritance ACL of each
directory where the user can create files. This way, any file that
the user in one way or another after all managed to create on the disk
would be impossible to execute.
If the machine has a mail reader installed on it, make sure that
the mailer is configured to not allow running of any executables attached
to a mail.
It can. Memory pages are swapped or paged to disk when an application
needs physical memory. Even though the page file (see Control
Panel->System->Performance->Virtual Memory) is not accessible while
the system is running, it can be accessed by, for example, booting
another OS.
There is a registry key that can be created so that the memory manager clears the page file
when the system goes down:
Note that the clearing of the page file only is done when the system is brought down
in a controlled fashion. If the machine is just switched off or brought down in any
other brute way, of course no clearing will be performed.
2.3 File system
As shipped from Microsoft, most versions of NT I've ever encountered have
had very weird access control list settings on the system files and directories.
A lot of files and directories have had "Everyone" with "full control"
capabilities. This is true for both NT 3.51 and 4.0.
One way to examine which files that have strange permissions are to
use SomarSoft's DumpACL program.
If you want to really lock something down hard, then you set the root
directory to full access for administrators and system, list access to
users (not Everyone). Let that work all the way down the tree. You then
go in and loosen things up as need be, but what you've just done is ensure
that any new directory that gets created will have those permissions. You
then need to make sure the print spool directory has full access to creator\owner
(see the NT Resource Kit, 3.51 Update 1 (also known as vol 5)). I'd also
go through (using cacls, or you can use the search facility of either file
manager or explorer) and set the permissions on all of the executables
and DLLs to full access to admins (or if people normally work on that machine
under admin status, remove write permission for admins), and list only
(read-execute) permissions to users. Note that you've just made it difficult
for users to install any software. This could be good or bad, depending
on what you want to do. You could make a list of common DLLs that are updated
often and give users delete permission.
Now you apply the "smoke test" - log in as a user, and see what is broken.
Some programs insist on being able to write to an .ini file in the system
tree - if users can't write to (or create) these files, these programs
will fail. Change the permissions as need be. If you go overboard, you
can even get a situation where non-admins either can't successfully log
in, or get a desktop that is completely blank (I did this, much to my astonishment).
If you want to allow users to store file locally, make sure that they
have full rights to their own directories. Note that under NT 4.0, a user's
desktop profile, and numerous other things are stored under the system
tree - look in %systemroot%\profiles, and make sure each user has full
rights to their subdirectory - it should be admin, system, and user have
full access.
You'll also want to loosen up the temp directory - a good thing is to
give users list access, but creator\owner full access. There may be other
directories that need work, depending on what apps you have, and whether
they have any notion of multiple users - one example would be the cache
directory for your browser.
Since people have a lot of different needs, there is no single answer
- it depends on your environment.
Examples of things that might break when one tighten file permission security
includes
Microsoft has an article with IDQ153094
(http://www.microsoft.com/kb/articles/q153/0/94/htm) that describes
what to do if you secure some files and change some ACLs that you should
not. Fixing Microsofts broken file system permission setup might hang your
system real bad and make it un-bootable. Read the article before actually
changing your system.
Microsoft has a salesblurb on NTFS that describes it from a
security perspective. (http://www.microsoft.com/ntserver/ntfs_mb.htm)
2.3.1 I Just installed a service pack. Why
is my file permissions changed?
There are some known instances where service packs have reset permission
to the state the permissions where on the first installation.
2.3.2 Why can users without permissions delete
files?
There is a known problem in 3.5, 3.51 and 4.0 versions of NT that users
might be able to delete files without permission. Check out Knowledge Base
article Q142017
on the subject
Yes. There are at least two different OSes that is capable of this, MS-DOS
and Linux.
It is possible to use the NTFSDOS.exe program from MS-DOS to read information
of a NTFS formatted disk.
2.4 Registry
As shipped from Microsoft, most versions of NT have very weird access control
list settings on the system registry keys. Some registry keys have had
permissions that let everyone access and change them over the network.
Dan Shearer <itudps@lux.levels.unisa.edu.au>
wrote in message <"ydd1N.0.UA4.0BSJo"@suburbia> dated Sat, 28 Sept 1996
14:05:28 +0930
> here's some more:
> ppl can read portions of the registry remotely (via regedt32.exe).
By default they can _write_ to it too, at least under 3.51 the default
permissions gave Everyone write access to quite a few things. The canonical
example was (is) the key that determines the association between an application
and its extension in file manager. That can be changed by an unpriveliged,
even unknown user with access to regedt32 on a connected network. Should
the .txt entry be changed to point to:
net user administrator xxxxx /y
notepad %1 %2 %2 %3 %4 %5
all someone with admin privilege at the console has to do is double-click
on a text file and the admin password is changed. Of course this is a pretty
basic example because the admin would (hopefully) be suspicious on seeing
a dos box pop up. But it is trivial to write a win32 app that both launches
notepad and does some malicious trapdoor stuff with the admin privilege
it has been given.
This is true for NT 3.51.
David LeBlanc <dleblanc@iss.net>
has written some text on the registry
In the registry, I'd go in and remove write permission to Everyone
from HKEY_CLASSES_ROOT, and give full access to creator\owner, which is
what Microsoft did with NT 4.0 - much more secure.
Some applications still uses old .INI-type files for initialization, especially
ports of old Windows 3 and MS-DOS programs. Those programs might have
vulnerabilities in such way that the file protection are wrong and by that let
someone read sensitive data, such as password, or change data.
The HKEY_LOCAL_MACHINE key is recreated by the system each time the system
is booted. This have the effect that changes in the ACLs for this key does
not persist over a reboot.
It depends on the version and role of the computer.
In NT 3.51, the registry is remotely accessible by default.
In NT 4.0, the ACL on the registry key
HKLM\CurrentcontrolSet\Control\SecurePipeServers\winreg
(DWORD:1) defines who can access the registry remotely. On a NT server, this key
exists with permissions set to Administrators:Full Control, but on a workstation there is no
such key. The workstation do look for it though, so just create it and set its permissions
if this is an issue.
The following keys are well suited for planting a back door in one way or another.
Always ensure the ACLs on these are ok. To keep track of changes or tries to change
them, one can set up auditing on the keys as well. See
2.10.5 Auditing .
This keys lists shares and named pipes that are accessible without logging in to the system,
a so called NULL session connection (see 2.7.4 ).
One scary aspect of this is that if you by coincident happen to create a share or named
pipe which name matches any of the names in these lists, they are accessible from a NULL session
connection.
Note that the RestrictAnonymous key under Control/LSA mentioned in
$$$: Q143474
does not prevent access to resources listed here.
Lists the DLLs that is to be invoked when a user change its password. The perfect point
for a password snitcher. See 2.14.2.
Please note that this is not an extensive list. There are more of these, and there
is no way of knowing when new ones appear. Any suggestions of things that would fit here
is gladly accepted. Contact the current maintainer
of this FAQ.
2.5 User security
Users are susceptible to a number of attacks, such as dictionary password
guessing. In Windows NT, one way to protect against those types of attacks
is to set the number of failed logins before disabling the account temporary
or until the system manager manually enables it again.
For more info regarding passwords in Windows NT, see 2.14 Passwords.
As to user rights, I like to go through and make sure Guest is not
only disabled, but that it has no rights to anything. Give careful attention
to who is allowed to log on from the network and locally. One thing to
consider is that the administrator account is on every machine, and can't
be locked out from too many bad passwords. A good way around this is to
remove the administrator's group from the permissions to log on from the
network, and add back in the individual users who are the admins. Now go
set it up to audit failed login attempts, lock out users for a few minutes
if there are too many login failures, and require a password of decent
length - 6 characters is acceptable. This makes brute force attacks very
difficult. If you want to prevent other users from accessing the machine
remotely, you can also remove the users from the right to log on from the
network - that confines the users to having to use the shares on the server.
This also prevents anyone not given that right from accessing the event
log, the registry, and the shares on the machine. You might also want to
pay attention to who can and cannot shut the machine down, and perhaps
make it to where you need to log in to shut it down.
2.5.1 Administrator account
Microsoft recommends that you changes the name of the administrator account
so that outsiders cannot guess the name.
This is of course just one of the things you can do. But
unlike what some Microsoft employees believe, security does not stop
there. Just changing name of administrator is to trying to protect
yourself by the lowest level of security there is, security by
obscurity .
It is possible to obtain the new name of the administrator by using
the command
nbtstat -A <ip-address>
when the administrator is logged in on the console.
2.5.2 Guest account
As shipped, some older versions of Windows NT had a guest account that
was easily used by outsiders. Newer versions of NT have their guest account
closed as shipped from Microsoft. Anyway, you should check out your guest
account and disable it as much as possible.
Some people remove the guest account from their system, but unfortunately,
Microsoft ship some product that relies upon the usage of that account.
For example, if you use Microsoft Internet Studio in combination with Microsoft
SQL or Microsoft Access running on another computer than the one running
Internet Studio.
2.6 Network security
For some background information on Internet and Internet security, see
Yes. To my knowledge, all IP based systems are possible victims for the
attack.
According to the article in phrack
magazine, volume 48, (http://www.fc.net/phrach/files/p48/p48-13.html)
NT have a queue size of 6 outstanding SYN packets. The article will serve
as good reading if you want to understand the details of the problem.
2.6.2 Is it possible to use packet filters on an
NT machine?
NT 4 comes with built-in support for packet filtering. It is a simple but
still usable filtering function that the administrator can configure to
just let some IP packets reach the actual applications running on the system.
You find configuration panel for the filtering function on "Control
Panel->Network->TCP/IP->Services->Advanced->Security"
Be aware that this simple filtering mechanism is not a substitute for
a real firewall since it cannot do advanced stuff like protection against
ip-spoofing, etc.
2.6.3 What ports must I enable to let NBT (NetBios
over TCP/IP) through my firewall
First of all, you should really, really reconsider if this
is such a good idea to let NBT traffic through your firewall. Especially
if the firewall is between your internal network and Internet.
The problem with NBT is that at once you open it up through the firewall,
people will have potential access to all NetBios services, not just a selection
of them, such as printing.
Authenticode is a way to ensure users that code they download from the
net has not been tampered with and gives the code an etched in ID of the
software publisher. Microsoft is pushing this as a new way of getting better
security into software distribution over the net.
In other SNMP-enabled machines you can configure both an write and a read
community name. On a Windows NT system you can only set one. Not having
a community name does not disable the service, as one might expect. According
to David LeBlanc, <dleblanc@iss.net>:
If you don't specify a community name, it will answer to anyone.
2.6.7 What servers have TCP ports opened
on my NT system? Or: Is netstat broken?
Normally, the netstat program should report information on the status of
the networking connections, routing information, etc. With the option -A
or -a, it should list all TCP and UDP available connections and servers
that are accepting connection. On Windows NT, even though the documentation
states otherwise, this is not the case.
There are no simple way to check what services that are running
with TCP ports opened to accept connections. Currently the only way to
get some information about this is to use a port scanner program and test
through each TCP port on the NT machine. This is not a fool proof way of
dealing with the problem.
This is a serious problem if you plan to have NT based computers
in the firewall environment. You cannot easily hardened them to become
bastion hosts, since you are not confident what types of network services
that might be reachable from the outside.
It is a confirmed bug in Windows NT 3.5, 3.51 and 4.0.
I do not expect Microsoft to fix it soon enough.
Update:
netstat.exe is fixed as of NT4 SP3, but it still shows some strange behavior. For example,
on a moderately loaded machine, you can find numerous duplicates of open connections. Why is that?
To get more information on TCPs three way handshake and the different states
of a TCP connection, see Microsoft's paper TCP
Connection States and Netstat Output
2.6.8 What are giant packets? Or, is Windows NT susceptible to the PING attack?
There are mixed reports whether or not NT is vulnerable to this attack.
By using ping to send a large packet to certain systems, they might hang
or crash.
Windows NT 3.51 seem to be vulnerable to this attack. A knowledge base
article, Q132470,
describes symptoms in Windows NT 3.51, and also include a pointer to a
patch for this problem
Check out Mike Bremford's Ping
o' Death web page (http://www.sophist.demon.co.uk/ping) for more information
on what systems are vulnerable and how.
Update:
The PoD site has moved to http://prospect.epresence.com/ping, which doesn't seem
to exist in the DNS for the moment.
There is a PoD II, which utilizes a bug in the way Microsofts IP-stack assembles
fragmented IP packets.
2.6.9 What about the denial-of-service problem
with RPC
There exists a problem with the RPC on port 135. This can be misused to
launch a denial-of-service attack against a NT system.
The example below, which uses the SAMBA package,
illustrates how this can be done
Security problems with DHCP include, but is not limited to
Fake DHCP-servers
Non-existing logs of who used what IP-address at a certain occasion
in past time.
One of the big limitations with DHCP has been the inability to log and keep a
historical track of which machine has leased which IP-address in the past. In SP3
Microsoft is said to have added this possibility. (Note: Not verified by
FAQ maintainer.)
The "OOB attack" is a denial of service attack that utilizes a bug in Microsofts implementation
of its IP-stack. Source code for a program called Winnuke that does this was posted to BugTraq in
May 1997 by _eci <myst@LIGHT-HOUSE.NET>.
Due to a bug in Microsofts IP implementation, one can fool the
stack to reassemble fragmented packets in such ways that it is
possible to send arbitrary data to an arbitrary port even when
the target machine is protected by a firewall. There are
firewalls that prevent this by handling all reassembling before
forwarding the complete packet to the target host. It is probably wise
to check up your firewall and/or apply SP3 if not done already.
CIFS stand for Common Internet File System and is a specification for a
file sharing protocol. It is based on the Server Message Block protocol,
SMB.
There is a mailing list where the designers from Microsoft and the designers
of SAMBA and other network file systems discuss CIFS. Check it out on 'listserv@msn.com'.
Send the command subscribe CIFS yourname to subscribe. The mailing list
is archived at http://microsoft.ease.lsoft.com/archives/cifs.html
2.7.2 Is it possible to turn off the default
sharing?
NT by default makes a share for each hard disk or partition. One have to
manually disable this behavior.
Patrik Carlsson <patrik@netman.se> gives a solution for the problem
in a mail to NT-security mailing list:
If the non-sharing of the default shares is an issue you could probably
write som sort of batch or cmd file that runs every time you start the machine
and disables the sharing. something like net share c$ /DELETE.
Another way is to create the registry key AutoShareServer or
AutoShareWks, depending on the machine role, as a REG_DWORD under
HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters
and set it to 0. Restart the Server service.
Note that this does not prevent IPC$ to be shared! A safer bet is
to stop and disable the Server service altogether if that is an option.
(Note: I have verified this a while ago, but cannot reproduce it on my
current installation. Please report any better luck to
ntsec@incolumitas.se.
BTW, try to search MS for the string "C$", on the web or the
MSDN Library CD.)
A NULL session connection, also known as Anonymous Logon, is a way of
letting a not logged on user to retrieve information such as user
names and shares over the network. It is used by applications such as
explorer.exe to enumerate shares on remote servers. The sad part is
that it lets non-authorized users to do more than that. Particularly
interesting is remote registry access, where
the NULL session user has the same permissions as built-in group
Everyone.
With SP3 for NT4.0 or a fix for NT3.51, a system administrator can restrict the
NULL session access, see
$$$: Q143474.
With this fix, a new well-known SID is
defined, named "Authenticated Users", which is Everyone except NULL
session connected users. Replacing Everyone in all ACLs on the machine
with this Authenticated User would be a good thing. To do this in a
controlled fashion, one can use cacls.exe for the file system, but
have to rely on some third party product for the registry ACLs. Using
explorer.exe/winfile.exe or regedt32.exe will most certainly break the
system. The cause for this is that these tools replace the
ACL instead of editing it.
2.8 Application and subsystem security
2.8.1 Web server security
There are a number of problems with web servers. Bugs in the server, stupid
CGI scripts, erroneous configurations, strange other services (e.g. data
base connections) are just a few things that might be used to damage your
security.
You might want to look at the WWW
Security FAQ to get some general security information on WWW.
If you install an Windows NT machine as a web server or a firewall,
you should tighten up the security on that box more that you should do
to ordinary machines on your internal network since a machine accessible
from the Internet are more vulnerable and more likely to be attacked. Securing
the machine gives you a bastion host. Some of the things you should
do include
Remove all protocol stacks except TCP/IP, since IP is the only protocol
that runs on the Internet
Remove some network bindings
Disable all unnecessary accounts, like guest
Remove share permissions and default shares
Remove network access for everyone (User Manger -> Policies -> User rights,
"Access this computer from the network")
Disable unnecessary services (FTP, etc)
Enable audit logging
Track the audit information
Internet Information Server
Check out Andy Baron's bug reports on earlier versions of the Internet
Information Server. Microsoft also has some information on this bug
as well as suggestions to workaround in Knowledge Base article Q148188.
Microsoft has some information on known vulnerabilities in IIS available
in Knowledge Base
Article Q142631
describes a problem where a users might access unwanted directories
Article Q147691
describes a problem where Anonymous Users Have Same Access as Domain Users
in IIS
Another bug has been found in IIS servers that will hang or kill the web
server. Sending the HTTP command "GET ../.." will hang a IIS version 2.0
server on NT 4. There are conflicting rumors whether this will work on
NT 3.51 or not.
Microsoft recommend that you upgrade your IIS server to version 3.0
or the latest available version.
IIS version 2.0 and 3.0 is vulnerable of a denial of service attack
using a "CGI request from a browser that contains between 4 and 8 kilobytes of data in the URL"
(cited from
Q143484 - IIS Services Stop with Large Client Requests).
People have found bugs in Netscape's Communications server on NT as
well. Check out this
e-mail to the www-security mailing list.
One should definitely be aware of CERTs
advisory CA-96.11 that describes the problem with having a perl interpreter
accessible over the net.
There is some work going on to get a better situation for people who
want to use perl on NT-machines running webs. Check out Softshore's web page
on PERL for NT.
Microsoft have some on-line articles on security and web servers. There
is articles on
There is known problems with the FTP server that ships with Windows NT.
There is another FTP server that comes with the Internet Information Server,
IIS, that is supposedly more secure.
As stated elsewhere in this document, logging is not turned on by default.
To turn on logging of the FTP server, there are a number of registry key
parameters that can be changed. They are located under the following key
IE sending away your password hash. Warning! Following the links below using Internet Explorer
may reveal your user name and password. Use a temporary fake account with a dummy password or
any other WEB browser.
Over NetBIOS
(http://www.ee.washington.edu/computing/iebug/)
On the NT 4.0 CD-ROM there are a utility called rollback.exe that will
corrupt your system if run. It is not intended for end-users, but someone
slipped and the tool is now out on many users systems.
Without any sign of warning, rollback.exe will remove all system registry
entries, which in turn will leave the system in a state where there are
not easy way to recover. One have to grab the emergency repair disk and
do a restore from the latest backup.
There is anExchange
FAQ with lots of Q &A's. Especially, check out chapter 17 on security.
2.8.8 Microsoft SNA
When installing the complete SNA package, you will get at least three more
services, AFTP, NVAlert and NVRunCmd.
AFTP is like its TCP/IP counterpart FTP a tool to transfer files over the
net. It might be used for anonymous logins as well.
NVRunCmd is a service that lets someone running the NetView network monitoring
tool send ordinary commands over the net that will be executed locally
on the Windows NT machine.
Make sure that you have disabled these services if you want to run a more
secure setup.
According to a posting to Bugtraq by Carl Byington
<carl@five-ten-sg.com >, default installation of
cc:Mail version 8 with an smtp link has some problems:
After installing a cc:Mail release 8 postoffice (and link to smtp) on an
NT3.51 machine, I noticed that the nightly reclaim process is scheduled via
the standard NT "at" command which runs %systemroot%\~callmnt.bat. This
batch file simply runs yet another batch file %systemroot%\~ccmaint.bat.
Why do this? Because the second batch file is "hidden", but a simple
"attrib" command removes that "protection", and then your master postoffice
password is nicely visible.
But you might ask, what are the NT security permissions on these batch
files? Simply "everyone full control". Oh well, at least I don't need to
worry about forgetting that password.
According to a posting to NTBugTraq by
Ondøej Holas <OHolas@EXCH.DIGI-TRADE.CZ>,
the Spooler Service shipping with Windows NT is susceptible to a denial of service attack:
After connecting to \\server\PIPE\SPOOLSS you can send probably any
amount of data to that pipe. Final effect is a memory leak in
SPOOLSS.EXE. The worst thing is, by default this connection can be
initiated over null-session (setting RestrictAnonymous to 1 has no
effect). To disable attack over null-session, you must remove line
"SPOOLSS" from
HKLM\System\CCS\Services\LanmanServer\Parameters\NullSessionPipes
(REG_MULTI_SZ), but after that authenticated users can still fill up
server's memory.
There are several security issues related to ODBC usage
Add hooks
Tracing ODBC connections
Any call with indirections, such as calls to ODBC data sources, are possible to
intercept by attaching to pre-made hooks.
By tracing ODBC connections, which is a completely legitime thing to do during
software development, you can get access to sensitive data, such as user name
for the connected database.
For more information, see
By default, all auditing in Windows NT is turned off. You have to
manually turn on auditing on whatever object you want audited. First off,
you should have a policy for
what to log (user behaviors, changes on files or processes)
for how long to keep the logs
whether or not you should turn on auditing on all your machines, or if you
only turn on logging on the servers
Then you should configure the auditing. You should also remember that it
is hard to have a good use of auditing (or any use at all), if you don't
have good tools and a good suite of policies on how to handle the logs.
You have to remember that cranking up auditing might give you performance
degradation. The trick is to find the balance between how much to log without
getting problem.
Remember that Windows NT saves the logs locally on disk. If someone
can take control over the machine, it is quite likely that the logs might
be manipulated as well. A better solution might be to send away the
logs to one or more protected, centralized log-servers.
No, not out of the box. If you want to have centralized logging for both
UNIX and NT machines you can check out Larry Kahn's syslogutils. To get
access to it, you have to send an email to an autoresponder, access@kahn.drcoffsite.com,
which mail you back information on how to access his FTP server.
Yes. There is a note on this in the Knowledge Base.
2.10.3 Can I grant access to someone to view
or change the logfiles?
Yes you can, but there is an error on the manual on how to do it. Check
out Knowledge Base article Q142615
to see why the "Manage auditing and security log" privilege does not
work as documented.
Even though auditing of enabled user rights is turned on in the Policy->Auditing dialog in
User Manager (for Domains), there is a bunch of user rights that are not logged.
One example, which can cause a lot of confusion, is the Backup and Restore user rights.
The cause for these to be excluded is that it would generate too much log entries if enabled.
A new log entry would be written for each backed up or restored file. Why is that? Couldn't
the backup program just take the backup right once and for all and then backup all of the files,
then discard the right?
See
Securing Windows NT Installation
(http://www.microsoft.com/ntserver/info/secure_NT_con.htm#a23) for a full list of privileges excluded
from auditing and ways of turning auditing on for these.
2.11 Crypto
2.11.1 What is CryptoAPI
CryptoAPI is a set of encryption APIs that allow developers to develop
applications that work securely over non-secure networks, such as the Internet.
CryptoAPI is shipped with NT version 4 and the Internet Explorer 3.0.
Version 2.0 of CryptoAPI comes with SP3 for NT4.
Yes, of course. There is Eric Young's various crypto implementations at
ftp://ftp.psy.uq.oz.au/pub/Crypto/ . An RC4 implementation called arcfour can be found in the SSH distribution.
As pointed out by Paul Ashton in a posting to the NT Security list, you can even use the same functions
that Microsoft them self uses:
Looking at the functions exported by advapi32.dll, you will notice that SystemFunction032() is
accompanied with 32 more functions named like that, SystemFunction001 through SystemFunction033.
Known today is that they include code for the following:
ECB mode DES for calculating LanMan hashes (see 2.14 Passwords)
It's always great fun to read the README.TXT's for the service packs.
They reveal problems that you weren't aware of directly, but can serve as a clue
to other problems you have encountered.
depending on your current browser/proxy location on the globe <sigh>.
Includes things like:
Another obfuscation layer around the SAM database (aka "Strong encryption of password database").
The syskey.exe utility gives the opportunity to encrypt the passwords stored in the registry
another round, using a 128-bit key that optionally can be stored on a floppy disk to avoid that it
is used by the bad guy to decrypt the data. It has to be stored somewhere though, if the
system itself is to validate
any logons at all. Most probably, it's not stored on any permanent media but rather in memory, presumably
only readable by kernel mode programs. But, of course, even there it could be read if you wrote some
code for it (as a device driver for example, or see
Run any Ring 0 code from a Win32 application on Windows NT
(http://www.sonic.net/~undoc/ntcallgate.html))
and had the power to install it. There is a KB article:
Q143475 -Windows NT System Key Permits Strong Encryption of the SAM .
Password filtering. The library passfilt.dll enables some checking of
the quality of chosen passwords. It is possible to supply your own
version of passfilt.dll. See the following KB articles for more information:
$$$: Q161990 - Enable Strong Password Functionality in Windows NT
(http://www.microsoft.com/kb/articles/q161/9/90.htm).
Update of CryptoAPI from 1.0 to 2.0
Changes to the default file permissions (ACLs) on the repair and
backup directories
Fixes to some denial of service (DoS) attacks
Options to restrict anonymous logon and enumerations
Note that passwords are stored in the registry in two formats, the NT way (MD4) and the old
LANman way (three DES encryptions of magic constant using different parts of the password).
These are password equivalents in the sense that they are the only thing that is
needed for a successfull authentication. This means that you don't have to crack them (using
dictionary or brute force) to use them for authentication.
Also, note that the SAM database is backed up to an ordinary file %SystemRoot%\repair\sam._
whenever a repair disk is created with the rdisk.exe program.
HKLM\SECURITY\Policy\Secrets\_SC_servicename\CurrVal contains the
encrypted password of the service. The password is not machine or
account dependent. i.e. a user foo with password bar in domain X
in NT3.51 has the same encrypted value as user baz in domain Y with
NT4.0 (with password bar).
The lsadump
program by Paul Ashton can be used to retrieve the plaintext service password.
Axent has a series of tools called OmniGuard
that includes single sign on, intruder detection, access control, etc.
3.1.3 SomarSoft's DumpACL, DumpEvt and DumpReq
Somarsoft have a suit of tools for dumping
information from NTs databases and logs.
3.1.4 Andy Baron's Password Cracker
ScanNT is a dictionary
based password cracker that check your NT machine for weak passwords.
A demo version is available from the URL above.
3.1.5 ISS
Internet Security Systems, ISS, have a
suite of tools for network security testings that are available on the
NT platform.
3.1.6 TCP/IP Portscan
There is a shareware program called NTPortscan
that scans the net for open TCP ports.
3.1.7 The NetBIOS Auditing Tool
Secure Networks Inc. has released a tool called NetBIOS Auditing Tool that
will check file shares, password integrity, extract information, etc, from
a remote host.
The tool is free of charge and released with source code and distributed
under the GNU public license.
Check out Secure Networks' NAT
web page (http://www.secnet.com/ntinfo/ntaudit.html) or download the
For details and descriptions on how, what and why on firewalls, check out
Marcus's firewalls FAQ.
The National Computer Security Association has certified a number of
firewalls for all types of platforms. Check out their web page
that lists those firewalls and give detailed information on each product.
For a more complete listing of firewall products, visit Cathy Fulmer's
firewalls product
list.
3.2.1 Raptor Eagle
Raptor has a version of it's Eagle
firewall available for the Windows NT platform.
Kerberos gives you secure authentication and an encrypted network session.
To run Kerberos, you have to have at least one Kerberos server available
to hold the kerberos tickets. For more information on Kerberos, consult
the Kerberos FAQ.
There is a Kerberos v. 4 client, currently in beta, available for Windows
NT. You can check it out on this
ftp server. Unfortunately, there are only UNIX Kerberos server sides
available here
3.3.3 SecurID
SecurID is a token based one-time password system that gives you a secure
authentication. There is Windows NT and Windows NT RAS clients available
from the vendor, Security Dynamics
Security Dynamics have a some security resources on-line, such as FAQs,white
papers, etc
Be aware that there have been alot of controversy lately since a posting
of a white paper
describing some weaknesses of the product.
3.3.4 S/KEY
Bellcore's S/Key User Authentication System with One-Time Passwords are
available both as a client program and should be available as a server
program for Windows NT by the time you read this. S/key are available for
a number of UNIX platforms, Windows 3.11, 95, NT 3.51 and 4.0.
The product SeNTry is used for centralized event log viewing and management.
This product is not to be confused with Soft Winters disk encryption tool
named SENTRY 2020 .
A program called PgpEudra to integrate the Eudora mail handling program
with PGP.
3.5.2 MIMEsweeper
There is a product called MIMEsweeper from Integralis that checks e-mail
for viruses. Integralis have both a product
description page and a FAQ
on MIMEsweeper available on the net.
4.0 Where can I find on-line information
on NT security
4.1 Mailing lists
4.1.1 NT Security Mailing list
There is a NT security mailing list maintained by the good folks at ISS.
You subscribe to it by sending a mail to majordomo@iss.net
with the body containing the string "subscribe ntsecurity your email".
The mailing list have some traffic and on-going discussion, and some
people might prefer to subscribe to the digest version instead to reduce
their incoming mail. The digest is available by sending mail to the same
address but with the text "subscribe ntsecurity-digest your email".
The NTBugTraq is the Windows NT counterpart of the BugTraq mailing list
that is mainly for UNIX related bugs with impact on security. It was started
by Russ Cooper
<Russ.Cooper@rc.on.ca>
in the end of January, 1997. It is a moderated list.
Microsoft has some information on-line. It might be contained in the Knowledge
Base archive, it might be in product white papers. Lately, Microsoft has been
moving a lot of information inside some sort of protected area, called
MSDN Online . To register as a member, which for now is free, you unfortunately
have to enable JavaScript and/or Java in your WEB browser. Once registered you
can disable Java, but a lot of things are depending on JavaScript, such as the
find button at
$$$: http://support.microsoft.com/support/.
You should be able to follow the links in this FAQ without enabling
either of the two, but for the links denoted with $$$ , such as
the one above, you have to be registered as a MSDN Online member.
A selection of interesting
information from www.microsoft.com
Trusted Systems have a book entitled "Windows
NT Security" (http://www.trustedsystems.com/NTBook.html)
Tom Sheldon (tsheldon@msn.com)
has written a book entitled "The Windows NT Security Handbook". It is scheduled
for publication in October, 1996.
Charlie Rutstein (Charlie_Rutstein@notes.pw.com)
has an upcoming book on NT Security. Click here
(http://ourworld.compuserve.com/homepages/cbr/toc.html) to see a table
of content of the book.
Mark Joseph Edwards, Peter Cardin and Andy Baron has written a book entitled
"Windows NT Internet Security".
"Windows NT Security Handbook - Everything you need to know to protect your network". Unfortunately, in our opinion, it does not live up to its claim to provide all knowledge you need. It have shortcomings in several areas, such as details in file system security.
Another problem is the rapid development in the software area. Microsoft have
released a number of new products and technologies and renamed some major and
several minor subsystems.
"Windows NT Security Handbook - Everything you need to know to protect your network" has ISBN 0-07-882240-8.
The book "Inside Windows NT", a classic, give an in-depth description on the Windows NT operating system.
