Authentication and Security
For Internet Developers
Scott Stabbert
Internet Developer
Support
Microsoft
Introduction
If you are a Web developer working
with Microsoft’s Internet Information Server (IIS), it is very important to
understand how IIS uses authentication and impersonation to control security on
your Web server. While working in the Internet Developer Support team at
Microsoft, I found that about 1 in 4 of the issues we dealt with were caused by
the umbrella topic we call permissions.
Further, most of those issues could have been avoided if the developer
simply had a better conceptual understanding of what was happening under the
hood. Authentication is simply the
process of determining the identity of a user.
Once a user has been positively identified, Windows NT can then control
what resources that user can access.
While not extremely technical, authentication and security can be
confusing. Having a solid understanding
of how IIS controls security will allow you to be much more successful creating
solid sites, and to avoid common time consuming problems.
This article explains Windows NT
security as it relates to IIS so that you can effectively troubleshoot nasty
security-related problems. We will cover
the three forms of authentication, how they differ, several ways of controlling
access to key areas on your Web server, and the important but almost
universally misunderstood concept of "delegation." Understanding delegation is mandatory for anyone
building a data driven Web site using IIS.
Understanding how Windows NT handles different "users" will
potentially save you days or weeks of troubleshooting.
ACLs, NTLM, and other definitions
To start with, let's define some
common terms that relate to Windows NT's security.
Ø ACLs Access
Control Lists. Each ACL is a list of
Access Control Entries (ACEs) that specify access and auditing information used
by Windows NT on an NTFS-formatted hard drive.
Windows NT uses the lists to determine which users have been granted
access to specific resources (files and folders), and which rights a user may
exercise such as read, write, and execute.
The ACLs for a file or folder can be viewed by right-clicking the
resource, clicking properties, and clicking the Permissions button on the
Securities tab.
Ø Challenge/Response A Windows NT authentication process. Challenge/response can occur when a user or
service (such as IIS) tries to access any resource stored on an NT machine
across a network (such as viewing a shared resource on a server). Can be used by IIS to authenticate a user
browsing a Web site.
Ø NTLM Windows NT's implementation of the challenge/response authentication scheme. NTLM stands for NT LAN Manager because it was developed and originally used in Microsoft LAN Manager, one of Microsoft's earliest networking products.
Ø SAM The
SAM (Security Account Manager) is a database of user and group account
information. The SAM does not contain
passwords, but instead stores password hashes (described later). The SAM is stored in the HKEY_LOCAL_MACHINE\SAM
and HKEY_LOCAL_MACHINE\Security\SAM registry subtrees. Not surprisingly, the SAM is often the prime
target of hackers.
Impersonation
Under different situations IIS
pretends to be different users. Remember
that all processes operating on a Windows NT machine run under a valid NT
account. When a program or process (like
IIS) runs on behalf of a user, it is said to be running under the security
context of that user. The purpose is to
give that process no more access to files and resources than the user would
have. When IIS does this, it is said to
be impersonating that user.
IIS, obviously, is designed to
handle Web requests as an automated service.
To do this, IIS still needs to run under some valid user’s security
context. There are two kinds of requests
that IIS may be required to respond to.
First are anonymous requests where we know almost nothing about the
user, and second are authenticated requests where we know exactly who is
requesting the resource. It's not always
obvious which method is being used since both anonymous and authenticated
requests can happen with no dialog boxes or other indications to the user. It is, however, mandatory that we as
developers always know which method is being used. What account IIS impersonates, and by
extension, what IIS can and can not do depends completely on knowing.
Anonymous Requests — No information is required from the user. By default, when a browser requests a Web
page, IIS will first try to fill the request without authenticating the user. To do this, IIS impersonates a special
Windows NT account, IUSR_machinename
(where machinename is the name of the
IIS host computer). This account is created during the install process for
IIS. If IIS, impersonating the IUSR_machinename account, can access the requested resource,
then the page is served to the anonymous user.
A common problem with anonymous
access occurs when the password for the IUSR_machinename account and the
password entered in the Internet Service Manager get out of sync. When IIS tries to impersonate the IUSR_machinename account, it submits the
password that was entered in the anonymous logon field to Windows NT . If that password is incorrect, IIS is totally
prevented from using the account. Since
anonymous access failed, IIS attempts to authenticate everyone. The scary part of this is that the
authentication can happen silently, so the site begins to fail but the reason
isn’t apparent at all. I’ve talked to
many Web site administrators who were experiencing bizarre security related
problems because their site authenticating all users, and they didn’t even know
it. This makes a huge difference if your
pages are accessing other resources like databases or server side components
(DLLs).
Authenticated Requests — Positive identification of the
user is required. When IIS cannot fill
the request using the IUSR_machinename
account, IIS attempts to authenticate and then impersonate the user so that it
can determine if that user should have access to the requested resource. There are two methods that IIS can use to
authenticate users; Windows NT challenge/response and Basic. These are discussed later in this
article. Authenticated Web access
usually works best within a company’s Intranet or some well-defined, contained
group. Even so, there are some
limitations to consider.
Controlling the
Authentication Method, and Why We Care
The IIS Service Manager tool is the
primary place where we can configure IIS for WWW, FTP, and Gopher
services. Without going into great
detail about the options in the WWW properties dialog box, we do need to be
aware of several key items. By default,
the Password Authentication group will have Allow Anonymous and Windows NT
Challenge/Response selected. The third
access method is Basic, which we will cover later. So lets look at several ways of controlling
access to your Web server.
Allow Anonymous Check Box
If Allow Anonymous is selected, IIS
will always attempt to access the resource being requested by impersonating the
Anonymous Logon account (by default, IUSR_machinename). When the IUSR_machinename account was automatically created, it was assigned a
random password and given guest privileges by being added to the guests
group. Adding or removing the Allow
Anonymous check is the best way to globally turn on or off anonymous access for
the entire Web server. With Allow
Anonymous de-selected, only users with valid Windows NT accounts that can be verified using either of
the two authentication methods will be serviced. Setting up IIS this way is usually only
appropriate for a corporate or members-only setting where it is important to
validate all users accessing your site.
Change Permissions on Files and Folders
The NTFS level permissions are respected by IIS, so manipulating individual permissions on files and folders allows better granularity as you control what pages can be accessed by whom. A common scenario would be to have customer pages on a retail site set with the default "Everyone Full Control" permissions, while other pages that allow the prices to be changed could be restricted to administrators. The IUSR_machinename account is of course part of the Everyone group, so you could restrict access several ways. Either remove the Everyone group and possibly add a "Web authors" group for those that need editing rights, or if you have a diverse number of Web authors and you aren’t interested in setting up and maintaining a "Web Authors" group, you could simply exclude the IUSR_machinename account. This method is obviously best for a site that needs some anonymous while still securing other pages.
ASP Code-Based Security
Code-based security is the most fun. Using Active Server Pages (ASP) code, we can implement unique and varied security. For example, say an annoying person is harassing your site. Since the IP address can be pulled from the logs, we could use the following code to deny access:
<%If
request.servervariables(“REMOTE_ADDR”) = “200.200.157.4” then
Response.Buffer =
TRUE
Response.Status =
("401 Unauthorized")
Response.End
End If%>
There are many server variables
that can be used under ASP, including the LOGON_USER that will return the
domain\username of authenticated users, and a blank for anonymous users. In this case it would be possible to use server
side code to check for key individuals and possibly redirect them to different
pages depending on their job requirements.
I’ve even seen companies used this technique to lock competitors out of
their Web sites.
Windows NT Challenge/Response
Windows NT Challenge/Response is
simply NT’s very secure way of determining who is making a request (that is,
authenticating them). The flow of how
Windows NT Challenge / Response works is mandatory knowledge for anyone working
on IIS. What we are really getting
around to is an understanding of the Windows NT limitation called delegation,
but this can only be explained when challenge/response is clear.
And Now for Something Completely Different: The "Hash"
Windows NT challenge/response does
not send a password across the network because it could be intercepted and
deciphered. NT uses a non-reversible
algorithm that is like a meat grinder.
You put something in, and out comes the hash. Windows NT uses the Internet standard MD4
hashing algorithm to produce a 16-byte (128-bit) hash. It is impossible (theoretically) to take both
the hash and the algorithm and mathematically reverse the process to determine
the password. In other words, the
password serves as a "private key".
Only someone who has the key can generate a particular hash. An NT domain controller has a database of
user hashes generated from user passwords, but doesn’t store the passwords
themselves. (Note that this separation
of hash and passwords does NOT make the domain controller less of a target for
hackers, because sometimes a hash can be used as a password-equivalent; more
about this later.)
IIS and the Challenge/Response Authentication Process
IIS will try to use Windows NT challenge/response authentication if the following are true:
·
If the “Allow Anonymous” box in the WWW properties of
the Internet Service Manager is cleared or the IUSR account doesn’t have
sufficient permissions to access the requested resource or code is used to deny
access.
·
Windows NT Challenge/Response is selected in the
Internet Service Manager under WWW properties
·
The browser making the request understands
challenge/response. Currently Internet
Explorer is the only browser that supports NT challenge/response.
When we say that IIS tries to
authenticate the user, what it actually does is rather simple. It sends an HTTP 401 Access Denied message
back to the browser, with the list of authentication methods it accepts. Another way of looking at this is IIS saying,
“You can’t get what you want without identifying yourself. By the way, I accept the following methods of
identification.” The two methods of
identification are NT Challenge/Response and Basic. Which method is acceptable depends on which
WWW properties are checked in the IIS Internet Service Manager dialog box. If both authentication methods are turned on,
Internet Explorer will always attempt to use challenge/response, while other
browsers will use Basic.
The following table presents a
packet’s-eye view of how NT challenge/response authenticates a user without
ever seeing their password.
Client Server
|
|
|
|
|
|
|
2. Server replies with an HTTP
401 Access Denied and includes NTLM and/or BASIC as acceptable methods of
authentication. |
|
|
|
|
|
|
|
4. Server again replies with an
HTTP 401 Access Denied, and includes a random value for the client. This is the CHALLENGE. |
|
5. Client
encrypts the challenge using their password hash as the private key,
generating a new unique hash for this transaction. The network connection between client and
server is marked as "Keep Alive".
The new hash is sent to the server over the same connection. Only someone that has the user’s password
hash and the random value could generate this new hash. The hash and the user’s name and domain are
then base64 encoded and resent. |
|
|
|
|
|
6. The server sends the hash,
user name, and the challenge value to the appropriate domain controller based
on the domain name sent from the client.
The Domain controller encrypts the challenge value by using the user's
password hash kept in the SAM. The
resulting hash is compared against what the server sent. If they match, the domain controller
authenticates the user, and the server then returns an HTTP 200 OK to the
client with the requested resource |
Why a Random "Challenge"?
The extra step of encrypting a
challenge using a password hash, instead of just passing the simple hash up to
the domain, makes it harder for the hash to be intercepted and used as a
password. Since the challenge requires
the user’s password hash to generate the new hash, it proves the person has at
least the user’s hash, but probably the user’s password as well. All this without having the password sent
over the wire. In essence, the password
becomes a private key and the random value a constantly changing public key.
Delegation!
Delegation is where most people
lose the picture on both NT security and IIS authentication, even though
delegation is a huge issue for anyone considering a secure Web server environment,
or, for that matter, just wanting things to work! When the IIS Web server impersonates a user
authenticated using NT challenge/response, IIS does NOT have the user’s password or
password hash. IIS only sees the
encrypted challenge, which it passes to the domain controller. You are most likely to see this when you have
an ASP page that accesses resources on another Windows NT box (such as a
database). The second Windows NT box
will challenge IIS forcing it to prove that it is truly the impersonated user
and IIS will not be able to since it
can not encrypt any challenges sent to it with the user’s hash. The second machine will deny access, and your
database enabled Web pages fail. This is
a limitation in the Windows NT 4.0 (and prior) security model, and not
IIS. Using Windows NT
challenge/response, there is no way a process impersonating you can access so
much as a text file on another Windows NT box.
If
you ever want to determine when delegation is an issue, ask yourself if the Web
server has the user's password or hash.
In politics you "follow the money". In delegation you "follow the
password"!
An analogy for this could be an
executive that delegates responsibility to a secretary to sign checks and
otherwise act on their behalf. When
using NT challenge/response, the user cannot delegate IIS to act fully on their
behalf. This particular limitation may
well go away with the release of Windows NT 5.0 when NT incorporates the
Kerberos authentication system (developed for MIT's Project Athena).
Basic Authentication
Most people are afraid to use the
Basic authentication option because of the screen they are confronted with when
activating it:
The
authentication option you have selected results in passwords being transmitted
over the network without data encryption.
Someone attempting to compromise your system security could use a
protocol analyzer to examine user passwords during the authentication
process. For more detail on user
authentication, consult the online help.
Are you
sure you want to continue?
The message is as bad as it
sounds. The user name and password are
Base64 encoded. Base 64 is easily
de-coded by even novice hackers, though they would still have to access your
network and use a TCP/IP packet sniffer to intercept network packets, so this
is not a likely event unless you are an overly attractive target such as a
bank.
Most Web administrators I’ve talked
to know that there are differences between NT challenge/response and Basic, but
still treat them as interchangeable.
Basic authentication always prompts the user with a dialog box and asks
them to type in a user name and password.
This information is then sent to IIS, which uses the name and password
to execute a log on locally command
to the IIS box. Since IIS now has the
password of that user, it can answer challenges from remote machines,
eliminating the delegation problem.
Think of a user authenticated using Basic as actually sitting at the Web
server working, where a user authenticated using NT challenge/response as
accessing the Web server from a network.
In fact, the user rights “access this computer from the network” and
“log on locally” are specific user rights that need to be set for users
depending on which authentication method is used. To set these rights, use the "User
Manager for Domains" tool and select the "user rights" item from
the "policies" menu.
Even with its flaws, there are two
circumstances where Basic authentication should be used.
·
You need to authenticate users using a browser other
than Microsoft Internet Explorer. For
example, Netscape Navigator only understands Basic authentication. If you have NT challenge/response and Basic
authentication selected, Internet Explorer will always use NT
challenge/response, and Navigator will choose Basic. If your data is sensitive, this is a serious
security concern.
·
Your site authenticates users and your ASP pages
access resources on other Windows NT machines.
The classic situation is an ASP page that uses
Common Authentication Scenarios
Whenever an Internet user is
authenticated using NT challenge/response, delegation will be an issue when IIS
accesses Windows NT resources across a network or local resources using UNC
paths. Of course, all local resources
can be accessed as long as the user has the correct NTFS level permissions.
UNC Paths
A common delegation-related error
occurs when an ASP page is coded to access a database using a file-based data
source (such as an Access .mdb file) and the location is specified using a UNC
path (for example, \\Server\Share\resource.ext). Even though the resource is local, specifying
a location using UNC makes it look to Windows NT as if it is elsewhere on the
network. The Windows NT networking
subsystem handles UNC paths. Windows NT
is abstracted within its various components enough that if you step into the
networking subsystem, as far as the other Windows components are concerned, you
are out on the network. This leads to
the confusing, but rather amusing scenario where an IIS machine that has
authenticated a user using challenge response, and is trying to access a local
resource using UNC, will demand authentication from itself, and is unable to
fulfill the request. To resolve this
problem, use absolute paths on the IIS machine (for example, “C:\folder\resource.ext”).
Delegation, NOT!
There is a subtle security-related
failure that mimics delegation failure, but is not related to delegation at
all. In both these cases, you will see a
three machine hop that fails (browser to NT/IIS to NT/remote resource). To troubleshoot this, check if this is an
authenticated or non-authenticated transaction.
If authenticated, the problem is almost certainly delegation failure.
However, if the page is accessed anonymously, the problem is likely caused by
the anonymous logon account being local to the IIS machine. This can easily happen
because the IUSR_machinename account is of course created locally. IIS impersonates IUSR_machinename, and attempts to access a resource on the remote
machine. The challenge is passed, and
IIS correctly encrypts the challenge using the IUSR_machinename’s password
hash. However, the remote Windows NT
machine takes the password hash and tries to validate it using its local SAM
database and the local domain controller.
Neither the remote Windows NT machine nor the domain controller have
ever heard of this account and, therefore, can’t validate the information.
a)
Duplicate the IUSR_machinename account as a local
account on the remote machine making sure the user passwords are the same. If an identical local account exists on the
machine with the desired resources, that machine can validate the submitted
hash without the aid of a domain controller.
Even though the two accounts are physically separate accounts, if their
information matches, validation can occur.
One of the technical reasons you can get away with this technique is
because Windows NT’s hashing algorithm is such that two identical passwords
from different users will generate the same password hash. Under UNIX, this isn’t the case. UNIX introduces a value referred to as
"salt" such that two users with the same password will generate
different hash values. Setting up a
duplicate local account is best when you want the IUSR_machinename account to
only have access to specific remote resources on your net. If someone is able to compromise the password
for the anonymous account, they will only have access to those computers on the
network where the local account exists.
The drawback is of course that if the anonymous account needs access to
multiple remote resources, now you have an administration nightmare as all the
accounts and their passwords must be kept in sync.
b)
Make the anonymous logon account a domain
account. To do this, remove the
IUSR_machinename account from the local IIS machine, and create a new account
on the domain controller. From the WWW
properties dialog box of the Internet Service Manager, enter the Username field
information in the format Domain\Username (for example,
BigDomain\JoeUser). This method is the
easiest to administer, but in the event that the account information is
compromised, an intruder would have greater access to the network. For some reason, I’ve talked with a lot of
network administrators who are concerned about the IUSR_machinename account being a target of hackers. It is actually no easier to steal the
anonymous logon account name and password then the CEO’s, so my preference for
ease of administration is the domain route.
c)
SQL Server has the unique ability to allow an
unauthenticated connection from another machine, effectively bypassing Windows
NT’s security. If security isn’t a big
concern (local company intranets are usually pretty safe environments), you may
want to make the process of connecting to SQL server much easier by using
TCP/IP sockets. SQL server will monitor
the network traffic and respond directly to TCP/IP requests, taking Windows NT
out of the loop. SQL has it’s own
security layer, so it is very possible to use this option and still implement a
decent security configuration. To enable
this option, select TCP/IP sockets in the Security dialog box when running SQL
setup.
To “Security Dialog” or Not to “Security Dialog”?
That is the Question!
Some Web developers do not want
their users to have to type in a name and password each time they view the
site. So when will users be prompted
with a dialog box to enter their name and password?
When using NT challenge/response,
Internet Explorer automatically and invisibly
sends the logon name, domain name and hash of the currently logged on user to
the Web server. Internet Explorer does
this without asking because sending the encrypted challenge doesn’t present any
real security risk. From there, two
things can happen:
·
If the IIS machine sends information that can be appropriately
validated by the domain controller, the user will be authenticated without a
visible prompt.
·
If the domain name sent by the browser isn't
recognized by IIS, then IIS will have no idea where to send the information for
validation. This is more common for
Internet users than intranet users, since a person sitting at home is rarely on
a domain. Even if they are, their domain controller probably isn’t accessible
by the IIS machine. Internet Explorer
prompts the user to enter a new name and password, in effect saying, “Give me
some information that I can use.” If an
employee working at home were trying to access a secured site, they would need
to enter their name in the form “bigdomain\JoeUser” and their password in the
password field so that IIS will get the correct domain information. Explicitly stating the domain name in this
manner is almost always mandatory authenticating users across the Internet.
Under Basic authentication, the user will always be prompted with a logon dialog box. You can probably guess why. We are about to do something that could compromise your Windows NT account name and password. All browsers figure that if you are willing to fill in the information and click OK, then you must know what you are doing. I personally don’t have a problem using Basic authentication on a secure corporate network, but I will not use it over the Internet without an additional layer of security such as Secure Sockets Layer (SSL is invoked on a specially configured Web server that uses HTTPS:// instead of HTTP://). Once again, the user will need to explicitly state the domain. IIS still needs to verify the submitted information with some domain controller.
Hackers and Your Site
Before I get into this, it seems I
always need to offer a disclaimer. Yes,
an aspiring young hacker could read this and get ideas, but believe me, there
are much better sources for hackers than this article. The best way to really secure your site is to
know where the weak points are, and no one knows where the weak points are
better than hackers. There are several
key areas that a hacker may try and attack or exploit on a Web site. Obviously getting their hands on a username
and password with administrative privileges is the biggest coup. Getting a user’s password hash is almost as
good because a password hash can be used in some cases as a "password
equivalent." The password hash
could be used to answer challenges by encrypting the challenge. Doing this can grant an intruder "access
this computer from the network" rights.
To be granted a "log on locally" right, though, they still
need the actual password.
Several programs have been written
specifically to extract password hashes from a Windows NT domain controller’s
SAM database, and crack the passwords.
PWDump.exe and NTCrack.exe are both free on the Internet, and are used
by both system administrators and hackers.
System administrators will use PWDump to synchronize the password lists
between network servers in a mixed environment such as UNIX and Windows NT so
users don’t need different passwords for the different Network operating
systems. Hackers will use PWDump and
NTCrack to execute a brute-force attack against a network. Here is how it works. PWDump.exe is a program written to dump the
SAM database of user hashes and account information to a text file. An administrator must run PWDump, so hackers
usually wouldn’t run the program themselves.
If they already had an administrator’s password, they would have
enough. A hacker without administrative
access to a network could construct a Trojan horse program that could be sent
in e-mail to an unsuspecting user. If
the user, while logged on with administrative rights, ran the attachment in
e-mail, the program could silently dump the SAM database and e-mail the text
file to the hacker. (I received mail recently with an attachment that said
"click here." I’ll give you
one guess what the chances are of my clicking on an unknown e-mail attachment;
exactly zero). Once a hacker has the
output of PWDump, they still don’t have any passwords. Remember that the MD4 hashing algorithm
theoretically cannot be reversed.
NTCrack is the program of choice for brute force attacks against a list
of password hashes. NTCrack can take all
the words in the English language, as well as play sophisticated games for
variations with numbers and case sensitivity, and in several hours on an
average Pentium machine, generate all the possible hashes for about a million
words and phrases. It then just matches
the hashes on file with the hashes retrieved from PWDump, and looks to see
which password generated that hash. NTCrack is only useful because users tend
to choose passwords that are easy to remember.
If NTCrack had to brute force attack all the possible password hashes
for Windows NT’s maximum password length of 14 characters (including numbers,
symbols, and case sensitivity), the search it would take several thousand
million years using a Pentium 120. (I
don’t know if anyone has calculated how long it would take on a Pentium Pro, but
I think we’re safe for a little while.)
If you would like more information on security issues, search the
Internet for NTCrack or PWDump. I
personally enjoy using NTCrack on my own system to ensure that the password
list is secure and that my users are choosing good passwords.
Final Word
I hope you now have a better idea
of Windows NT security issues that affect Web site development. This subject comes up the most frequently on
sites that use authentication and deliver dynamic database driven content. In this article I've tried to look at just
the underlying foundations of security and delegation. Future articles will begin to build on this
understanding, and discuss more specific configuration issues and
problems. If you have a good
understanding of what IIS is doing to get its job done, you’ll be much more
able to get your job done.
Happy programming!
Scott Stabbert
ASP / Visual InterDev Training Lead
Microsoft Internet Developer Support